| 方案 | 简介 | 事务分类 | 一致性 | 总结 | 实现/产品/框架 |
|---|---|---|---|---|---|
| 两阶段提交（2PC） | 二阶段分别指的是准备和提交两个阶段 | 数据库层面 | 强一致性 | 锁资源-阻塞-效率低 | Seata |
| 三阶段提交（3PC） | 准备阶段、预提交阶段和提交阶段 | 数据库层面 | 强一致性 | 引入一个阶段也多一个交互，因此性能会差一些 | |
| TCC（补偿事务） | TCC 指的是Try - Confirm - Cancel | 业务层面 | 最终一致性 | 执行效率高，基于 TCC 实现分布式事务，会将原来只需要一个接口就可以实现的逻辑拆分为 Try、Confirm、Cancel 三个接口，所以代码实现复杂度相对较高。 | Seata |
| Saga模式 | Saga是一个长活事务可被分解成可以交错运行的子事务集合。其中每个子事务都是一个保持数据库一致性的真实事务 | 业务层面 | 最终一致性 | 业务流程长、业务流程多 无锁，高性能 | Seata apache/servicecomb-pack |
| 最大努力通知 | 柔性事务的思想：尽力最大的努力达成事务的最终一致；直接传递消息消费，要是成功则成功，要是失败则多重试几次，还是不成功就算了 | 业务层面 | 最终一致性 | 适用于对时间不敏感的业务；最大努力通知事务方案既没有使用本地表扫描，也未使用可靠消息机制 | |
| 本地消息表 | 本地消息表其实就是利用了 各系统本地的事务来实现分布式事务 | 业务层面 | 最终一致性 | 此方案的核心是将需要分布式处理的任务通过消息日志表的方式来异步执行，执行成功后修改消息的状态；此外另起一个线程，不断轮询本地消息表中未处理成功的消息再次发起调用。与tcc相比，实现方式较为简单，开发成本低。缺点： 事务业务与消息发送业务耦合 、业务数据与消息表要在一起 | RocketMQ |
| 消息事务 | RocketMQ 事务消息的功能 | 业务层面 | 最终一致性 | 该方案与本地消息最大的不同是去掉了本地消息表，由MQ来实现消息的可靠性传递，确认消息一定被消费。业务相对简单，不需要编写三个阶段业务 缺点：代码侵入, 依赖于MQ的可靠性. | RocketMQ |
分布式事务总结
2021-12-06
227
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《
阿里云开发者社区用户服务协议》和
《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写
侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
简介：
学习摘要
相关实践学习
目录
相关文章
|
29天前
|
消息中间件
缓存
监控
|
2月前
|
数据库
|
2月前
|
数据库
微服务
|
2月前
|
数据库
微服务
|
2月前
|
消息中间件
关系型数据库
调度
|
3月前
|
消息中间件
数据库
RocketMQ
|
6月前
|
消息中间件
Oracle
关系型数据库
|
存储
算法
网络协议
|
消息中间件
存储
Oracle
