文章目录
- Sentinel
- Seata
-
- 分布式事务问题
- 理论基础
- Seata架构
- 部署TC服务
- 微服务集成Seata
- Seata的四种模式
-
- [XA - 强一致性](#XA - 强一致性)
Sentinel
雪崩问题
微服务之间相互调用，因为调用链中的一个服务故障，引起整个链路都无法访问的情况。
Sentinel与Hystrix
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指令，提交或回滚事务
代码中实现：