分布式事务解决方案
分布式事务解决方案
数据库事务正确执行的四个基本要素ACID ：
原子性
一致性
隔离性
持久性
CAP定理：在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容忍性（Partition tolerance）三个要素最多只能同时实现两点，不可能三者兼顾。
- 一致性：在分布式系统中的所有数据备份，在同一时刻是否同样的值。
- 可用性：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。
- 分区容忍性：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
BASE理论：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。
解决方案
两阶段提交（2PC）
需要引入一个协调者，其他节点为参与者。
第一阶段：
- 协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待答复。
- 各参与者执行事务操作，将 undo 和 redo 信息记入事务日志中（但不提交事务）。
- 如参与者执行成功，给协调者反馈 yes，否则反馈 no。
第二阶段
- 当所有参与者均反馈 yes，提交事务，协调者向所有参与者发出commit请求，参与者commit释放资源，通知协调者，完成提交。
- 当有一个参与者反馈 no，回滚事务，协调者向所有参与者发出rollback请求，参与者执行undo日志，通知协调者，完成回滚。
优点：尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。
缺点：实现复杂，牺牲了可用性，对性能影响较大，不适合高并发高性能场景。
问题
- 性能问题：所有参与者在事务提交阶段处于同步阻塞状态，占用系统资源，容易导致性能瓶颈。
- 可靠性问题：如果协调者存在单点故障问题，或出现故障，提供者将一直处于锁定状态。
- 数据一致性问题：在阶段 2 中，如果出现协调者和参与者都挂了的情况，有可能导致数据不一致。
三阶段提交（3PC）
TCC
Try : 预留资源，执行业务
Confirm / Cancel : 执行commit或者提交
缺点：代码侵入大，Try、Confirm 和 Cancel 操作功能要按具体业务来实现，业务耦合度较高，提高了开发成本。
优点：业务方控制锁，数据最终一致性，解决了2阶段提交协调者单点故障问题，由主业务方发起并控制整个业务活动。
注意点：
1、幂等
可能会存在重复调用，业务方需要保证接口幂等性
2、空回滚
回滚事务调用二阶段，但一阶段尚未执行，业务方需要考虑，可引入事务状态控制记录作为控制手段，无记录时即为空回滚
3、资源悬挂
回滚事务调用二阶段完成空回滚后，一阶段执行成功，业务方需要考虑，可引入事务状态控制记录作为控制手段，二阶段发现无记录时插入记录，一阶段执行时检查记录是否存在
本地消息表
在发起方需要创建一个本地消息表，用来记录生产方的事务发送情况
