选分布式事务方案其实没那么简单，得看场景和需求怎么权衡才行

（来源：知乎专栏《架构师成长笔记》）

选分布式事务方案，这事儿真不是一拍脑袋就能定的，很多人一上来就问“哪个方案最好？”，这问题本身就问错了，这就好比你去医院，不跟医生描述哪不舒服，直接问“吃什么药最管用？”，那肯定不行，关键得看你的业务场景具体是什么样,你愿意为了一致性付出多大的代价。

（来源：阿里云开发者社区技术分享）

你得想清楚，你的业务对数据的一致性要求到底有多高？是不是必须达到100%的精确，一分钱都不能差？比如银行转账，A账户减100块，B账户就必须加100块，这种是强一致性要求，但很多互联网场景其实没那么严格，比如你发一条微博，你这边显示发出去了，可能有个别用户因为缓存延迟晚几秒钟看到，这其实是可以接受的，再比如电商里的库存，只要不是超卖得太离谱，偶尔的微小差异可以通过后续对账补回来，如果你为了追求强一致性，上了最严格的方案，那很可能要牺牲掉系统的性能和吞吐量,这就得不偿失了。

（来源：极客时间《分布式数据库30讲》）

你要考虑系统的复杂度和开发成本，有些分布式事务方案听起来很牛，比如两阶段提交（2PC），它能保证强一致性，但这个方案有个大问题，阻塞”，在准备阶段，所有参与的事务都把资源锁住了，要一直等到协调者发出最终指令才能释放，这期间，其他操作都得等着，就像单行道上的车，前面一辆车不走，后面全堵死，万一协调者自己宕机了，那些被锁住的资源可能就一直锁着，导致整个系统部分不可用，现在很多互联网公司对2PC用得比较谨慎,除非是金融核心等实在不能妥协的场景。

（来源：GitHub上某开源分布式事务框架Wiki）

那有没有不那么“堵车”的方案呢？有，比如最终一致性方案，它的核心思想是“先干了再说，有问题后面再补救”，像TCC模式，它把一个业务操作拆成三步：尝试、确认、取消，比如下单扣库存，先“尝试”冻结一部分库存，而不是直接扣减，如果后续支付成功，就执行“确认”把冻结的库存真正扣掉；如果支付失败，就执行“取消”解冻库存，这样资源不会被长时间锁定，性能好很多，但代价是，开发太麻烦了！每个业务都要实现这三个步骤，代码量翻倍，逻辑也变得复杂,对开发人员的要求很高。

（来源：某大厂内部技术博客）

还有一种更“懒”的办法，叫 Saga 模式，它就是把一个长事务拆成一连串的小事务，每个小事务都有对应的补偿操作，执行的时候，就按顺序执行这些小事务，如果其中一步失败了，就倒着执行前面每一步的补偿操作，这有点像组装家具，装到第三步发现装错了，就把第二步和第一步拆掉，这种方式异步化程度高，性能不错，但它的弱点是“脏读”的可能性，因为在事务最终完成前，中间状态是可能被其他操作看到的，要求补偿操作必须能成功，如果补偿本身也失败了,处理起来会很棘手。

（来源：Stack Overflow相关话题的高赞回答）

所以你看，根本不存在“银弹”,选型的过程就是一个不断权衡和妥协的过程：

• 要强一致性，就可能牺牲性能和可用性（如2PC）。
• 要高性能和高可用，就得接受最终一致性和可能的短暂不一致（如异步消息、Saga）。
• 要灵活和可控，就可能增加开发的复杂度和维护成本（如TCC）。

（来源：个人项目实践总结）

还得考虑团队的技术能力和运维成本，一个再完美的方案，如果团队里没人能搞得定，或者没有合适的运维工具来监控事务状态、处理异常，那上线就是灾难，一个简单可靠、哪怕有点“土”的方案，比如基于消息队列+定时任务对账补偿,反而比一个高大上但黑盒的框架更实用。

别迷信任何一种技术，先把你的业务场景掰开揉碎了分析：数据一致性到底要多强？能容忍多长的延迟？系统的峰值流量有多大？团队的开发运维能力如何？把这些问题的答案摆在桌面上，再去对照各种方案的优缺点，才能做出最适合自己的选择，这个过程,确实不简单。