镝不咸分布式事务这件事，我前后啃了差不多两周才敢说自己彻底摸透了。最开始是被线上一个奇怪的“订单已支付但库存没扣”的问题逼着去学的，后来发现几乎所有团队聊到分布式事务都会卡在同一个地方：网上讲 CAP 和两阶段提交的文章一大堆，但要么只讲理论不给落地，要么直接甩代码让你抄，抄完还是不知道为什么。这篇我想换个方式，把 CAP、2PC、3PC 这些概念拆开揉碎，结合订单库存、支付对账这些真实场景，讲清楚方案选型背后的权衡，也把实现过程中的坑和排查思路一并整理出来。
适合正在做微服务拆分、遇到数据一致性问题的后端同学，也适合准备系统设计面试、需要把分布式事务讲出深度的人。我会从最核心的“为什么需要分布式事务”讲起，逐步推演到具体协议、实现细节、常见问题，基本上你读完就能拿着这套思路去设计自己项目里的方案。
1. 内容整体设计与思路拆解
1.1 先从“分布式事务到底解决什么问题”说起
单体应用时代，事务很简单。一个订单创建操作，涉及到订单表、库存表、账户表，都在同一个数据库里，直接用数据库自带的事务就能保证要么全部成功、要么全部失败。但拆成微服务之后，订单服务、库存服务、账户服务各自持有独立的数据库，原本一个本地事务就能搞定的事情，被拆成了跨服务的多次调用。
比如用户下单这个动作，理想情况下应该是：订单状态改成“已支付”，库存扣减成功，账户余额扣除成功。这三个操作分布在三个服务里，每个服务各自有独立的事务，没有任何一个数据库能同时管住这三张表。如果订单改成功了，库存扣减失败了，就会出现“钱付了但货没发”的脏数据。这就是分布式事务要解决的核心矛盾：如何在多个独立资源之间维持事务的原子性。
很多初学者会把分布式事务误解成“分布式数据库的事务”，其实两者差别挺大。分布式数据库的事务是指数据分散在多个节点，但由同一个数据库引擎统一管理；而分布式事务是多个独立的服务/资源各自为政，需要通过额外的协调机制让它们达成一致。前者靠数据库内部协议，后者靠应用层协议，也就是我们常说的 CAP、2PC、3PC 这些。
1.2 理清 CAP 理论在其中的真实位置
网上聊分布式事务必提 CAP，但这个理论其实回答的是“分布式系统在正常运作时能达到什么上限”，而不是“如何实现分布式事务”。CAP 讲的是：在网络分区（Partition）发生时，系统只能在一致性（Consistency）和可用性（Availability）之间二选一，不能同时满足。
分布式事务本质上是“为了保证一致性而牺牲一定可用性”的典型场景。比如两阶段提交，在协调者发出提交指令之后，所有参与者必须同步确认，这个等待确认的过程本身就是一种可用性下降。你可以把 CAP 理解为分布式事务的“底层约束”，而 2PC、3PC 是“在约束下设计的具体协议”。
很多人会以为“CAP 中 AP 比 CP 更好”，这其实是脱离场景的空谈。对于支付、库存这类的强一致性场景，CP 反而是刚需；对于社交动态、日志采集这类场景，AP 则更合适。所以在选型分布式事务方案之前，先要想清楚自己的业务到底属于哪一种。
1.3 选型前必须明确的三种事务模型
从设计思路上看，分布式事务的方案大致可以分成三类：强一致性、最终一致性、业务补偿。强一致性以 XA 协议、两阶段提交、三阶段提交为代表，适合短事务、高一致要求的场景；最终一致性以本地消息表、事务消息、SAGA、TCC 为代表，适合长事务、可以容忍短暂不一致的场景；业务补偿则是更灵活的手动对账和冲正机制，适合业务流程复杂、没有现成框架可用的场景。
这几类方案的关系不是简单的“哪个更好”，而是“在什么约束下成立”。如果你们系统对一致性的要求是“用户支付成功后库存必须立即准确”，那强一致性方案是首选；如果业务流程中有异步环节，比如支付回调后异步发货，那最终一致性更合适。搞清楚这个区分，后续的协议理解才不会走偏。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 两阶段提交（2PC）核心细节解析
2.1 协调者与参与者的角色拆解
两阶段提交是最经典的强一致性协议，几乎所有分布式事务教材都会拿它开刀。它定义了两个角色：协调者（Coordinator）和参与者（Participant）。协调者负责发起事务、收集决策、最终拍板；参与者负责执行本地操作、上报状态、根据协调者指令提交或回滚。
典型场景是银行跨行转账：转账服务是协调者，转出账户数据库和转入账户数据库是参与者。第一阶段协调者问两边“你们能不能扣/加这笔钱”，第二阶段协调者说“可以，都提交”或“不行，都回滚”。
这个过程听起来简单，但真正落地时有很多隐含细节。比如协调者在第一阶段必须等待所有参与者返回“准备完成”，这个等待是有超时上限的；参与者返回“准备完成”之后，实际上已经持有了锁资源，不能随意释放。一旦协调者发出提交指令，参与者必须尽快提交，否则整个事务就会卡住。这些细节决定了 2PC 的性能瓶颈和故障风险。
2.2 两阶段提交完整流程逐步推演
我用自己的项目举例。当时我们做了一个订单库存扣减联动，订单服务和库存服务各自独立数据库，通过两阶段提交来保证一致性。完整流程可以拆成如下阶段：
第一阶段（准备阶段/投票阶段）：
- 订单服务作为协调者，向库存服务发送“准备扣减库存”请求；
- 库存服务开启本地事务，执行“预扣减”操作，但不提交；
- 库存服务返回“准备完成”或“准备失败”给订单服务；
- 协调者收集所有参与者的投票结果。
第二阶段（提交/回滚阶段）：
- 如果所有参与者都返回“准备完成”，协调者广播“提交”指令，各参与者提交本地事务；
- 如果有任一个参与者返回“准备失败”，协调者广播“回滚”指令，各参与者回滚本地事务。
这个流程可以用一个表格来汇总，方便对照理解：
| 阶段 | 协调者动作 | 参与者动作 | 关键风险 |
|---|---|---|---|
| 准备阶段 | 发送准备请求，等待投票 | 执行本地操作，持锁不提交 | 协调者宕机时参与者一直锁着资源 |
| 提交阶段 | 根据投票广播提交/回滚 | 执行提交或回滚，释放资源 | 提交指令丢失时参与者无法决策 |
第一阶段的关键在于“预操作”。参与者既要保证能完成本地事务，又不能真的提交，所以通常会在本地事务里执行 SQL 但不 commit。这一步做得好不好，直接决定了第二阶段能否顺利执行。
2.3 为什么两阶段提交面临协调者单点问题
2PC 最大的争议在于协调者单点故障。假设协调者在第一阶段收集完所有投票后、正要广播提交指令时宕机了，此时所有参与者都已经处于“准备完成”状态，锁着资源等着后续指令。协调者一挂，所有参与者既不能提交也不能回滚，只能一直等下去，直到超时。
这个问题的根源是：2PC 的提交决策权完全集中在协调者手中，参与者没有自主决策能力。你可以想象一个只有裁判的拔河比赛，裁判如果晕倒，两队选手就只能僵在原地。
实践中协调者通常会做高可用，比如通过选举、主备切换来保证协调者不挂。但另一个问题随之而来：新的协调者接管后，如何知道之前的事务状态？如果旧协调者已经广播了“提交”而新协调者不知道，参与者可能就会一直等着。所以从故障恢复角度看，2PC 并不是一个足够健壮的协议，这也是后续出现三阶段提交的重要原因。
2.4 两阶段提交的场景适配与性能代价
尽管有单点问题，2PC 在特定场景下依然是合理选择。比如 XA 事务、JTA 事务底层都是基于两阶段提交思想的，很多数据库中间件也支持类似协议。适合 2PC 的业务通常具备以下特征：事务短、参与节点少、对一致性极其敏感、可以接受短暂的不可用。
代价也很直接。参与者从“准备完成”到“收到提交/回滚指令”这段时间，持有着数据库行锁或表锁，相当于把多服务的资源全部串行化了。假设一个扣库存操作持有锁 100ms，那么并发 100 个请求，后面的请求就得排队。这也是为什么 2PC 通常只适用于低并发、强一致场景，而不是所有分布式系统的万能解。
3. 三阶段提交（3PC）的改进与理解
3.1 三阶段提交相比两阶段提交改了什么
3PC 的提出主要是为了解决 2PC 的两个痛点：协调者单点故障后的长期阻塞，以及参与者宕机导致的不确定性。核心思路是把“准备”阶段再拆成两个阶段，多引入一个“预提交”阶段，同时给每个阶段都增加超时机制，让参与者在无法联系协调者时可以自行做出决策。
但这里要泼一盆冷水：3PC 并没有彻底解决分布式一致性问题，它只是降低了阻塞概率，却引入了一个新问题——脑裂。因为参与者有了超时后自主决策的权利，当网络分区发生时，一部分参与者可能超时回滚，而另一部分参与者可能超时提交，最终导致数据不一致。所以在实际工程中，3PC 的使用比例远低于 2PC，更多是作为理论知识点在学习。
3.2 三阶段提交的完整状态流转
3PC 把事务过程分成三个阶段：CanCommit（询问阶段）、PreCommit（预提交阶段）、DoCommit（提交阶段）。
第一阶段，协调者先询问所有参与者“你们是否能够提交这个事务”，参与者只需要回答“能”或“不能”，不需要执行任何实际操作。这个阶段可以理解为“先探探路”，避免某个参与者明明不能执行却还让其他参与者白忙活一场。
第二阶段，如果所有参与者都回答“能”，协调者发送预提交指令，参与者执行本地事务操作并返回“预提交完成”。这个阶段相当于 2PC 的第一阶段，区别在于“预提交完成”之后，协调者还要再等一个最终确认。
第三阶段，协调者收到所有参与者的“预提交完成”后，发送真正的提交指令。这里有一个关键改进：参与者如果在预提交之后超时未收到最终提交指令，可以自行提交，而不是无限阻塞。
状态流转用表格表示会更清晰：
| 阶段 | 协调者指令 | 参与者状态 | 超时后的策略 |
|---|---|---|---|
| CanCommit | 询问是否可以提交 | 待决策 | 回复“不能”，事务取消 |
| PreCommit | 执行预提交操作 | 已预提交 | 等待最终指令，不自行提交 |
| DoCommit | 最终提交/回滚 | 已提交/已回滚 | 超时后自行提交 |
注意第三阶段超时后参与者默认“自行提交”，这是和 2PC 最大的差异。在 2PC 中参与者没有自主决定权，永远等待协调者；在 3PC 中参与者被赋予了更多自主权，代价是可能多节点决策不一致，出现脑裂。
3.3 工程上为什么很少直接用三阶段提交
既然 3PC 解决了阻塞问题，为什么我在生产环境几乎没见过有人直接用？原因是它解决阻塞的方式是“允许参与者自行决策”，但分布式系统里节点间的网络是不可靠的，当一个参与者超时自行提交时，协调者可能正打算广播回滚，于是两个节点就出现了状态分叉。
举个例子，四个节点组成的转账事务，A、B 节点收到提交指令成功提交，C 节点网络超时自行提交，而 D 节点超时后选择回滚。整个事务最终变成一部分提交、一部分回滚，这比 2PC 的“大家一起卡住”更可怕，因为卡住还能人工介入，数据不一致就只能靠对账去弥补了。
所以在实际工程中，3PC 更多停留在理论层面。如果你在网上看到“我们使用三阶段提交”的表述，大概率是某篇博客作者只写了理论而没有真正落地。真正的生产级强一致方案，要么上 2PC 配合协调者高可用，要么直接用 Paxos/Raft 这类共识算法去改造，比如 etcd、ZooKeeper 的 ZooKeeper Atomic Broadcast，本质上已经不是传统 2PC 的范畴了。
4. 从 CAP 到分布式事务的工程实践路径
4.1 用订单与库存场景看方案选型
回到我遇到的那个“订单已支付但库存没扣”问题。当年我们团队在方案选型时，先后考虑过两阶段提交、基于本地消息表的最终一致性、以及 TCC。最终我们没有选用 2PC，原因是流量峰值太高，数据库锁会让库存服务变成整个系统的瓶颈。
后来我们用了本地消息表 + 定时任务的方式。具体做法是：订单服务在扣减库存这个动作发生前，先往本地消息表里插入一条“预发送”状态的消息，然后执行业务操作并提交本地事务；提交成功后，定时任务扫描消息表，把“预发送”状态的消息发送给库存服务。库存服务处理成功后，回调确认，订单服务把消息状态改成“已发送”。如果库存处理失败，消息会不断重试，直到成功。
这里的关键点是：本地消息表和业务操作必须在同一个本地事务里。如果先执行库存扣减，再插入消息表，那消息表可能插入失败，最终业务数据和消息状态不一致。我一开始犯过这个错，后来把顺序调整为先插入消息再执行业务，或者把两者包在同一个数据库事务里，才算稳定下来。
4.2 最终一致性方案对 CAP 的取舍
本地消息表方案走的是典型的 AP 路线。订单服务先在自己的库里把订单状态改为“已支付”，这个过程对外表现为可用；随后通过异步消息把“扣库存”的动作同步到库存服务，两者之间短暂存在不一致状态，最终靠重试机制达到一致。
这种取舍牺牲了一点实时一致性，但换来了高可用和高吞吐。用户看到的支付结果是即时的，库存的扣减可能在几百毫秒甚至几秒后才最终落地。对于大多数电商场景，这完全可接受，因为用户下单后不会立刻看到库存扣减的中间过程。
但要注意，最终一致性方案需要一个额外条件：消息必须可靠投递。如果消息丢失，事务就永远无法收敛到一致状态。我见过很多团队用 RabbitMQ 或 Kafka 做事务消息，却忽略了本地事务和消息发送必须绑定在同一条生命周期里，导致消息发出了、本地事务却回滚了，或者本地事务提交了、消息却没能发出。解决思路是用事务消息或者把消息发送做成幂等重试，而不是简单发一条消息就完事。
4.3 TCC 方案与两阶段提交的对比
TCC（Try-Confirm-Cancel）是业务层面的两阶段提交，和 2PC 站在不同层级。2PC 由数据库或中间件管理，TCC 强调业务方自己实现 Try、Confirm、Cancel 三个方法。Try 阶段预留资源，Confirm 阶段真正执行，Cancel 阶段回滚。
比如库存扣减，Try 阶段把库存从“可用库存”扣减到“冻结库存”，Confirm 阶段把“冻结库存”扣减为“已售库存”，Cancel 阶段把“冻结库存”退回“可用库存”。这样一来，资源的预留和真正的扣减被拆成两步，第一阶段不会持有数据库行锁太久，业务的并发能力比 2PC 好不少。
TCC 的难点在于每个服务的三个方法都要具备幂等性，而且 Cancel 方法必须能正确处理 Try 成功但 Confirm 失败的情况。我在这上面踩过坑：Cancel 方法只考虑“用户发起了 Cancel 才执行回滚”，但实际场景中可能出现 Cancel 方法被重复调用，或者 Confirm 还没执行完就来了 Cancel，导致数据被回滚了两次。后来我们给每个方法加上事务状态记录，用状态机保证同一个事务只能从 Try 到 Confirm 或 Cancel 流转一次，才算解决。
4.4 三阶段提交在选型中的真实定位
既然 3PC 理论上有脑裂风险，是不是就完全没用了？也不完全是。在某些特定场景下，比如参与者数量固定、网络稳定、参与者之间可以互相通信的私有网络中，3PC 的优化思路还是有价值的，它能减少协调者宕机导致的长时间阻塞。
但从我个人经验来看，大多数团队没那个环境去驯服 3PC，最终方案大概率还是落在“本地消息表 + 重试”或“TCC + 状态机”这两条路上。如果你的团队已经有 ZooKeeper 或 etcd，也可以在这些协调服务之上实现基于 Paxos/Raft 的事务协调，但这就涉及更复杂的分布式共识算法了，不是一篇文章能讲完的。
5. 常见问题与排查技巧实录
5.1 订单支付成功但库存扣减失败的根因定位
这是我线上遇到最多的问题。表现形式是：用户支付成功，订单状态正常，但一个月后发现库存数据对不上。排查思路可以按以下顺序来：
- 先查订单服务和库存服务的本地事务日志，确认两个操作是否都进入了提交或回滚流程；
- 再查协调者（如果有）的状态日志，看是否广播了提交/回滚指令；
- 检查消息队列中是否存在未确认的消息，或者消息表里是否有“预发送”状态长期未更新；
- 确认库存服务的扣减接口是否幂等，是否因为重复调用导致数据错乱。
我见过一次很隐蔽的故障：库存服务扣减接口本身没有加幂等控制，重试机制每 5 秒重发一次消息，结果同一笔订单被扣了两次库存。后来我们在库存服务里加了一个“业务单号唯一索引”，才让重复消息落不了库。
5.2 本地消息表中的“死信”处理
本地消息表方案最常见的坑就是“死信”——消息重试次数过多却一直失败，最终卡死在消息表里。如果不处理，会对数据库表造成压力，而且日志量越来越大，排查问题时很难找出真正的失败原因。
我们的做法是给消息表增加一个“重试次数”字段，当重试次数超过阈值（比如 10 次）时，将消息标记为“人工介入”，并触发告警。整个处理时间视消息量而定，比如每天 10 万笔订单，至少会产生 10 万条消息，如果 1% 的消息变成死信，每天就有 1000 条人工处理任务，如果没有告警和批量查询工具，基本是灾难。
一个小技巧：定时扫描任务不要只关注“现在重试”，还要关注“重试时间”。如果消息是半小时前产生的，说明库存服务已经持续异常半小时，这时候需要优先检查库存服务的健康状况，而不是继续盲目重试。
5.3 两阶段提交超时失败的恢复流程
如果你在生产环境确实用了 2PC，那就要提前做好超时恢复预案。一次标准的恢复流程是这样的：
- 协调者记录每个事务的全局状态，包括参与者的 IP、端口、事务 ID；
- 当协调者发现某个参与者超时未回复时，先把该事务标记为“中断”，然后尝试联系参与者；
- 如果确认参与者已经“预提交”但尚未收到最终指令，协调者可以广播“回滚”；
- 如果协调者自己也宕机了，需要靠协调者的高可用节点接管，根据日志恢复事务状态。
实际操作中，我给所有参与者的“准备”操作加上了超时限制，比如 3 秒内必须返回，否则视为“准备失败”。这个时间不是随便定的，是基于对数据库执行耗时的压测结果：正常扣库存 SQL 在 100 毫秒内完成，加上网络传输和序列化，500 毫秒足够，给 3 秒已经很充裕。把超时设太短，容易把正常事务误判为失败；设太长，又会加剧锁的占用时间。
5.4 最终一致性与分布式事务的“对账”兜底
不管选了哪种方案，我都建议保留一个对账任务。分布式事务很难做到 100% 不需要人工介入，哪怕是理论再完美的方案，也可能因为网络分区、bug、运维误操作导致状态不一致。
对账任务的实现思路是：每天定时扫描订单表和库存流水表，找出“订单已支付但库存流水缺失”或“库存已扣减但订单不存在”的数据，然后告警。我们当时用了一条简单的对账 SQL，每天凌晨跑一次，把所有异常对账记录拉出来，配合一个后台管理页面供运维确认和处理。虽然简单，但救了很多次急。
对账不能替代分布式事务，它只是最后的兜底。如果你想着“反正有对账，业务逻辑可以先不严谨”，那迟早会出大事。对账的意义在于帮你发现问题，而不是掩盖问题。
6. 深入理解分布式事务中的关键权衡
6.1 为什么强一致性方案越来越少见
过去很多团队一听到分布式事务就想到 XA、2PC，但实际上现在主流的设计思路越来越倾向于“尽量避免跨服务强一致”。怎么避免？通过服务边界设计。比如订单服务和库存服务如果共享一个库存字段，那这个字段到底归谁管就说不清，永远需要跨服务事务。如果把库存服务设计成“扣减接口对外暴露，是否增减由库存服务自己判断”，订单服务只需要记录订单状态，跨服务依赖就弱化很多。
另一个思路是“把一个长事务拆成多个本地事务”。比如下单、支付、发货、收货，每一步都更新各自服务的数据，通过状态流转串起来。用户在支付前，订单处于“待支付”，不需要和库存强一致；支付完成后触发扣库存，此时即使库存扣减失败了，也可以通过后续的定时补偿来纠正。把强一致拉长到“业务流程级别”，远比在单个操作级别上生硬保证要务实。
这也是我后来在团队里反复强调的一个原则：能通过流程设计避免的事务，不要通过事务协议去硬扛。协议只是工具箱里的一个工具，不能因为工具好用就到处用。
6.2 网络不可靠下的“最终一致”哲学
分布式系统最核心的假设是：网络不可靠、节点可能宕机、消息可能重复。因此，面向分布式事务的设计必然要从“追求瞬时一致性”转向“追求最终一致性”。本地消息表、事务消息、SAGA、TCC，本质都是围绕“短暂不一致 + 最终一致”来设计的。
你可能觉得“最终一致”听起来像逃避问题，但实际上它才是分布式系统下最诚实的技术选择。既然没有办法在同一时刻让所有节点看到完全相同的数据，那就退一步，保证在有限时间内收敛到一致状态，并且每一步都有迹可循、可补偿、可重试。
比如 SAGA 模式，把一个全局事务拆成一系列局部事务，每个局部事务执行完都对外暴露补偿接口。订单创建成功后，如果支付失败，就执行创建订单的补偿操作（将订单置为已取消）。SAGA 不要求所有服务在同一时刻保持一致，但要求每个局部事务都有明确的补偿动作。这个模式在长事务、跨业务流程场景中比 2PC 好用得多。
6.3 分布式事务的“解决”不等于“可用”
方案选型有个容易被忽视的点：理论上正确的方案，在工程上不一定可用。2PC 和 3PC 都有严谨的协议流程，但实际部署时要考虑协调者的高可用、参与者的幂等、网络异常下的重试、超时参数的设置，以及人工介入恢复的流程。这些工程化问题往往决定了方案到底能不能落地。
拿 2PC 举例，分布式的每个参与者都要支持 prepare、commit、rollback 三种能力，大多数关系型数据库通过 XA 协议支持。但接入 XA 后，事务的锁粒度、事务时长、并发量都会发生显著变化。你说不定会发现，原本 1000 并发没问题的接口，在引入 2PC 后只能扛 50 并发，这显然不能接受。
所以在设计阶段，我建议先画一个“事务方案对比表”，把一致性强度、可用性、性能、实现复杂度、运维成本都列出来，再结合自己系统的真实场景打分，而不是看到某个方案有名气就直接用。下面是我自己做项目时参照的对比表：
| 方案 | 一致性 | 可用性 | 性能 | 实现复杂度 | 适用场景 |
|---|---|---|---|---|---|
| 两阶段提交 | 强 | 较低 | 低 | 中等 | 短事务、参与方少、强一致 |
| 三阶段提交 | 较弱（有脑裂风险） | 中等 | 中 | 高 | 理论场景，实际使用少 |
| 本地消息表 | 最终 | 高 | 高 | 低 | 异步业务、可容忍短暂延迟 |
| 事务消息 | 最终 | 高 | 高 | 中 | 配合 MQ 使用，消息可靠投递 |
| TCC | 最终（业务可补偿） | 高 | 中 | 高 | 需要预留资源、必须业务定制 |
| SAGA | 最终（可补偿） | 高 | 中 | 高 | 长事务、流程化业务 |
从表格里能直观看到，没有任何一个方案是完美的。强一致性方案牺牲了性能和可用性，最终一致性方案牺牲了实时一致性。选型就是一场取舍，关键是明确业务的优先级。
7. 个人实操中的判断准则与最后的小建议
7.1 用“支付过程”去判断该选哪个方案
如果让我给一个简单粗暴的判断准则，我会这样问自己：这个操作发生在用户核心交易链路里面，还是后台异步处理链路里？
核心交易链路（比如支付、下单、改价）对用户体验要求极高，通常不能接受长时间等待或页面报错。这种场景下，我倾向于用 TCC 或最终一致性方案，配合快速失败和人工介入机制，而不是用 2PC 把整个链路锁死。
后台异步处理链路（比如同步库存、更新报表、对接第三方）通常可以容忍几分钟的延迟，这时候用本地消息表或事务消息就足够了。重试机制可以放宽，消息消费失败后自动拉起重试，必要时人工介入。
还有一种场景是资金类操作（比如跨行转账、清理结算），这种场景对一致性要求极高，没法容忍“短暂不一致”，尽管上游想换成最终一致性，我也一般会坚持短事务 + 强一致协议，比如 2PC，配合协调者高可用和完备的对账流程，这样才能向老板和审计交代。
7.2 为“分布式事务故障”做准备比选型更重要
再成熟的分布式事务方案，都可能在某个极端时刻失效。比起纠结选哪个方案，我更建议花时间准备一套“故障演练 + 人工介入流程”。我们团队每个季度会做一次故障演练，模拟协调者宕机、消息丢失、数据库主从切换等场景，检验重试机制和补偿逻辑是否真的健壮。
演练过程中常常会发现一些平时发现不了的问题，比如补偿任务重复执行导致数据错乱、消息表索引在数据量巨大时性能退化、人工介入工具缺少审计日志等。这些问题如果不演练，线上出了故障才开始排查，损失就大了。
我的建议是：给每个分布式事务方案都说清楚“当天下大乱时你怎么恢复现场”。如果答不上来，说明方案还不完整。网上很多帖子只教你怎么成功，很少有人讲怎么失败，但失败的恢复过程恰恰是工程实践中最值钱的部分。
7.3 一个小技巧：给每个事务增加全局唯一标识
最后分享一个我在所有分布式事务方案里都会做的小优化：给每个全局事务生成一个全局唯一的 UUID 或雪花 ID，并在所有日志、消息体、数据库记录中带上这个事务 ID。别看它简单，真实排查问题时，没有这个 ID 你根本无从下手。
试想一下，线上出现一个支付成功但库存没扣的问题，你要从订单日志、库存日志、消息日志、协调者日志里找到同一个事务的完整链路，如果没有全局事务 ID，只能靠时间戳模糊匹配，效率极低。有了事务 ID，一条 grep 就能把所有相关记录串起来。
另外一个额外好处是：可以用事务 ID 做幂等。库存服务收到重复的扣减消息时，可以根据事务 ID + 业务类型去数据库查唯一约束，如果已经处理过就直接返回成功，不会重复扣减。这个优化几乎零成本，但能减少大量因重试导致的数据错乱问题。
分布式事务没有银弹。从 CAP 的底层约束，到 2PC 的同步阻塞，再到 3PC 的脑裂风险，每一个“经典方案”背后都有它无法回避的代价。真正稳妥的做法是：明确自己的业务对一致性、可用性、性能的优先级，理解每个方案的底层原理，然后在工程上补足高可用、幂等、重试、超时、对账这些配套设施。理论能帮你选对方向，工程能力决定方案能不能落地。希望这篇基于实战经验的梳理，能让你少走一些我曾经走过的弯路。