WannaRunning的博客

SphU类在sentinel-core依赖中，主要用于对资源的访问控制。当系统想要执行某个资源操作时，通过调用 SphU.entry 方法来检查该资源是否受到流量控制。如果资源当前处于限流状态，那么 SphU.entry 会抛出 BlockException 异常，表示请求被限流，此时系统可以进行降级操作。如果资源没有受到限流，那么 SphU.entry 会返回一个 Entry 对象，表示一次资源操作开始，系统可以继续执行相关的业务代码。

Seata 是一个需独立部署的中间件，所以先搭 Seata Server，下载地址：https://github.com/seata/seata/releases/download/v1.4.0/seata-server-1.4.0.tar.gz解压后，到 /seata/conf/ 下面的步骤修改相关配置文件修改事务日志和注册中心等配置file.conffile.conf 文件用于配置持久化事务日志的模式，目前提供 file、db、redis 三种方式。默认是file，修改文件选择 db

前面写了常见的分布式解决方案介绍。这篇文章要写的seata是阿里的分布式解决方案中间件。Seata与2PC的区别相对于2pc，seata有独立的事务管理，整体实现也分两阶段，可以看做是2pc的演变。而两种方案最大区别就是Seata支持AT，即异步事务的实现。在2PC中，第一阶段开始事务操作就会锁定资源，直到二次提交完成后释放资源，在整个过程中对于每个分支事务来说资源锁定时间都依赖其他的分支事务。而在Seata中，每一个分支事务的提交操作都可以在第一阶段自主完成，降低了锁范围提高效率。而第.

生产环境下一般更常用的是 push 模式的数据源。对于 push 模式的数据源,如远程配置中心（ZooKeeper, Nacos, Apollo等等），推送的操作不应由 Sentinel 客户端进行，而应该经控制台统一进行管理，直接进行推送，数据源仅负责获取配置中心推送的配置并更新到本地。因此推送规则正确做法应该是配置中心控制台/Sentinel 控制台 → 配置中心 → Sentinel 数据源 → Sentinel，而不是经 Sentinel 数据源推送至配置中心。实现流程1.控制台将规则推送.

目录@SentinelResource的实现方式分析基于web层配置进行流控配置实现方式分析SentinelWebAutoConfiguration阅读官方文档后做一个分析总结，对于sentinel单独在应用中实现流控，官方文档中建议使用姿势如下：一般推荐将@SentinelResource注解加到服务实现上，而在 Web 层直接使用 Spring Cloud Alibaba 自带的 Web 埋点适配分析一下就是对于非API接口形式的资源使用@SentinelResour..

之前的文章写了Sentinel的整合使用方式，这篇文章具体写一下它的容错实现。容错的三个核心思想1.保证自己不被上有服务器压垮2.保证自己不被下游服务器拖垮3.保证外界环境良好Sentinel的主要功能就是容错。主要体验在三个方面：流量控制任意时间到来的请求是随机不可控的，但是服务的处理能力有限，Sentinel就可以只作为一个调配器，根据需要把随机的请求限制为指定的形状。熔断降级当检测到链路中的某个资源不稳定时，如请求时间过长或异常响应比例升高，则对这个资源进行限制，让

sentinel是springcloud alibaba里的高可用流量控制组件，顺便提一下Hystrix，两者都是做熔断降级。Hystrix与Sentinel对比Hystrix支持线程池隔离和信号量隔离两种模式。线程池隔离的好处是隔离度高，缺点是多线程池切换会带来一定的系统开销。Hystrix的信号量隔离是基于线程并发数量限制实现的，但是缺点是无法对慢调用自动进行降级，只能等待客户端自己超时，因此仍然可能会出现级联阻塞的情况。Sentinel 可以通过并发线程数模式的流量控制来提供信号量隔离的功

并发场景中读写操作安全性除了使用同步锁机制外，另一种更好的实现方式就是使用CopyOnWrite的方式保证读写安全。写入时复制（CopyOnWrite，简称COW），简单来说，就是平时查询的时候，都不需要加锁，随便访问，只有在更新的时候，才会从原来的数据复制一个副本出来，然后修改这个副本，最后把原数据替换成当前的副本。修改操作的同时，读操作不会被阻塞，而是继续读取旧的数据。这点要跟读写锁区分一下。此做法主要的优点是如果调用者没有修改资源，就不会有副本（private copy）被创建，因此多个调用者只是

nacos默认是AP模式，也就没有主从节点之分，搭建集群也比较简单。复制三份相同的nacos程序包，进入其中一个查看[root@host-192-168-48-4 nacos]# lsbin conf data LICENSE logs NOTICE target[root@host-192-168-48-4 nacos]# cd conf/[root@host-192-168-48-4 conf]# lsapplication.properties application.

类似于Eureka与config集成后的项目多环境配置，nacos集成了注册中心和配置中心的功能。配置方式也与前者基本类似，匹配原则上优先级最高的就是以 {服务名-环境变量.后缀}匹配配置文件。配置文件组合包括主bootstrap.yml文件和各个环境的配置文件其中主文件中只配置 要激活的环境信息 和 服务名称spring: main: allow-bean-definition-overriding: true profiles: act.

CAP原则根据分布式CAP理论，即一致性consistency，可用性availability，分区容错partition-tolerance三个特性中，最多满足其中两个。Eureka 满足AP两个特性，它实现的是最终一致性，当新的服务注册到集群中的一个eureka 上，此时这个服务挂掉了，那么刚刚注册的服务就无法同步到其他eureka 上也就无法被调用者使用。但是当eureka 重新启动后就可以恢复。Zookeeper满足CP两个特性，集群中主服务挂掉后，会在子服务中选举新的注册服务，在选举过

nacos简介在 spring cloud alibaba中，nacos类似于Eureka的功能，它的作用一个是注册中心，另外一个是配置中心。nacos文档:：https://nacos.io/zh-cn/docs/what-is-nacos.htmlnacos博客：https://nacos.io/zh-cn/blog/index.htmlNacos安装方式可以...