Sentinel

雪崩问题

微服务之间相互调用，因为调用链中的一个服务故障，引起整个链路都无法访问的情况。

Sentinel与Hystrix

sentinel使用案例

sentinel官网




访问微服务任意端点，即可触发sentinel监控：

限流规则

流控模式

在service层方法添加@SentinelResource注解


对来源于query入口的请求限流。

流控效果

热点参数限流

隔离和降级

Feign整合Sentinel

线程隔离

熔断降级

授权规则与规则持续化

自定义异常结果

规则管理模式

Seata

分布式事务问题

理论基础

CAP定理

CAP 也就是 Consistency（一致性）、Availability（可用性）、Partition Tolerance（分区容错性） 这三个单词首字母组合。

CAP 定理（CAP theorem）指出对于一个分布式系统来说，当设计读写操作时，只能同时满足以下三点中的两个：

C：一致性（Consistency） : 所有节点访问同一份最新的数据副本
A：可用性（Availability）: 非故障的节点在合理的时间内返回合理的响应（不是错误或者超时的响应）。
P：分区容错性（Partition Tolerance） : 分布式系统出现网络分区的时候，仍然能够对外提供服务。

由于当前的网络服务，网络故障是不可避免的，那么在保证分区容错性（P， Partition Tolerance）的前提下，可用性（A，Avaliability）和一致性（C， Consistency）就只能保证一个，因为你要保证可用，在分区的情况下，发生网络故障一定无法保证一致性，在保证一致性的情况下，就只能把网络故障断开的分区的机器停用，那这就违背了可用性。

CAP理论告诉我们，在保证P的前提下，只能出现CP或AP的架构

BASE理论

Seata架构

• TC（Transaction Coordinator）事务协调者：维护全局和分支事务状态，协调全局事务提交或者回滚
• TM（Transaction Manager）事务管理器：定义全局事务的范围，提交或者回滚全局事务。
• RM（Resource Manager）资源管理器：管理分支事务处理的资源，注册分支事务并报告分支事务的状态给TC，驱动分支事务提交或回滚。

部署TC服务

微服务集成Seata

Seata的四种模式

XA - 强一致性

XA模式：强一致性模式，几乎所有主流的数据库都对XA规范提供了支持。

但是XA模式一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差，而且XA模式依赖于关系型数据库来实现事务。

正常情况下：

回滚情况下：

seata的XA模式：
seata对XA模式做了一些调整：

RM一阶段工作：

• 注册分支事务到TC
• 执行分支事务SQL但不提交
• 报告执行状态到TC

TC二阶段工作：
TC检测各个分支事务执行状态

• a、如果都成功，通知所有的RM提交事务
• b、如果有失败，通知所有的RM回滚事务

RM二阶段工作：
接收TC指令，提交或回滚事务

代码中实现：