假设一个场景线上一个用户下单余额扣了、库存也扣了订单却显示未支付。排查到最后是订单库、账户库、库存库三个库各改各的谁也管不了谁。这是分布式事务上的第一课跨库操作没有本地事务兜底出问题只是早晚的事。一、一个扣款场景把问题逼出来分布式事务要解决的不是”一次操作改多个地方”而是”多个地方要么同时成功、要么同时失败”。本地事务Local Transaction在同一个数据库内完成的事务要么全部提交要么全部回滚。你可以理解为”同一本账本上的记录错了一整页都能涂掉重写”。用生活里的场景类比三个人合租住在 1 楼、3 楼、5 楼晚上要同时关灯得挨个通知。只要中间有一层没听到就有一个人摸黑进门。跨库操作就是这种”挨个通知”的活而本地事务只会管自己那盏灯。分布式事务Distributed Transaction跨越多个数据库或服务的操作集合要求所有参与方要么一起成功、要么一起回滚。你可以理解为”几本分处各地的账本想在同一时刻改对”。这篇文章我打算把分布式事务从原理到落地串一遍先看 CAP 定理为什么让这条路这么难走再看 BASE 理论给出的妥协方案最后对比 AT 模式和 TCC 模式这两种主流实现以及它们各自的坑。收藏一下我们开始。二、CAP定理分布式系统的天花板在 CAP 定理里分区容错是必选项一致性和可用性只能二选一。CAP 定理Consistency, Availability, Partition tolerance分布式系统不可能同时满足一致性、可用性、分区容错性最多同时保证其中两个。你可以理解为”酒店的地点、价格、房间大小最多让你挑两个满意”。三个指标拆开看1一致性Consistency用户访问任意节点读到的数据必须一样。node01 改了余额node02 必须跟着变否则用户换个节点就查到旧账。2可用性Availability读或写总能成功。只能读不能写、只能写不能读或者都执行不了都算弱可用或不可用。3分区容错Partition tolerance节点之间的网络断了系统也要继续对外服务。Partition 就是网络故障把系统劈成几个互不相通的”孤岛”。关键矛盾在这网络不会 100% 保证畅通分区一定会出现而系统又必须持续运行。所以分区容错是硬指标所有分布式系统都得满足。剩下的只能在一致性和可用性里挑一个选可用性AP节点继续读写但同步不了的节点数据不一致事后靠补偿慢慢收敛。选一致性CP把数据锁住等网络恢复再放行期间系统不可用或只能读。现实就是这么不讲道理——只要网络会断你就得在 A 和 C 之间二选一。把取舍画成流程图一眼就能看懂。看图 1网络分区一旦出现往左走是 AP数据先乱一阵再收敛往右走是 CP先锁住不动一致但不可用。三、BASE理论不强一致但最终一致BASE 理论放弃的不是一致性而是强一致性——把”必须立刻一致”换成”最后一致就行”。BASE 理论Basically Available, Soft State, Eventually Consistent分布式系统允许损失部分可用性、出现中间状态最终把数据收敛到一致。你可以理解为”先把事办了睡前保证把账平掉”。三个词各管一段基本可用Basically Available出故障时损失部分可用性保住核心功能。抢购高峰让你排队等一会儿而不是直接 502。软状态Soft State允许存在中间状态比如数据暂时对不上。最终一致性Eventually Consistent不要求立刻一致但中间状态结束之后数据最终会一致。顺着 BASE 的思路分布式事务的解法分成两个方向AP 思想各分支各自执行、各自提交不锁数据。允许结果不一致之后用补偿手段恢复实现最终一致性。AT 模式走这条路。CP 思想各分支执行完先不提交等彼此的提交结果再一起提交或回滚。期间锁住资源数据不可用但保证一致。XA 模式走这条路。所以分布式事务从来没有”一种标准答案”关键是先想清楚你打算牺牲一致性还是可用性四、AT模式框架帮你补偿但别忽视脏写AT 模式最大的卖点是不用写补偿代码代价是并发场景下容易踩脏写的坑。AT 模式Automatic TransactionSeata 提供的一种分布式事务实现利用数据快照自动回滚开发者几乎无感。你可以理解为”系统定期给你的数据拍照出事就按照片恢复”。坦白讲我最早就是无脑选了 AT 模式因为它接入成本最低几个注解就搞定。它分两个阶段走阶段一每个分支事务执行前先记录数据快照再正常执行、正常提交。阶段二全局协调者汇总各分支的结果——全部成功说明事务在阶段一已经提交完了这里只需要删掉快照只要有分支失败就按快照把数据恢复到更新前再删快照。这个两阶段流程用文字说容易绕看图 2重点看阶段二的两个出口。大多数场景下AT 模式确实省心。但在极端情况尤其是多线程并发访问同一个 AT 事务里的数据时会出现脏写——某个分支回滚把另一个事务刚写入的新值一并覆盖回旧值了。两个线程同时改同一条库存记录一个事务回滚另一个线程刚提交的新值被快照覆盖账又对不上。排查了整整一天最后锁定位在脏写。好家伙快照回滚居然能滚出脏数据这谁能想到解决办法是引入全局锁在分支释放数据库锁之前先拿到全局锁保证同一时刻只有一个事务能操作这条数据回滚时就不会踩到别人刚写的东西。可能有人会问AT 模式加了全局锁并发性能不就废了吗这就是取舍。全局锁把冲突行的并发度压到 1多个线程抢同一行时吞吐明显下降。以我现在的经验写冲突不严重、读多写少的业务用 AT 很划算写热点集中的场景老老实实考虑 TCC 或者 消息队列。五、TCC模式补偿逻辑自己写更可控TCC 模式牺牲了编码量换来的是对补偿过程的完全掌控适合高并发和补偿逻辑复杂的业务。TCC 模式Try-Confirm-Cancel把分布式事务拆成预留、确认、取消三个阶段三个方法都由开发者手写。你可以理解为”先交定金把东西占住再付尾款反悔了就退定金”。三个方法各管一件事try检查并预留资源。比如检查余额够不够够就先把要扣的金额冻结起来。confirm真正完成业务。前提是 try 成功了confirm 一定要能成功——confirm 里只放不会失败的收尾动作。cancel释放预留的资源是 try 的反向操作。用一个扣款例子串一遍。账户 A 余额 100要扣 301Try余额充足冻结 30可用余额变 70。此时总余额冻结 可用还是 100分支事务直接提交不用等别的分支。2Confirm可用余额已经扣过了直接把冻结的 30 划走总余额变 70。3Cancel释放冻结冻结的 30 归零可用余额回到 100。TCC 的核心思想一句话就能讲透扣款不直接扣先锁进一个”冻结”口袋。看图 4 会更直观。但 TCC 的坑也藏在手写逻辑里。一个分布式事务里有两个分支try 阶段分支 A 成功、分支 B 阻塞。阻塞太久全局事务超时二阶段 cancel 触发两个分支都要执行 cancel——可分支 B 压根没执行过 try。空回滚Empty Rollback分支事务还没执行 try 就被要求 cancel此时 cancel 必须什么都不做。你可以理解为”客人还没进店店员就开始退他定金了”。更麻烦的是分支 B 的 try 阻塞结束后还会继续执行——但全局事务已经结束了永远不会有 confirm 或 cancel 再来。这个事务只执行了一半悬在那里事务悬挂Transaction Suspension分支的 try 被阻塞全局事务已超时结束阻塞结束后 try 才执行整个事务永远收不了尾。你可以理解为”主人全家都出门了客人还站在门口按门铃”。try 还没执行cancel 先到了主人走了客人还在门口。这两个问题不处理线上迟早出事。好在解法也明确写 try 和 cancel 时维护一张事务状态表。只有 try 成功记录过cancel 才允许真正回滚try 执行前先查状态确认全局事务还活着再动手。六、怎么选没有银弹只有取舍分布式事务没有银弹选方案的本质是选”你能接受哪方面的损失”。方案补偿方式代码量并发表现适合场景XACP数据库两阶段提交低低锁资源金融级强一致AT 模式AP框架快照自动回滚低中常规业务快速接入TCC 模式AP手写 try/confirm/cancel高高高并发、补偿逻辑复杂绝大多数业务用 AT 模式就能撑住重点别把它当银弹写热点集中、补偿逻辑绕的场景才值得为 TCC 多写那几个方法。可能有人会问消息队列本地消息表、事务消息算不算分布式事务方案算。它是另一种思路——先把本地改动落库再把”要通知下游”这个动作也可靠地投递出去靠消息做到最终一致。好处是彻底不锁资源坏处是做不到同步强一致下游消费有延迟。选哪种看你的业务能接受多少延迟。说白了每一类分布式事务方案都是在”一致性、可用性、代码量”三者里做减法。在我这边能异步走消息队列的优先消息队列其次 TCCAT 模式适合快速接入XA 只留给真正必须强一致的核心链路。