先放一个结论2PC和3PC的对比从来不只是“多一个阶段”那么简单。真正搞懂这两套协议你的分布式事务选型才算入了门。我先交代一下背景。我在做微服务架构和中间件落地的时候经常被问到两阶段提交和三阶段提交到底怎么选网上资料大多把流程画完了事但真正到了线上碰到协调者宕机、网络分区、连接池被占满才发现很多细节教科书根本没讲。这篇文章我会从协议原理、故障模型、工程落地三个层面把2PC和3PC掰开揉碎顺便把TCC和Saga也拉出来做一轮同台对比。适合正在做分布式事务选型、或者准备把Seata、XA这类方案引入项目的后端同学参考。1. 为什么需要分布式事务从单机到分布式的信任崩塌1.1 单机事务的惯性思维我们最开始学数据库的时候事务就是ACID四个字母begin、commit、rollback三件套。单体应用里所有数据都落在一个MySQL实例上事务由数据库自己管理binlog、redo log、undo log把原子性和持久性安排得明明白白。这个阶段没人讨论什么协调者、参与者因为数据库自己就是那个“唯一的话事人”。但分布式架构把这一切打散了。订单服务管订单表库存服务管库存表用户服务管用户余额。一次下单动作要同时扣库存、减余额、创建订单三个服务各自连各自的数据库本地事务只能保证自己那一亩三分地的原子性跨服务的原子性就没人管了。这个时候我们需要一个跨节点的“总导演”来协调所有人统一行动这就引出了分布式事务协议。1.2 分布式环境下的一致性问题分布式事务的核心矛盾是参与节点可能分布在不同的机器、不同的机房甚至不同的城市节点之间的通信会延迟、会丢包、会超时节点自身也可能宕机、卡顿、磁盘写满。在这些不稳定因素里要让大家要么全成功、要么全失败难度比单机事务大了一个量级。更麻烦的是分布式系统里有个著名的FLP不可能定理在异步网络里即使只有一个节点可能故障也不存在一个确定性算法能让所有节点达成一致。2PC和3PC都是在这个大背景下做的妥协和取舍它们不是银弹只是在不同约束条件下的“最优解”。1.3 2PC/3PC在整个事务家族中的位置业内提到的分布式事务方案大致可以分成两派。第一派是刚性事务派追求强一致性代表作就是2PC两阶段提交和3PC三阶段提交。它们的思路是把单机事务的提交过程拆成多个阶段由中心化的协调者统一推进。第二派是柔性事务派接受最终一致性代表作是TCCTry-Confirm-Cancel和Saga。它们不强求所有节点同时成功而是通过补偿机制让整个流程在最终某个时间点达到一致。2PC和3PC是协议级别的方案关注的是资源管理器与事务管理器之间的交互规范TCC和Saga更偏向业务层面的方案需要你在业务代码里显式实现正向操作和反向操作。理解了这层关系后面做选型才不容易乱。2. 2PC协议拆解一次跨越网络的集体表决2.1 两阶段到底做了什么2PC包含一个协调者Coordinator和一组参与者Participant整个事务分成两个阶段。第一阶段叫准备阶段Prepare Phase也叫投票阶段。协调者向所有参与者发送prepare请求参与者收到请求后执行本地事务的SQL操作把数据修改写入事务日志undo log和redo log但不提交commit。然后参与者向协调者回复“可以提交”Ready或者“不可以提交”Abort。第二阶段叫提交阶段Commit Phase也叫执行阶段。协调者汇总所有参与者的投票如果所有人都回复了Ready协调者就广播commit请求参与者收到后正式提交本地事务并释放锁和资源。如果有任何一个参与者回复了Abort或者协调者在超时时间内没收到某个参与者的回复协调者就广播abort请求所有参与者回滚本地事务。你把这个过程想象成一场线上会议主持人先挨个问“这个方案你们支持吗”大家各自表态只要有一票反对会议直接散场所有人按原计划来如果全票通过主持人再通知大家“按方案执行”大家才开始干活。2.2 阻塞点、单点与脑裂2PC看起来逻辑流畅但真正落地的时候有几个致命的软肋我一个个说。第一个是同步阻塞。在准备阶段参与者已经执行了事务操作但事务还没有提交所以资源锁、行锁、表锁全都握在手里不释放。如果协调者因为故障、网络抖动迟迟不发第二阶段的指令参与者只能一直等。数据库连接池里的连接被这些“悬而未决”的事务占用很快连接池就会被耗尽整个应用直接失去响应。我见过一个生产事故就是协调者进程OOM下游所有数据库连接全被占满最后只能手动kill掉挂起的事务。第二个是协调者单点。协调者如果崩溃了整个集群就没人来做最终决策。比这更糟的是如果协调者崩溃时已经发出了部分commit请求有些参与者收到了并提交了有些参与者没收到还在等待集群就进入了“谁也不知道该不该提交”的混沌状态。第三个是脑裂问题。网络分区会把集群分成两半协调者和部分参与者在一个分区里其他参与者在另一区里。协调者发出的commit指令分区外的参与者根本收不到它们只能一直阻塞。这时候如果强制让分区内的参与者提交全局数据就不一致了如果让分区外的参与者回滚又违反了“已经收到commit的参与者不能回滚”的协议约束。这些问题的根源在于2PC把“决策权”完全集中在了协调者一个人身上参与者没有在异常情况下自主决策的能力。2.3 2PC的真实落地XA、Seata AT与商业数据库2PC这个协议虽然原始但经过改良之后依然是工业界最广泛使用的分布式事务基础。第一类是数据库层面的XA协议。MySQL的XA、PostgreSQL的PREPARE TRANSACTION、Oracle的XA都是2PC的具体实现。XA把事务管理器TM和资源管理器RM标准化应用层通过TM驱动多个数据库完成两阶段提效。我在使用ShardingSphere时就经常看到XA事务的日志输出底层就是2PC那一套。第二类是Seata的AT模式。Seata AT在理念上借鉴了2PC但做了很多工程优化。AT模式通过数据源代理在业务SQL执行前后自动生成undo_log和快照第一阶段直接把数据提交掉第二阶段根据结果异步回滚或清理日志。它比标准2PC更激进的地方在于第一阶段不长时间占用数据库锁避免了同步阻塞的坑。但代价是要求每个数据库里都要有undo_log表并且对隔离级别有要求。所以严格来说Seata AT不是纯正的2PC而是“类2PC”的改良方案。第三类是商业分布式数据库。OceanBase、TiDB这类原生分布式数据库内部用多副本一致性协议Raft/Paxos管理分片同时在上层提供分布式事务能力。它们的事务协调器会综合2PC和共识算法的思路把“协调者”做成一个高可用的共识组解决了2PC协调者单点的问题。但在事务交互细节上你依然能看到prepare/commit的影子。3. 3PC协议拆解为“不阻塞”付出的代价3.1 从两阶段到三阶段的演进逻辑3PCThree-Phase Commit的提出就是为了解决2PC里参与者在异常情况下只能被动等待、不能自主决策的问题。它把2PC的“准备-提交”两步改造成了“CanCommit、PreCommit、DoCommit”三步。第一步CanCommit是询问阶段。协调者问所有参与者“你们这个事务能不能提交”这一步不执行任何SQL只是确认参与者的资源状态比如连接是否可用、事务是否开启成功。第二步PreCommit是预提交阶段。协调者收到所有参与者的“能提交”回复后广播preCommit请求。参与者收到后真正执行事务SQL写入事务日志然后返回ACK。注意这里依然没有提交但资源锁已经握住了。第三步DoCommit是最后提交阶段。协调者收到所有参与者的ACK后广播doCommit请求参与者正式提交并返回结果。3.2 3PC的超时自救机制3PC相比2PC最大的改进是引入了超时机制让参与者在等待协调者指令超时后可以自行决定下一步动作。具体来说参与者在收到preCommit指令并完成预提交后如果等待doCommit超时它会默认执行提交操作。这个设计基于一个假设既然协调者已经广播了preCommit说明所有节点都投了赞成票这时候大家统一提交的成功率是最高的。所以超时后自动提交比傻等协调者更合理。同理参与者如果在CanCommit阶段之后、PreCommit阶段之前等不到协调者的指令超时后会默认中止事务。因为在准备阶段还没真正动数据回滚的代价极低。这个超时自决机制让3PC在协调者挂掉或网络分区的时候不一定会像2PC那样无限阻塞。理论上它解决了2PC的“同步阻塞”问题——但这只是理论上后面我会讲它的新bug。3.3 3PC仍然解决不了的问题3PC的超时机制有一个隐藏的坑如果网络分区把协调者和一部分参与者隔开了协调者向已连接的那部分参与者发送了preCommit并向全体广播doCommit但消息被网络切断了那分区外的参与者只能在超时后自行抉择。这里有个致命场景分区外的参与者在PreCommit阶段超时后按照协议规则会自动回滚。但分区内的参与者已经收到preCommit并成功提交了。结果就是一部分节点提交了一部分节点回滚了全局数据不一致。这个问题的根源是3PC的“超时自动提交”假设在真实现网环境下并不总是成立。网络分区不是按节点参与者的“投票意愿”划分的协调者可能还没收集完ack就分区了也可能在脑裂后广播了互相矛盾的消息。因此大量并发论文的结论是3PC在“节点无故障、纯粹的网络分区”这种限定条件下可以做到非阻塞但一旦叠加节点故障它依然不能保证全局一致性。这也是为什么在实际生产系统里你很少看到纯3PC的落地实现。它更多是作为一致性协议演进中的一环出现在教材和论文里。很多Paxos和Raft的爱好者会告诉你共识算法比3PC更优雅地解决了一致性问题。4. 2PC与3PC的硬核对比4.1 协议行为对比表我直接做一个对比表把差异点列清楚对比维度2PC3PC阶段数量准备、提交两个阶段CanCommit、PreCommit、DoCommit三个阶段事务执行时机准备阶段执行SQL提交阶段提交CanCommit不执行SQLPreCommit执行SQLDoCommit提交参与者超时处理只能等不能自行提交或中止PreCommit后超时默认提交CanCommit后超时默认中止协调者故障影响全局阻塞等待新协调者恢复参与者可超时自决理论上更快恢复网络分区影响分区外参与者无限阻塞分区外参与者可能在超时后提交造成不一致数据一致性强度在无故障情况下严格一致在分区故障场景下有概率不一致工程落地难度有XA、Seata AT等成熟方案没有主流中间件直接原生实现适用场景短事务、参与方少、强一致要求高理论价值高实际工程参考其超时思想4.2 工程视角为什么3PC在实际系统中少见既然3PC在阻塞问题上比2PC“先进”为什么业界不拥抱它第一是它并没有完全解决一致性问题。它把阻塞问题改成了“提交结果不一致”问题这在很多业务场景里比阻塞更难以容忍。订单扣款这种场景你可以忍受短暂的系统无响应但不能忍受一个账户扣了钱另一个账户没收到。所以强一致场景里3PC的“超时自动提交”反而是个风险。第二是没有可靠的工程化基础设施。XA有数据库厂商支持Seata AT有全套监控和回滚方案而3PC在中间件层面几乎是空白。你如果想自己实现一个3PC协调器要处理消息丢失、重放、幂等、日志恢复、新协调者选举等一系列问题工作量远大于收益。第三是业界的调优方向已经走向了“共识算法 高可用协调者”路线。TiDB、OceanBase、Spanner这些真正要对外提供强一致分布式事务的系统用的都是基于Raft/Paxos的高可用协调者替代单点协调者配合2PC风格的提交流程。也就是说大家把2PC的“协调者”做成了不会挂的共识组而不是自己发明3PC。所以在我的工作经验里如果你的技术选型卡片上写的是“3PC”大概率还在纸面讨论阶段真正能落地的团队都会在2PC增强方案Seata AT、XA和业务柔性方案TCC、Saga之间举棋。4.3 什么时候可以借鉴3PC的思想虽说3PC不实用但它的超时决策思想在很多“半分布式事务”场景里被借用了。比如服务A调用服务BB处理完迟迟不返回结果A这边不能无限等。常见做法是设置一个合理的超时时间超时后A走降级策略比如标记失败、重试或者做本地补偿。这个“超时后不要傻等”的思路就是从3PC的“超时自决”里提炼出来的实践智慧。再比如分布式任务调度框架里的分片任务主节点下发任务给各分片分片执行完回报结果主节点如果超时未收到全部完成报告会重试分片。这种“主节点分片”的协调模式和3PC的超时决策思路异曲同工。你把3PC当成一种思维模型而不是协议本身反而更实用。5. 跳出两阶段TCC与Saga到底补了什么5.1 TCC的三步法与三大坑TCC这个名字你已经不陌生了但很多人没意识到它其实是一种“业务侵入式”的2PC改良方案。TCC把每个参与者的业务操作拆成三个动作Try校验并预留资源、Confirm确认提交、Cancel补偿回滚。拿电商下单举例。订单服务的Try阶段会创建一条状态为“待确认”的订单记录库存服务的Try阶段会冻结预占库存积分服务的Try阶段会给用户加一条积分变动流水但状态为“待生效”。所有Try都成功了再进入Confirm阶段把订单状态改成“已确认”、冻结库存扣减、积分流水生效。如果某个节点Try失败则执行所有节点的Cancel把已预留的资源释放掉。TCC的三大坑绝大多数团队踩过第一个是空回滚。Cancel操作可能出现在Try还没成功执行的情况下。比如Try请求因为网络超时协调者认为失败并发起Cancel但服务端实际上根本没执行Try。如果Cancel直接去回滚一个不存在的预留数据就会报错。所以Cancel里要做空回滚判断没有Try记录就直接成功返回。第二个是悬挂。Try请求在超时后被协调者判为取消但后来Try请求又到达服务端正常执行了这时候预留资源已经“悬挂”在那里没有对应的Confirm或Cancel去释放。解决思路是在Try和Cancel的入口处记录事务状态如果发现已有Cancel记录Try直接拒绝执行。第三个是幂等。Confirm和Cancel可能被重复调用网络重推、协调者重试都会触发重复请求。所以每个接口都要实现幂等控制通常用事务状态表唯一事务ID来保证。我实际用TCC比较多的时候发现一个技巧Try阶段尽可能做“预占型”的资源操作不要真的扣减真实数据Confirm阶段再做真正的扣减Cancel阶段做的所有操作必须是Try操作的可逆操作。这个原则能大幅降低空回滚和悬挂的概率。5.2 Saga的编排与补偿哲学Saga和TCC最大的不同在于它完全没有“预留”的概念。Saga把一个长事务拆成一组有顺序的本地交易每个本地交易都有对应的补偿交易。正向交易按顺序执行如果某个正向交易失败了就逆序遍历已经成功的交易逐个执行补偿交易把数据恢复到初始状态。订单系统里Saga的执行路径可能是创建订单 → 扣库存 → 扣余额。如果扣余额失败了就回滚扣库存、回滚创建订单。补偿动作是业务层面的反向操作可能是加回库存、删除订单而不是数据库层面的undo日志回滚。Saga有两种模式编排Choreography和编配Orchestration。编排模式是每个服务监听事件并触发下一个动作没有中心控制器适合流程固定、参与服务多的场景编配模式由一个Saga协调器统一控制执行顺序和补偿逻辑适合流程需要动态调整的场景。我个人在工程上更偏好编配模式因为流程可视化、故障定位容易代码维护成本也低。Saga最大的问题是缺乏隔离性。两个并发Saga操作同一份资源时可能互相读到对方的中间状态。一个Saga扣了库存还没补偿完另一个Saga已经看到库存减少了并开始下单。所以在资金、库存这类核心数据上Saga通常要和业务锁、状态机配合使用尽量别裸奔。5.3 四种方案同台对比一致性、可用性、吞吐、侵入性我把四种方案做一个横向对比对比维度2PC增强版3PCTCCSaga一致性强一致理论强一致分区下有分歧最终一致最终一致可用性协调者故障会阻塞参与者可自决可用性稍好不依赖长事务锁可用性高可用性高吞吐量低资源锁持有久低多一次网络交互中锁释放快中高无长锁业务侵入性低对业务透明很低高每个动作拆三份高要写补偿典型应用银行转账、账户扣款教材/论文电商下单、库存扣减旅行预订、长流程审批常见产品Seata AT、XA XA无主流实现Seata TCCSeata Saga、Eventuate这个表你多琢磨一下就能发现一个规律一致性、可用性、吞吐量、业务侵入性这四个维度是互相牵制的。2PC强一致但吞吐低、可能会阻塞TCC和Saga吞吐高、可用性好但要写大量补偿代码且一致性降级为最终一致。选型本质上是想清楚你愿意在哪里妥协。6. 事务选型实操我是怎么做的6.1 业务场景决定协议不是一个公式做选型之前先问业务团队三个问题。第一个问题这个操作允许出现中间状态吗比如转账用户A账户钱扣了用户B账户钱没到中间状态是不允许的哪怕只持续100毫秒用户体验也会炸。这种必须是强一致直接上2PC增强方案Seata AT或XA别考虑Saga。第二个问题单个事务的持续时间能控制在100毫秒到1秒吗如果每个节点的操作都是几个数据库查询加一个外呼API整个事务下来要好几秒那2PC的资源锁会折磨死人。这种场景更适合Saga或者TCC。第三个问题业务团队愿意花多少精力维护补偿逻辑如果只有两三个人维护一个老系统让他们把每个操作拆成Try/Confirm/Cancel三份工作量可能翻倍。这时候可以先选一个本地消息表异步方案或者干脆引入消息队列做最终一致性。我之前做过一个支付清结算系统账务模块用了Seata AT因为资金数据强一致不能妥协同一个系统里的优惠券发放用了Saga状态机因为允许“发了一部分券然后废券”这种最终一致状态。一个系统里混用两种方案并不丢人按模块隔离才是正确姿势。6.2 落地清单与团队协作建议方案定了以后我建议你先盘一下这四类基础设施事务管理中间件Seata、ShardingSphere、自研协调器必须选一个有可视化管理后台的方便排查挂起事务。日志与监控分布式事务的日志要打全事务ID、阶段、耗时、结果一个都不能少。我习惯在事务入口打一条trace日志在每个参与者完成阶段打一条debug日志排查问题的时候靠这个串联。数据库资源规划2PC场景下数据库连接池要给分布式事务预留buffer。连接池最大连接数、事务内连接占用时长、最大活跃事务数三个参数要联动调优不然一个慢事务就能拖垮整个连接池。超时与重试配置开事务的总超时时间建议设置为主链路RT的3到5倍比如正常50毫秒超时就给250毫秒。重试次数要结合参与者的幂等能力决定千万不要无限重试。团队协作上我强烈建议在业务需求阶段就把“此接口是否会跨服务写多份数据”作为一个评审点。很多分布式事务问题的根源是开发者在需求阶段没识别出来等上线了才发现有跨库操作。早一点在接口设计评审里引入这个检查项能省后面大量的返工。6.3 伪需求识别什么时候根本不需要分布式事务还有一种情况我得单独拎出来说很多时候你以为需要分布式事务实际上根本不需要。第一类伪需求是单库能搞定的事非要拆开。一个订单系统如果订单表、库存表、余额表都在同一个数据库里哪怕是同一个实例的不同库直接用本地事务就行了别为了微服务而微服务。第二类伪需求是可以用业务幂等解决的“多写”。比如两个系统之间用消息队列异步同步数据消费端只要实现幂等配合去重表就不需要引入事务协议了。加一张本地消息表把写库和发消息放在一个本地事务里再通过定时任务推送这是最简单可靠的方案。第三类伪需求是“看起来要一致实际允许延迟”。比如用户上传头像、更新昵称这种数据允许几秒的延迟根本不需要分布式事务丢一条消息出去异步更新就行。判断标准很简单如果这是一个用户无感知的异步流程或者短时间不一致可以被兜底任务修复就别碰分布式事务更别纠结2PC还是3PC。能用简单方案绝不上复杂方案这是我在生产环境里最深的体会。7. 常见问题与排查避坑实录7.1 协调者宕机之后怎么办2PC场景里协调者宕机是每套系统都会遇见的现实问题。恢复的核心在于协调者必须持久化事务状态日志把每个事务当前处于什么阶段写盘。宕机重启后协调者读取日志对“准备完成但尚未提交”的事务重新询问参与者状态再决定补发commit还是abort。我踩过一次坑协调者宕机后没有及时清理过期的分布式事务日志结果新事务启动时发现日志表无限膨胀拖慢了数据库性能。现在我的做法是协调者的状态日志表设置合理的清理策略超过30天的历史数据定期归档删除。如果协调者彻底起不来了那就得靠集群投票选举一个新协调者。新协调者要能读取旧协调者的事务状态记录并对所有参与者做一次状态同步。这里建议在中间件层开启自动选主功能避免人工介入导致的长时间业务中断。7.2 网络分区后的悬挂事务怎么处理网络抖动导致协调者和参与者之间的连接断开很容易出现悬挂事务参与者认为自己还在一个未完成的事务里但协调者已经把这个事务判定为失败并走了回滚流程两边的状态就错位了。处理方法是在参与者端引入事务状态表和最大等待时间。如果参与者发现某个事务超过了最大等待时间仍未收到协调者的下一次指令就主动去协调者查询该事务的最终状态。协调者如果也无法确认就需要人工或者异步任务介入对事务状态做对账补偿。我在生产环境里还见过一种更隐蔽的悬挂协调者发出prepare后网络断了但实际上所有参与者都执行了prepare并持有锁。这种悬挂事务如果一直等不到协调者消息数据库锁会越攒越多。建议把所有分布式事务都加一个“最长生命周期”超过30分钟就认定为悬挂事务走自动告警和人工作废流程。7.3 超时参数设置的坑超时设置太短容易把正常稍慢的事务误判为失败。超时设置太长故障恢复又要等很久。这两头都有人栽过跟头主要原因是只用了一个固定的全局超时没有结合具体业务链路动态调整。我的经验是按操作类型分别设置超时数据库本地操作的超时定在100毫秒左右一次远程调用RT在200毫秒内的整体事务超时给500毫秒涉及跨机房调用的超时放到1秒甚至更多。设置完成后要压测验证不能拍脑袋最好用全链路压测工具模拟高峰流量看看超时阈值能不能覆盖P99的延迟。超时触发的回滚动作也有讲究回滚动作本身可能会因为网络问题再失败所以回滚操作要做重试和幂等否则事务状态会卡在“已回滚”和“未回滚”的灰色地带。7.4 一些容易被忽略的工程细节最后分享几个我经常遇到、但很多人没在教材里看到的细节每个都是踩过的坑。先说行锁升级问题。2PC第一阶段会持锁但如果某个参与者的SQL用了全表扫描行锁就会升级成表锁整个表被锁住对线上影响极大。所以在分布式事务涉及的SQL上一定要确保走索引避免锁升级。再说连接池水位。Seata AT模式虽然相比纯2PC减少了锁释放时间但第一阶段结束后连接并没有立刻归还。我在实践中特意把数据源的连接池最大连接数调大了20%到30%给分布式事务留出buffer。没有这个预留流量高峰一来连接池直接被事务占满业务就雪崩了。还有一个是本地异步任务的时序问题。分布式事务的回滚经常由后台定时任务触发这些任务和业务高峰重叠时会对数据库造成很大的瞬时压力。我习惯把回滚任务调度在业务低峰期或者做分批处理一次只回滚固定条数避免洪峰叠加。最后一个细节分布式事务中间件的版本升级一定要先在灰度环境把事务耗时、回滚成功率这些指标测一遍再上生产。很多看似无关的升级比如框架依赖的序列化方式变更都可能让回滚日志的解析逻辑出问题进而导致回滚失败。我自己在分布式事务上走过的弯路不少。最早用纯手写XA后来切到Seata AT再后来业务线引入了大量长流程又把TCC和Saga加了进来。过程里最深刻的体会是分布式事务没有一个“万能药”每一种方案都是一个权衡关键是你要清楚自己的业务在什么维度上不能妥协。如果你现在的业务要强一致、事务短、参与方少那就踏踏实实用2PC增强方案别被那些“3PC更高级”的说法忽悠如果你的业务允许最终一致、操作链路长那TCC和Saga才是你真正值得投入的方向。多去线上一线看看那些挂起的事务、爆掉的连接池你会比背一百遍协议流程都更有收获。
2PC与3PC深度对比：分布式事务选型的关键差异与工程实践
先放一个结论2PC和3PC的对比从来不只是“多一个阶段”那么简单。真正搞懂这两套协议你的分布式事务选型才算入了门。我先交代一下背景。我在做微服务架构和中间件落地的时候经常被问到两阶段提交和三阶段提交到底怎么选网上资料大多把流程画完了事但真正到了线上碰到协调者宕机、网络分区、连接池被占满才发现很多细节教科书根本没讲。这篇文章我会从协议原理、故障模型、工程落地三个层面把2PC和3PC掰开揉碎顺便把TCC和Saga也拉出来做一轮同台对比。适合正在做分布式事务选型、或者准备把Seata、XA这类方案引入项目的后端同学参考。1. 为什么需要分布式事务从单机到分布式的信任崩塌1.1 单机事务的惯性思维我们最开始学数据库的时候事务就是ACID四个字母begin、commit、rollback三件套。单体应用里所有数据都落在一个MySQL实例上事务由数据库自己管理binlog、redo log、undo log把原子性和持久性安排得明明白白。这个阶段没人讨论什么协调者、参与者因为数据库自己就是那个“唯一的话事人”。但分布式架构把这一切打散了。订单服务管订单表库存服务管库存表用户服务管用户余额。一次下单动作要同时扣库存、减余额、创建订单三个服务各自连各自的数据库本地事务只能保证自己那一亩三分地的原子性跨服务的原子性就没人管了。这个时候我们需要一个跨节点的“总导演”来协调所有人统一行动这就引出了分布式事务协议。1.2 分布式环境下的一致性问题分布式事务的核心矛盾是参与节点可能分布在不同的机器、不同的机房甚至不同的城市节点之间的通信会延迟、会丢包、会超时节点自身也可能宕机、卡顿、磁盘写满。在这些不稳定因素里要让大家要么全成功、要么全失败难度比单机事务大了一个量级。更麻烦的是分布式系统里有个著名的FLP不可能定理在异步网络里即使只有一个节点可能故障也不存在一个确定性算法能让所有节点达成一致。2PC和3PC都是在这个大背景下做的妥协和取舍它们不是银弹只是在不同约束条件下的“最优解”。1.3 2PC/3PC在整个事务家族中的位置业内提到的分布式事务方案大致可以分成两派。第一派是刚性事务派追求强一致性代表作就是2PC两阶段提交和3PC三阶段提交。它们的思路是把单机事务的提交过程拆成多个阶段由中心化的协调者统一推进。第二派是柔性事务派接受最终一致性代表作是TCCTry-Confirm-Cancel和Saga。它们不强求所有节点同时成功而是通过补偿机制让整个流程在最终某个时间点达到一致。2PC和3PC是协议级别的方案关注的是资源管理器与事务管理器之间的交互规范TCC和Saga更偏向业务层面的方案需要你在业务代码里显式实现正向操作和反向操作。理解了这层关系后面做选型才不容易乱。2. 2PC协议拆解一次跨越网络的集体表决2.1 两阶段到底做了什么2PC包含一个协调者Coordinator和一组参与者Participant整个事务分成两个阶段。第一阶段叫准备阶段Prepare Phase也叫投票阶段。协调者向所有参与者发送prepare请求参与者收到请求后执行本地事务的SQL操作把数据修改写入事务日志undo log和redo log但不提交commit。然后参与者向协调者回复“可以提交”Ready或者“不可以提交”Abort。第二阶段叫提交阶段Commit Phase也叫执行阶段。协调者汇总所有参与者的投票如果所有人都回复了Ready协调者就广播commit请求参与者收到后正式提交本地事务并释放锁和资源。如果有任何一个参与者回复了Abort或者协调者在超时时间内没收到某个参与者的回复协调者就广播abort请求所有参与者回滚本地事务。你把这个过程想象成一场线上会议主持人先挨个问“这个方案你们支持吗”大家各自表态只要有一票反对会议直接散场所有人按原计划来如果全票通过主持人再通知大家“按方案执行”大家才开始干活。2.2 阻塞点、单点与脑裂2PC看起来逻辑流畅但真正落地的时候有几个致命的软肋我一个个说。第一个是同步阻塞。在准备阶段参与者已经执行了事务操作但事务还没有提交所以资源锁、行锁、表锁全都握在手里不释放。如果协调者因为故障、网络抖动迟迟不发第二阶段的指令参与者只能一直等。数据库连接池里的连接被这些“悬而未决”的事务占用很快连接池就会被耗尽整个应用直接失去响应。我见过一个生产事故就是协调者进程OOM下游所有数据库连接全被占满最后只能手动kill掉挂起的事务。第二个是协调者单点。协调者如果崩溃了整个集群就没人来做最终决策。比这更糟的是如果协调者崩溃时已经发出了部分commit请求有些参与者收到了并提交了有些参与者没收到还在等待集群就进入了“谁也不知道该不该提交”的混沌状态。第三个是脑裂问题。网络分区会把集群分成两半协调者和部分参与者在一个分区里其他参与者在另一区里。协调者发出的commit指令分区外的参与者根本收不到它们只能一直阻塞。这时候如果强制让分区内的参与者提交全局数据就不一致了如果让分区外的参与者回滚又违反了“已经收到commit的参与者不能回滚”的协议约束。这些问题的根源在于2PC把“决策权”完全集中在了协调者一个人身上参与者没有在异常情况下自主决策的能力。2.3 2PC的真实落地XA、Seata AT与商业数据库2PC这个协议虽然原始但经过改良之后依然是工业界最广泛使用的分布式事务基础。第一类是数据库层面的XA协议。MySQL的XA、PostgreSQL的PREPARE TRANSACTION、Oracle的XA都是2PC的具体实现。XA把事务管理器TM和资源管理器RM标准化应用层通过TM驱动多个数据库完成两阶段提效。我在使用ShardingSphere时就经常看到XA事务的日志输出底层就是2PC那一套。第二类是Seata的AT模式。Seata AT在理念上借鉴了2PC但做了很多工程优化。AT模式通过数据源代理在业务SQL执行前后自动生成undo_log和快照第一阶段直接把数据提交掉第二阶段根据结果异步回滚或清理日志。它比标准2PC更激进的地方在于第一阶段不长时间占用数据库锁避免了同步阻塞的坑。但代价是要求每个数据库里都要有undo_log表并且对隔离级别有要求。所以严格来说Seata AT不是纯正的2PC而是“类2PC”的改良方案。第三类是商业分布式数据库。OceanBase、TiDB这类原生分布式数据库内部用多副本一致性协议Raft/Paxos管理分片同时在上层提供分布式事务能力。它们的事务协调器会综合2PC和共识算法的思路把“协调者”做成一个高可用的共识组解决了2PC协调者单点的问题。但在事务交互细节上你依然能看到prepare/commit的影子。3. 3PC协议拆解为“不阻塞”付出的代价3.1 从两阶段到三阶段的演进逻辑3PCThree-Phase Commit的提出就是为了解决2PC里参与者在异常情况下只能被动等待、不能自主决策的问题。它把2PC的“准备-提交”两步改造成了“CanCommit、PreCommit、DoCommit”三步。第一步CanCommit是询问阶段。协调者问所有参与者“你们这个事务能不能提交”这一步不执行任何SQL只是确认参与者的资源状态比如连接是否可用、事务是否开启成功。第二步PreCommit是预提交阶段。协调者收到所有参与者的“能提交”回复后广播preCommit请求。参与者收到后真正执行事务SQL写入事务日志然后返回ACK。注意这里依然没有提交但资源锁已经握住了。第三步DoCommit是最后提交阶段。协调者收到所有参与者的ACK后广播doCommit请求参与者正式提交并返回结果。3.2 3PC的超时自救机制3PC相比2PC最大的改进是引入了超时机制让参与者在等待协调者指令超时后可以自行决定下一步动作。具体来说参与者在收到preCommit指令并完成预提交后如果等待doCommit超时它会默认执行提交操作。这个设计基于一个假设既然协调者已经广播了preCommit说明所有节点都投了赞成票这时候大家统一提交的成功率是最高的。所以超时后自动提交比傻等协调者更合理。同理参与者如果在CanCommit阶段之后、PreCommit阶段之前等不到协调者的指令超时后会默认中止事务。因为在准备阶段还没真正动数据回滚的代价极低。这个超时自决机制让3PC在协调者挂掉或网络分区的时候不一定会像2PC那样无限阻塞。理论上它解决了2PC的“同步阻塞”问题——但这只是理论上后面我会讲它的新bug。3.3 3PC仍然解决不了的问题3PC的超时机制有一个隐藏的坑如果网络分区把协调者和一部分参与者隔开了协调者向已连接的那部分参与者发送了preCommit并向全体广播doCommit但消息被网络切断了那分区外的参与者只能在超时后自行抉择。这里有个致命场景分区外的参与者在PreCommit阶段超时后按照协议规则会自动回滚。但分区内的参与者已经收到preCommit并成功提交了。结果就是一部分节点提交了一部分节点回滚了全局数据不一致。这个问题的根源是3PC的“超时自动提交”假设在真实现网环境下并不总是成立。网络分区不是按节点参与者的“投票意愿”划分的协调者可能还没收集完ack就分区了也可能在脑裂后广播了互相矛盾的消息。因此大量并发论文的结论是3PC在“节点无故障、纯粹的网络分区”这种限定条件下可以做到非阻塞但一旦叠加节点故障它依然不能保证全局一致性。这也是为什么在实际生产系统里你很少看到纯3PC的落地实现。它更多是作为一致性协议演进中的一环出现在教材和论文里。很多Paxos和Raft的爱好者会告诉你共识算法比3PC更优雅地解决了一致性问题。4. 2PC与3PC的硬核对比4.1 协议行为对比表我直接做一个对比表把差异点列清楚对比维度2PC3PC阶段数量准备、提交两个阶段CanCommit、PreCommit、DoCommit三个阶段事务执行时机准备阶段执行SQL提交阶段提交CanCommit不执行SQLPreCommit执行SQLDoCommit提交参与者超时处理只能等不能自行提交或中止PreCommit后超时默认提交CanCommit后超时默认中止协调者故障影响全局阻塞等待新协调者恢复参与者可超时自决理论上更快恢复网络分区影响分区外参与者无限阻塞分区外参与者可能在超时后提交造成不一致数据一致性强度在无故障情况下严格一致在分区故障场景下有概率不一致工程落地难度有XA、Seata AT等成熟方案没有主流中间件直接原生实现适用场景短事务、参与方少、强一致要求高理论价值高实际工程参考其超时思想4.2 工程视角为什么3PC在实际系统中少见既然3PC在阻塞问题上比2PC“先进”为什么业界不拥抱它第一是它并没有完全解决一致性问题。它把阻塞问题改成了“提交结果不一致”问题这在很多业务场景里比阻塞更难以容忍。订单扣款这种场景你可以忍受短暂的系统无响应但不能忍受一个账户扣了钱另一个账户没收到。所以强一致场景里3PC的“超时自动提交”反而是个风险。第二是没有可靠的工程化基础设施。XA有数据库厂商支持Seata AT有全套监控和回滚方案而3PC在中间件层面几乎是空白。你如果想自己实现一个3PC协调器要处理消息丢失、重放、幂等、日志恢复、新协调者选举等一系列问题工作量远大于收益。第三是业界的调优方向已经走向了“共识算法 高可用协调者”路线。TiDB、OceanBase、Spanner这些真正要对外提供强一致分布式事务的系统用的都是基于Raft/Paxos的高可用协调者替代单点协调者配合2PC风格的提交流程。也就是说大家把2PC的“协调者”做成了不会挂的共识组而不是自己发明3PC。所以在我的工作经验里如果你的技术选型卡片上写的是“3PC”大概率还在纸面讨论阶段真正能落地的团队都会在2PC增强方案Seata AT、XA和业务柔性方案TCC、Saga之间举棋。4.3 什么时候可以借鉴3PC的思想虽说3PC不实用但它的超时决策思想在很多“半分布式事务”场景里被借用了。比如服务A调用服务BB处理完迟迟不返回结果A这边不能无限等。常见做法是设置一个合理的超时时间超时后A走降级策略比如标记失败、重试或者做本地补偿。这个“超时后不要傻等”的思路就是从3PC的“超时自决”里提炼出来的实践智慧。再比如分布式任务调度框架里的分片任务主节点下发任务给各分片分片执行完回报结果主节点如果超时未收到全部完成报告会重试分片。这种“主节点分片”的协调模式和3PC的超时决策思路异曲同工。你把3PC当成一种思维模型而不是协议本身反而更实用。5. 跳出两阶段TCC与Saga到底补了什么5.1 TCC的三步法与三大坑TCC这个名字你已经不陌生了但很多人没意识到它其实是一种“业务侵入式”的2PC改良方案。TCC把每个参与者的业务操作拆成三个动作Try校验并预留资源、Confirm确认提交、Cancel补偿回滚。拿电商下单举例。订单服务的Try阶段会创建一条状态为“待确认”的订单记录库存服务的Try阶段会冻结预占库存积分服务的Try阶段会给用户加一条积分变动流水但状态为“待生效”。所有Try都成功了再进入Confirm阶段把订单状态改成“已确认”、冻结库存扣减、积分流水生效。如果某个节点Try失败则执行所有节点的Cancel把已预留的资源释放掉。TCC的三大坑绝大多数团队踩过第一个是空回滚。Cancel操作可能出现在Try还没成功执行的情况下。比如Try请求因为网络超时协调者认为失败并发起Cancel但服务端实际上根本没执行Try。如果Cancel直接去回滚一个不存在的预留数据就会报错。所以Cancel里要做空回滚判断没有Try记录就直接成功返回。第二个是悬挂。Try请求在超时后被协调者判为取消但后来Try请求又到达服务端正常执行了这时候预留资源已经“悬挂”在那里没有对应的Confirm或Cancel去释放。解决思路是在Try和Cancel的入口处记录事务状态如果发现已有Cancel记录Try直接拒绝执行。第三个是幂等。Confirm和Cancel可能被重复调用网络重推、协调者重试都会触发重复请求。所以每个接口都要实现幂等控制通常用事务状态表唯一事务ID来保证。我实际用TCC比较多的时候发现一个技巧Try阶段尽可能做“预占型”的资源操作不要真的扣减真实数据Confirm阶段再做真正的扣减Cancel阶段做的所有操作必须是Try操作的可逆操作。这个原则能大幅降低空回滚和悬挂的概率。5.2 Saga的编排与补偿哲学Saga和TCC最大的不同在于它完全没有“预留”的概念。Saga把一个长事务拆成一组有顺序的本地交易每个本地交易都有对应的补偿交易。正向交易按顺序执行如果某个正向交易失败了就逆序遍历已经成功的交易逐个执行补偿交易把数据恢复到初始状态。订单系统里Saga的执行路径可能是创建订单 → 扣库存 → 扣余额。如果扣余额失败了就回滚扣库存、回滚创建订单。补偿动作是业务层面的反向操作可能是加回库存、删除订单而不是数据库层面的undo日志回滚。Saga有两种模式编排Choreography和编配Orchestration。编排模式是每个服务监听事件并触发下一个动作没有中心控制器适合流程固定、参与服务多的场景编配模式由一个Saga协调器统一控制执行顺序和补偿逻辑适合流程需要动态调整的场景。我个人在工程上更偏好编配模式因为流程可视化、故障定位容易代码维护成本也低。Saga最大的问题是缺乏隔离性。两个并发Saga操作同一份资源时可能互相读到对方的中间状态。一个Saga扣了库存还没补偿完另一个Saga已经看到库存减少了并开始下单。所以在资金、库存这类核心数据上Saga通常要和业务锁、状态机配合使用尽量别裸奔。5.3 四种方案同台对比一致性、可用性、吞吐、侵入性我把四种方案做一个横向对比对比维度2PC增强版3PCTCCSaga一致性强一致理论强一致分区下有分歧最终一致最终一致可用性协调者故障会阻塞参与者可自决可用性稍好不依赖长事务锁可用性高可用性高吞吐量低资源锁持有久低多一次网络交互中锁释放快中高无长锁业务侵入性低对业务透明很低高每个动作拆三份高要写补偿典型应用银行转账、账户扣款教材/论文电商下单、库存扣减旅行预订、长流程审批常见产品Seata AT、XA XA无主流实现Seata TCCSeata Saga、Eventuate这个表你多琢磨一下就能发现一个规律一致性、可用性、吞吐量、业务侵入性这四个维度是互相牵制的。2PC强一致但吞吐低、可能会阻塞TCC和Saga吞吐高、可用性好但要写大量补偿代码且一致性降级为最终一致。选型本质上是想清楚你愿意在哪里妥协。6. 事务选型实操我是怎么做的6.1 业务场景决定协议不是一个公式做选型之前先问业务团队三个问题。第一个问题这个操作允许出现中间状态吗比如转账用户A账户钱扣了用户B账户钱没到中间状态是不允许的哪怕只持续100毫秒用户体验也会炸。这种必须是强一致直接上2PC增强方案Seata AT或XA别考虑Saga。第二个问题单个事务的持续时间能控制在100毫秒到1秒吗如果每个节点的操作都是几个数据库查询加一个外呼API整个事务下来要好几秒那2PC的资源锁会折磨死人。这种场景更适合Saga或者TCC。第三个问题业务团队愿意花多少精力维护补偿逻辑如果只有两三个人维护一个老系统让他们把每个操作拆成Try/Confirm/Cancel三份工作量可能翻倍。这时候可以先选一个本地消息表异步方案或者干脆引入消息队列做最终一致性。我之前做过一个支付清结算系统账务模块用了Seata AT因为资金数据强一致不能妥协同一个系统里的优惠券发放用了Saga状态机因为允许“发了一部分券然后废券”这种最终一致状态。一个系统里混用两种方案并不丢人按模块隔离才是正确姿势。6.2 落地清单与团队协作建议方案定了以后我建议你先盘一下这四类基础设施事务管理中间件Seata、ShardingSphere、自研协调器必须选一个有可视化管理后台的方便排查挂起事务。日志与监控分布式事务的日志要打全事务ID、阶段、耗时、结果一个都不能少。我习惯在事务入口打一条trace日志在每个参与者完成阶段打一条debug日志排查问题的时候靠这个串联。数据库资源规划2PC场景下数据库连接池要给分布式事务预留buffer。连接池最大连接数、事务内连接占用时长、最大活跃事务数三个参数要联动调优不然一个慢事务就能拖垮整个连接池。超时与重试配置开事务的总超时时间建议设置为主链路RT的3到5倍比如正常50毫秒超时就给250毫秒。重试次数要结合参与者的幂等能力决定千万不要无限重试。团队协作上我强烈建议在业务需求阶段就把“此接口是否会跨服务写多份数据”作为一个评审点。很多分布式事务问题的根源是开发者在需求阶段没识别出来等上线了才发现有跨库操作。早一点在接口设计评审里引入这个检查项能省后面大量的返工。6.3 伪需求识别什么时候根本不需要分布式事务还有一种情况我得单独拎出来说很多时候你以为需要分布式事务实际上根本不需要。第一类伪需求是单库能搞定的事非要拆开。一个订单系统如果订单表、库存表、余额表都在同一个数据库里哪怕是同一个实例的不同库直接用本地事务就行了别为了微服务而微服务。第二类伪需求是可以用业务幂等解决的“多写”。比如两个系统之间用消息队列异步同步数据消费端只要实现幂等配合去重表就不需要引入事务协议了。加一张本地消息表把写库和发消息放在一个本地事务里再通过定时任务推送这是最简单可靠的方案。第三类伪需求是“看起来要一致实际允许延迟”。比如用户上传头像、更新昵称这种数据允许几秒的延迟根本不需要分布式事务丢一条消息出去异步更新就行。判断标准很简单如果这是一个用户无感知的异步流程或者短时间不一致可以被兜底任务修复就别碰分布式事务更别纠结2PC还是3PC。能用简单方案绝不上复杂方案这是我在生产环境里最深的体会。7. 常见问题与排查避坑实录7.1 协调者宕机之后怎么办2PC场景里协调者宕机是每套系统都会遇见的现实问题。恢复的核心在于协调者必须持久化事务状态日志把每个事务当前处于什么阶段写盘。宕机重启后协调者读取日志对“准备完成但尚未提交”的事务重新询问参与者状态再决定补发commit还是abort。我踩过一次坑协调者宕机后没有及时清理过期的分布式事务日志结果新事务启动时发现日志表无限膨胀拖慢了数据库性能。现在我的做法是协调者的状态日志表设置合理的清理策略超过30天的历史数据定期归档删除。如果协调者彻底起不来了那就得靠集群投票选举一个新协调者。新协调者要能读取旧协调者的事务状态记录并对所有参与者做一次状态同步。这里建议在中间件层开启自动选主功能避免人工介入导致的长时间业务中断。7.2 网络分区后的悬挂事务怎么处理网络抖动导致协调者和参与者之间的连接断开很容易出现悬挂事务参与者认为自己还在一个未完成的事务里但协调者已经把这个事务判定为失败并走了回滚流程两边的状态就错位了。处理方法是在参与者端引入事务状态表和最大等待时间。如果参与者发现某个事务超过了最大等待时间仍未收到协调者的下一次指令就主动去协调者查询该事务的最终状态。协调者如果也无法确认就需要人工或者异步任务介入对事务状态做对账补偿。我在生产环境里还见过一种更隐蔽的悬挂协调者发出prepare后网络断了但实际上所有参与者都执行了prepare并持有锁。这种悬挂事务如果一直等不到协调者消息数据库锁会越攒越多。建议把所有分布式事务都加一个“最长生命周期”超过30分钟就认定为悬挂事务走自动告警和人工作废流程。7.3 超时参数设置的坑超时设置太短容易把正常稍慢的事务误判为失败。超时设置太长故障恢复又要等很久。这两头都有人栽过跟头主要原因是只用了一个固定的全局超时没有结合具体业务链路动态调整。我的经验是按操作类型分别设置超时数据库本地操作的超时定在100毫秒左右一次远程调用RT在200毫秒内的整体事务超时给500毫秒涉及跨机房调用的超时放到1秒甚至更多。设置完成后要压测验证不能拍脑袋最好用全链路压测工具模拟高峰流量看看超时阈值能不能覆盖P99的延迟。超时触发的回滚动作也有讲究回滚动作本身可能会因为网络问题再失败所以回滚操作要做重试和幂等否则事务状态会卡在“已回滚”和“未回滚”的灰色地带。7.4 一些容易被忽略的工程细节最后分享几个我经常遇到、但很多人没在教材里看到的细节每个都是踩过的坑。先说行锁升级问题。2PC第一阶段会持锁但如果某个参与者的SQL用了全表扫描行锁就会升级成表锁整个表被锁住对线上影响极大。所以在分布式事务涉及的SQL上一定要确保走索引避免锁升级。再说连接池水位。Seata AT模式虽然相比纯2PC减少了锁释放时间但第一阶段结束后连接并没有立刻归还。我在实践中特意把数据源的连接池最大连接数调大了20%到30%给分布式事务留出buffer。没有这个预留流量高峰一来连接池直接被事务占满业务就雪崩了。还有一个是本地异步任务的时序问题。分布式事务的回滚经常由后台定时任务触发这些任务和业务高峰重叠时会对数据库造成很大的瞬时压力。我习惯把回滚任务调度在业务低峰期或者做分批处理一次只回滚固定条数避免洪峰叠加。最后一个细节分布式事务中间件的版本升级一定要先在灰度环境把事务耗时、回滚成功率这些指标测一遍再上生产。很多看似无关的升级比如框架依赖的序列化方式变更都可能让回滚日志的解析逻辑出问题进而导致回滚失败。我自己在分布式事务上走过的弯路不少。最早用纯手写XA后来切到Seata AT再后来业务线引入了大量长流程又把TCC和Saga加了进来。过程里最深刻的体会是分布式事务没有一个“万能药”每一种方案都是一个权衡关键是你要清楚自己的业务在什么维度上不能妥协。如果你现在的业务要强一致、事务短、参与方少那就踏踏实实用2PC增强方案别被那些“3PC更高级”的说法忽悠如果你的业务允许最终一致、操作链路长那TCC和Saga才是你真正值得投入的方向。多去线上一线看看那些挂起的事务、爆掉的连接池你会比背一百遍协议流程都更有收获。
