分布式事务笔记
一、分布式相关概念
1.1 分布式CAP定理
1. 一致性(Consistency)：分布式系统不同节点的数据在同一时刻完全一致
2. 可用性(Availability)：分布式系统随时对外提供正常服务，不是异常或超时（访问某个节点）
3. 分区容错性(Partition Tolerance)：分布式系统出现网络故障后，节点间不能相互通信，此时要保证整体功能是可用的
由于各种网络故障无法避免，CAP不能全部满足，但必须保证发生故障后，分布式系统是可用的，因此共分成PA和PC两种。
选择PA，当某个节点更新延迟，外部访问该节点，获得的是旧数据，牺牲了一致性。
选择PC，则这种情况访问某个节点，这个节点的数据是旧数据，为了保证一致性，必须等到其他节点同步数据，但是因为网络异常节点通信被阻塞了，这个时候请求超时得不到正常响应。
1.2 BASE理论
- 基本可用：在系统出现故障后，允许损失部分功能，保证核心功能可用
- 软状态：允许某些情况下，节点间的数据不一致
- 最终一致性：经过一段时间后，所有节点数据必须一致
BASE是对CAP中一致性和可用性权衡的结果，无法做到强一致性则采取适当的方式达到最终一致性
二、分布式事务的解决方案
2.1 基于XA协议的两段式提交
2.1.1 2PC
- 协调者接收客户端请求，向参与者发送准备命令（其中包含了需要执行的命令）
- 参与者锁定资源，执行命令，在事务提交前等待，向协调器发送 执行完成/执行失败 的回答
- 协调者根据返回，给参与者们发出提交事务或者回滚事务的命令
- 参与者根据命令执行相应的操作，返回操作的结果
需要数据库的隔离级别是串行：https://www.zhihu.com/question/58308824
缺点：协调者单点问题，参与者若未收到提交/回滚则会一直阻塞
2.1.2 3PC
1. 协调者接收客户端请求后，询问参与者是否可以进行事务操作
2. 当全部协调者返回OK，协调者发送准备命令，参与者锁定资源，执行命令并返回执行结果，等待提交
3. 协调者等待执行结果，等待超时则发送回滚命令。获取执行结果，判断是全部成功则发送提交命令，参与者提交事务；否则发送回滚命令。
4. 参与者等待提交/回滚命令超时，则默认提交，并释放资源
2.2 TCC两阶段补偿型
- Try阶段：事务管理者收到客户端请求，向下属服务预留和锁定业务资源
- Confirm阶段：下属服务全部成功锁定。管理者进行确认，操作完成。这一阶段需要保证幂等性
- Cancel阶段：下属服务存在失败，管理者对资源进行取消，操作撤回。这一阶段需要保证幂等性
如果Try阶段成功，则Confirm必须成功。如果Try失败，则Cancel必须成功。如果Confirm或者Cancel有失败，TCC框架将记录，一段时间后重试
案例参考：https://www.jianshu.com/p/70e4ca5e7c53
TCC和XA的区别：
- XA是资源层的分布式事务，锁定时间长，但业务代码不需要改造。
- TCC是业务层的分布式事务，最终一致性，锁定时间可控，但需要对业务的代码改造，跟业务紧耦合
2.3 本地消息表（异步确保）
把分布式事务拆分成若干个本地事务。各个系统本地有一个本地消息表，用于存放发往其他系统的请求，并且会记录下系统的返回，比如成功失败。发起方将执行自身业务和保存本地消息表封装成一个事务。保证了放入消息表中的业务自己已经执行完成。然后将消息发往下一个系统，收到了回复则更新消息表的执行状态。返回成功则事务完成，返回失败则需要回退自身业务，或者重试。如果一直没有收到回复，则扫描消息表，将没有返回的消息重发。
2.4 MQ事务消息
RocketMQ支持事务消息（网图已附参考，侵权联系即删）
- 发起方发送prepare消息到Broker，Broker返回成功。此时相当于告知MQ我正在执行本地事务，一会儿会告诉你结果
- 确认MQ返回成功后，发起方执行本地事务，并通知MQ执行结果 Commit（代表成功），RollBack（代表失败）。通知可能丢失，Broker会定时回调发起方提供的反查事务状态接口
- Broker收到是Commit，则将prepare消息发送给订阅方，订阅方执行成功则消费消息，否则由MQ负责重试
- Broker收到是Rollback，则丢弃prepare消息
2.5 Sagas事务模型
将长事务拆成多个短事务，由Sagas工作流引擎负责协调，如果某过程执行失败，Sagas会以相反的顺序调用补偿操作，进行回滚。
参考：https://zhuanlan.zhihu.com/p/183753774
Open/X XA：https://www.jianshu.com/p/6c1fd2420274
