分布式数据一致性/分布式事务总结

一、简述

1、分布式事务/分布式数据一致性问题根源：存储资源的分布性，写多个资源，写入不能确保一定成功
2、分布式事务模型：
1）AP：Application，应用程序
2）RM：Resource Manager，资源管理器
3）TM：Transation Manager，事务管理器
注：事务可分为全局事务和分支事务

二、常见解决方案

1、两阶段提交
1）实现思路：
a）准备阶段：事务管理器（TM）通知资源管理器（RM）准备分支事务，记录事务日志，并告知事务管理器的准备结果。即挨个资源管理器除commit操作外均执行完成
b）提交/回滚阶段：第一阶段中所有RM都返回成功，则TM向所有RM发送commit指令；有任何一个RM返回失败，则TM向所有RM发送rollback指令
2）缺点
a）同步阻塞：准备阶段涉及的RM资源会被一直锁定，直到全部提交或回滚
b）过于保守：任何一个失败都会全部回滚（作者觉得这条没啥毛病）
c）TM单点故障：第二阶段TM故障会导致第一阶段锁定的资源不会被释放
d）脑裂导致数据不一致：局部网络异常等在第二阶段可能有些RM通知到了，有些通知不到
2、三阶段提交
1）实现思路
a）询问阶段：TM向所有RM询问是否能执行
b）准备阶段：若第一阶段所有RM都回复能执行，则对所有RM执行除commit外的所有操作（同两阶段提交中第一阶段），否则向所有RM发送事务中断请求
c）提交/回滚阶段：同两阶段提交中的第二阶段
2）相比于两阶段提交的优点：
a）增加询问阶段，可尽早发现无法执行操作而中止后续的行为
b）引入超时机制，一旦超时，TM和RM都会默认继续提交事务，认为状态为成功。因为事务提交成功的可能性远大于失败的可能性，但该做法可能导致数据不一致，所以超时时需要加入些必要的日志或报警便于追溯
3、TCC补偿方案（Try-Confirm-Cancel）
1）Try：这个阶段主要是对数据的校验或者资源的预留
2）Confirm：确认真正执行的任务，只操作Try阶段预留的资源
3）Cancel：取消执行，释放Try阶段预留的资源
注：本质上是一种两阶段提交的思想，可通过redo日志来防宕机丢数据，下游使用密等接口
4、基于可靠性消息的最终一致性方案
利用消息中间件的可靠性机制类实现数据一致性的投递，即事务消息和事务回查
5、最大努力通知型
在下游如果没有返回一个消息确认时，上游需要不断的进行重试，直到收到一个消息确认或者达到最大重试次数

三、分布式事务框架Seata

1、Seata提供了4种事务模式：AT、Sega、TCC（补偿方案）、XA（两阶段）
2、AT模式
1）实现思路：
a）第一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源，即缩小锁粒度
b）第二阶段：提交异步化。全局提交，说明此时所有分支事务已经完成了提交，通过异步队列清理回滚日志即可；回滚则通过第一阶段的回滚日志进行反向补偿
注：使用AT模式时，RM必须是支持本地事务的关系型数据库
2）隔离性
a）写隔离：第一阶段中，获取本地锁->业务操作->获取全局锁->本地提交释放本地锁->释放全局锁
注：
a）获取全局锁如果多次重试失败，则回滚事务，释放本地锁
b）全局锁与本地锁的死锁问题通过获取全局锁timeout解决
d）读隔离：默认读未提交，靠最终一致性
3、Saga模式
1）实现思路：长事务解决方案，把一个业务流程中的长事务拆分成多个本地短事务，业务流程中的每个参与者都提交真实的提交给该本地短事务，当其中一个参与者事务执行失败，则通过补偿机制补偿前面已经成功的参与者。
2）补偿恢复方式
a）向后恢复：把之前的执行结果逐一撤销
b）向前恢复：对失败的事务进行重试
3）优劣势
c）优势：一阶段直接提交，性能高，短事务可异步执行
d）劣势：不支持原子性和隔离性
3）协调模式：
a）事件编排式（分布式）：把Sega的决策和执行顺序逻辑分布在Sega的每一个参与者中，它们通过交换事件的方式来进行沟通
b）命令协同式（集中式）：把Sega的决策和执行顺序逻辑集中在一个Sega控制类中，它以命令/回复的方式与每项服务进行通信，告诉它们应该执行哪些操作
4、Seata file存储模式
1）单机模式：默认，全局事务会话信息持久化在本地文件中，性能高
2）db存储模式：高可用模式，全局事务会话信息通过db共享，性能相对较差。全局事务会话信息由全局事务、分支事务、全局锁构成
3、Seata配置
1）registry.conf
a）registry：配置注册中心地址
b）config：配置Seata配置文件地址
2）file.conf：Seata的配置，包括：协议、服务端、监控