分布式事务实现方案
可靠事件模式（定时任务的健壮性）：主业务在本地维护一个本地事件表，一定要和主业务在同一个库中，这样可以利用数据库事务保证本地事件表的数据和主业务数据同时落库成功，当业务进来之后，本地事件表记录一条消息，消息状态记录为待发送，同时发送MQ消息，至此同步的业务执行完毕；异步的任务为：当MQ消息持久化到磁盘中后，回调业务方，这时候修改本地事件表中的消息状态为已发送，然后消费者消费成功后发送事件，业务方接收到消息将本地事件表中的消息状态改为完成，同时修改业务数据
TCC模式：将一个任务拆分三个操作：Try、Confirm、Cancel；调从业务时，都要先执行所有从业务的try，所有的try都成功了再调用confirm，当其中有任意一个confirm失败，则调用cancel回滚
可靠事件模式2.0（去哪网使用）（需要第三方协调服务的健壮性）：每个参与方都在本地维护一个本地事务表，A调B、C，A调B失败，A调C成功，B失败有可能是真的失败，也有可能是超时失败实际成功，那么在B端就记录的是成功，这时候需要一个第三方服务，复制协调对比每一方的事务结果，如果想刚刚这种情况B实际是调用成功了，则不进行回滚或者补偿，把A端记录B的调用改为成功，如果B确实是失败了，根据业务补偿B，或者回滚A和C都行
消息广播（MQ的健壮性）：A调用B、C，A执行成功后，发送成功事件，B、C监听到成功事件后，做相应的操作，如果A调B失败，A发送调用失败的消息，B、C监听到消息做回滚操作
1. 两阶段提交 (2PC - Two-Phase Commit)
特点：
经典的分布式事务协议
分为准备阶段和提交/回滚阶段
协调者(Coordinator)负责协调参与者(Participant)
优点：强一致性保证
缺点：同步阻塞、性能较低、协调者单点问题
实现：
XA协议(JTA/JDBC)
MySQL XA
Oracle XA
2. 三阶段提交 (3PC - Three-Phase Commit)
特点：
2PC的改进版，增加了预提交阶段
减少了阻塞时间
引入了超时机制
优点：比2PC更可靠，减少了阻塞
缺点：实现复杂，仍然存在一致性问题
3. TCC (Try-Confirm-Cancel)
特点：
业务层面的两阶段提交
每个事务操作需要实现Try、Confirm、Cancel三个接口
适用于高并发场景
优点：性能较好，可保证最终一致性
缺点：业务侵入性强，开发成本高
实现：
Seata TCC模式
ByteTCC
TCC-transaction
4. SAGA模式
特点：
长事务解决方案
将大事务拆分为多个本地事务
每个本地事务有对应的补偿操作
优点：适合长时间运行的事务
缺点：不保证隔离性
实现：
Seata Saga模式
Apache ServiceComb Saga
Eventuate Tram Saga
5. 本地消息表
特点：
基于消息队列+本地事务表
通过定时任务保证消息投递
优点：实现简单，性能较好
缺点：消息可能重复消费
6. 最大努力通知
特点：
定期通知，不保证一定成功
适用于对一致性要求不高的场景
优点：实现简单
缺点：不保证强一致性
7. 事务消息
特点：
基于消息队列实现
如RocketMQ的事务消息
优点：解耦服务，性能较好
缺点：依赖消息队列
实现：
RocketMQ事务消息
Kafka事务消息
8. 开源框架
Seata：
阿里开源的分布式事务解决方案
支持AT、TCC、SAGA、XA模式
Atomikos：
轻量级分布式事务管理器
支持JTA/XA
Narayana：
JBoss提供的JTA/XA实现
选型建议
强一致性：XA/2PC
高并发场景：TCC
长事务：SAGA
最终一致性：本地消息表/事务消息
简单业务：最大努力通知
评论区