SpringCloud（三）Sentinel、Seata、多级缓存

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（事务协调者）指令，提交或回滚事务

代码中实现：
直接在yaml中设置XA模式，然后使用时用@GlobalTransaction注解。

AT（Auto Transaction）- 最终一致性

XA模型中多个资源需要相互等待事务提交状态都报告后，才可以执行最后的提交或者回滚，期间会锁定资源，由于多个事务相互等待，可能导致资源锁定周期过长。

AT模式强调最终一致性，同样是分阶段提交的事务模型：
阶段一RM的工作：

• 注册分支事务到TC
• 记录Resource的undo-log（数据快照）
• 每个Resource直接执行业务SQL并提交
• 报告事务状态到TC

阶段二：
如果成功提交，则RM删除undo-log
如果失败回归，则RM根据快照记录恢复到执行前

AT模式与XA模式最大的区别是什么？

• XA模式一阶段不提交事务，锁定资源，AT模式一阶段直接提交，不锁定资源。
• XA模式依赖数据库机制实现回顾，AT模式利用undo-log数据快照实现数据回滚。
• XA模式强一致性，AT模式是最终一致，因为没有锁定资源，可能导致脏写问题。

脏写与写隔离

解决脏写问题，可以由TC记录正在操作某行数据的事务，该事务持有全局锁，具备执行权，即AT模式的写隔离，这样AT模式相当于锁的粒度就降低了。

优缺点

AT模式的优点：

• 一阶段完成直接提交事务，释放数据库资源，性能比较好
• 利用全局锁实现读写隔离
• 没有代码侵入，框架自动完成回滚和提交

AT模式的缺点：

• 两阶段之间处于软状态，属于最终一致性
• 框架的快照功能会影响性能，但比XA模式好很多

实现：

TCC（Try-Comfirm-Cancel）- 无锁模式

TCC模式与AT模非常相似，每个阶段都是独立事务，不同的是TCC通过人工编码来实现数据恢复，需要实现三个方法：

• Try：资源检测和预留
• Confirm：完成资源操作业务，要求Try成功Comfirm一定要成功
• Cancel：预留资源释放，可以理解为try的反向操作

TCC的优点和缺点

优点：

• 一阶段完成直接提交事务，释放数据库资源，性能好
• 相比AT模式，无需生成快照，无需使用全局锁，性能最强
• 不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库

缺点：

• 有代码侵入，需要人为编写try、confirm、cancel接口，太麻烦
• 软状态，事务是最终一致的
• 需要考虑confirm和cancel的失败情况，最好幂等处理。

空回滚和业务悬挂

使用案例

具体编码时：
首先申明TCC服务接口，定义好TCC的三个方法：

在service层编写实际的TCC逻辑

Saga模式

Saga模式是Seata提供的长事务解决方案，也分为两个阶段：

• 一阶段：直接提交本地事务
• 二阶段：成功则什么都不做，失败则通过编写补偿业务来回滚

四种模式对比

多级缓存

• 客户端缓存
• Nginx本地缓存
• Redis缓存
• JVM进程缓存