分布式事务
目录
分布式事务
分布式事务模式总结
| 方案 | 简介 | 事务分类 | 一致性 | 总结 | 实现 / 产品 / 框架 |
|---|---|---|---|---|---|
| 两阶段提交（2PC） | 二阶段分别指的是准备和提交两个阶段 | 数据库层面 | 强一致性 | 锁资源 - 阻塞 - 效率低 | Seata |
| 三阶段提交（3PC） | 准备阶段、预提交阶段和提交阶段 | 数据库层面 | 强一致性 | 引入一个阶段也多一个交互，因此性能会差一些 | |
| TCC（补偿事务） | TCC 指的是 Try - Confirm - Cancel | 业务层面 | 最终一致性 | 执行效率高，基于 TCC 实现分布式事务，会将原来只需要一个接口就可以实现的逻辑拆分为 Try、Confirm、Cancel 三个接口，所以代码实现复杂度相对较高。 | Seata |
| Saga 模式 | Saga 是一个长活事务可被分解成可以交错运行的子事务集合。其中每个子事务都是一个保持数据库一致性的真实事务 | 业务层面 | 最终一致性 | 一阶段提交本地事务，无锁，高性能 事件驱动架构，参与者可异步执行，高吞吐 补偿服务易于实现不保证隔离性 | Seata |
| 最大努力通知 | 柔性事务的思想：尽力最大的努力达成事务的最终一致；直接传递消息消费，要是成功则成功，要是失败则多重试几次，还是不成功就算了 | 业务层面 | 最终一致性 | 适用于对时间不敏感的业务；最大努力通知事务方案既没有使用本地表扫描，也未使用可靠消息机制,一般会提供主动查询接口 | |
| 本地消息表 | 本地消息表其实就是利用了 各系统本地的事务来实现分布式事务 | 业务层面 | 最终一致性 | 此方案的核心是将需要分布式处理的任务通过消息日志表的方式来异步执行，执行成功后修改消息的状态；此外另起一个线程，不断轮询本地消息表中未处理成功的消息再次发起调用。与 tcc 相比，实现方式较为简单，开发成本低。缺点： 事务业务与消息发送业务耦合 、业务数据与消息表要在一起 | MQ |
| 消息事务 | RocketMQ 事务消息的功能 | 业务层面 | 最终一致性 | 该方案与本地消息最大的不同是去掉了本地消息表，由 MQ 来实现消息的可靠性传递，确认消息一定被消费。业务相对简单，不需要编写三个阶段业务 缺点：代码侵入,还需要编写回查接口， 依赖于 MQ 的可靠性. | RocketMQ |
基于消息的最终一致性
基于可靠消息实现分布式事务最终一致性
优点：
性能高
缺点：
事务无法回滚
实现较为复杂
基于事务消息实现分布式事务最终一致性
优点：
实现较为简单
缺点；
性能较可靠消息差，消息发送失败事务会回滚，增加了业务故障点
参考资料
