一次线上故障，把“分布式事务”四个字从PPT里拽到了我面前。当时订单服务已经扣款成功，库存服务却回滚失败，用户看到的提示是“支付成功”，仓库里却没有货可发。客服工单一下子涌进来，技术群里全是“库存到底扣没扣”的消息。那一刻我意识到，单机数据库里那个ACID事务，在微服务和多语言环境下根本指望不上。也正是从那次之后，我带着团队把分布式事务、最终一致性、高可靠架构这些概念真正落到了生产系统里，也踩遍了多语言协作场景下的各种坑。
这篇内容不是理论课，是我把“订单与库存分布式事务”从故障到修复、从方案选型到多语言落地的全程记录。适合正在做微服务拆分、需要处理跨服务数据一致性、或者团队里同时存在Java、Go、PHP等多语言技术栈的架构师和开发同学参考。我会把当时怎么排查、为什么这样选型、代码层面怎么落地、压测和故障演练暴露了什么问题，一条一条讲清楚。
1. 一次线上故障逼出的选题：订单扣库存数据不一致的完整复盘
1.1 故障表象与初步定位
那是一个促销日的晚上，订单量比平时翻了四倍。最先报警的是库存系统的数据库连接池被打满，紧接着订单系统的支付回调开始超时，再往后就是用户反馈“钱扣了订单取消了”。
我进到日志平台看链路，发现一个典型的时间线：订单服务在自己库里面开启了本地事务，先写订单表、扣减账户余额，这两个操作都在MySQL里，事务提交成功。然后订单服务通过HTTP调用库存服务，库存服务在自己的数据库里扣减库存，但是这个调用超时了，订单服务直接抛异常，回滚了自己这边的本地事务。用户看到的是支付失败，但实际上账户余额已经扣了，订单状态也变成了已取消。这就是最典型的“跨服务调用导致的分布式事务不一致”。
很多刚接触微服务的同学会觉得，只要每服务保证自己的本地事务，调用链上某个环节失败就整体返回失败，数据就安全。实际上不是这样的，分布式系统里网络调用有三个结果：成功、失败、超时未知。超时未知是最恶心的，订单服务收到超时时，库存服务那边的扣减可能已经成功了，也可能还没执行。订单服务如果直接回滚，两边数据就对不上。
1.2 根因：两个服务、两套事务、一条断掉的数据链
我当时让团队把整个调用链路画出来，问题看得非常清楚。订单服务和库存服务各自拥有独立的数据库，订单主库在A机房，库存主库在B机房，中间隔了一条专线。订单服务扣款写的是自己的库，库存服务扣库存写的是自己的库，这两个操作之间没有任何分布式事务协议在协调。
HTTP调用超时之后，库存服务实际上已经把库存扣了，但是事务还没提交，网络断掉了。订单服务那边回滚了自己的余额扣减，库存服务超时时间到了之后，连接断开，库存服务自己的事务也回滚了。这一条链上，余额扣减和库存扣减都回滚了，表面上一致了，但是订单服务的支付回调记录被写进了本地表，支付网关那边已经确认扣款成功了。第二天对账的时候才发现，支付网关扣了用户钱，我们却把订单取消了。
这种问题靠加超时时间、加重试根本解决不了。HTTP重试会让库存被扣两次，不加重试又会漏扣，好像怎么都是错的。我当时跟团队说了一句话：只要两个服务不在同一个数据库里，就必须引入一种机制来协调跨库操作，不能指望链路调用的“运气”。
根因复盘完了之后，我的第一个决定是：把支付回调、订单创建、账户扣减、库存扣减这些核心写操作，全部从HTTP同步调用里拆出来，改成异步化。只有订单创建和支付确认可以走弱一致，其他所有跨服务数据变更必须走明确的事务方案。这个决定后来被证明是整场治理里最重要的一步。
2. 分布式事务方案选型：从2PC到Saga，我为什么放弃了“完美方案”
2.1 强一致方案的代价：2PC与TCC的真实局限
方案选型那段时间，我几乎把市面上所有分布式事务方案都过了一遍。最先被否掉的是基于两阶段提交（2PC）的方案，比如Atomikos、Bitronix这类XA事务管理器。2PC的逻辑很清晰：先准备，再提交，所有参与者都返回成功才提交，有一个失败就全部回滚。
但2PC在生产环境有一个致命伤：TC（事务协调者）单点阻塞。如果协调者在第二阶段宕机了，所有参与者的事务资源会一直保持锁定状态，数据库连接、行锁、全局锁全部被占住，业务先卡死。网上很多人说2PC性能差，其实性能倒不是最关键的，关键是它把本地事务的锁范围放大到了跨库跨网络，风险被放大了。而且我们的核心库是MySQL，XA方案的兼容性和运维复杂度足够让人头疼。选型会议上我直接拍板：核心链路不碰2PC。
TCC（Try-Confirm-Cancel）方案我们也认真评估过。TCC的概念很好，Try阶段冻结资源，Confirm阶段真实扣减，Cancel阶段释放冻结。它比2PC灵活，每个阶段都是业务自己写的。但是TCC对业务侵入性太大，每一笔订单、每一个库存SKU都要写Try、Confirm、Cancel三套逻辑，相当于把事务的复杂度从框架层搬到了业务层。我们的库存有几十万个SKU，每个SKU的冻结逻辑不一样，靠人力去维护三套方法，出错概率很高。加上团队里还有PHP和Go的同事，让他们也按TCC标准写一套代码，沟通成本会直接失控。
2.2 最终一致性路线的关键判断：本地消息表与事务消息的取舍
我最终选择的是最终一致性路线。这个路线在技术圈里多少有些争议，有人觉得“最终一致”就是“数据会乱一会儿”，不够高级。我的经验恰好相反，对于绝大多数互联网业务，尤其是订单、支付、库存这类场景，最终一致性才是可行性、成本、可靠性之间平衡得最好的方案。
具体到技术选型，当时摆在我面前的主要是两个方向：本地消息表（也叫事务消息表）和消息队列的事务消息。本地消息表的核心做法是，把业务操作和消息写入放在同一个本地事务里。比如订单服务扣减余额的同时，在本地数据库插入一条状态为“待发送”的库存扣减消息，这两个操作在同一个事务里，一起成功一起失败。然后由一个后台任务定期扫描消息表，把消息发给库存服务的队列，同时更新发送状态。库存服务消费消息后，处理自己的扣减逻辑，再回调或通过消息通知订单服务。
这个方案的好处是逻辑非常直白，不依赖消息队列的特殊能力，大家一看就懂，出了问题也容易排查。坏处是每个消息都要建表、扫表、改状态，代码量不小。事务消息方案则是把消息的本地事务特性内置到MQ里，比如RocketMQ的事务消息，生产者先发送半消息，等本地事务执行完了再提交或回滚半消息。这样就不用自己维护消息表了，消息可靠性和事务绑定都由MQ保证。
当时我们做了一次实测。本地消息表的方式，订单服务要额外维护一张消息表，写入量会翻倍，但整体实现起来可控，任何语言的团队都能理解。RocketMQ事务消息虽然代码更简洁，但有一个前置条件：团队必须对RocketMQ的运行机制很熟，而且生产环境要有一套稳定运行的RocketMQ集群。我们当时用的消息中间件是Kafka，Kafka本身不支持事务消息语义，要支持得自己封装很多东西，权衡之下，本地消息表胜出。
这个选择可能不是最前沿的，但在我们当时的场景里是最稳妥的。后来有一次Kafka集群升级抖动，本地消息表方案自然扛住了，因为消息表在业务库里面，由后台任务推送给MQ，MQ挂了消息不会丢，恢复了继续发。如果用完全依赖MQ事务消息的方案，遇到MQ集群级别的故障，消息状态可能就悬在半空，得额外写补偿程序来兜底。
3. 最终一致性落地的工程细节：消息可靠性、幂等消费与对账补偿
3.1 消息不丢不重背后的四条保障
方案定了之后，真正的难点才开始。本地消息表看起来简单，落地的时候全是细节。我总结了四个保障，少了任何一个，最终一致性都会变成“最终不一致”。
第一，消息发送必须确认。后台任务从消息表扫描待发送消息，把消息内容发给MQ，这个动作不能发了就完。要发完消息之后，回写消息表状态为“已发送”。如果回写失败，下次扫描会重复发送同一条消息，这不怕，后面有幂等兜底。如果扫描任务在发送前宕机，消息会一直停留在“待发送”，下次继续扫，这就是不丢。
第二，MQ消费必须手动确认。消费端收到消息，执行完库存扣减逻辑，必须手动提交消费位移，不能依赖自动提交。自动提交的问题在于，Kafka是拉取消息后先更新位移再执行逻辑，如果逻辑执行到一半进程挂了，这条消息就丢了。我们当时的核心消费组全部改成手动提交，而且提交位移的时机放在了业务逻辑全部成功之后。
第三，消费失败要进死信队列或重试表。消费端处理失败时，不能无限重试，也不能丢弃。我给团队定的规则是：业务可重试的异常（比如数据库连接抖动）最多重试三次，每次间隔递增；不可重试的异常（比如数据格式错误）直接进入死信队列，推给告警平台由人工介入。库存系统中曾有过一个反例，某次消费失败被无限重试，结果同一批消息压垮了下游数据库，这个教训很深刻。
第四，本地消息表要有过期监控。消息表里的记录不能一直躺在“待发送”状态。我们做了一个监控任务，统计所有创建时间超过十分钟还停留在“待发送”或“已发送但未确认”的消息数量，超过阈值就告警。这个监控曾经帮我们发现过扫表SQL的索引失效问题，也算意外收获。
3.2 幂等表与状态机：让重复消息变成无害消息
消息可以重复发送，消费端就必须幂等。我们当时在库存服务里建了一张流水幂等表，表的唯一键是业务主键加消息ID。处理消息时，先尝试把消息ID插入幂等表，插入成功说明这条消息是第一次来，继续执行扣库存逻辑，扣库存也有自己的流水表。插入幂等表如果违反唯一约束，说明消息来过，直接返回成功。
这里有一个容易踩的坑：幂等表的判重和真正的业务操作必须在一个本地事务里，否则判重成功了业务操作还没执行，服务就宕机了，重启后同一条消息再来，又会因为幂等表里已经有这个ID而被直接跳过，库存就漏扣了。正确的做法是，在一个本地事务里完成两条写操作：写幂等记录、写库存扣减流水并更新库存。要么都成功，要么都回滚。这样即使宕机，两件事一起回滚，不会出现“判重成功但扣减失败”的空隙。
光有幂等表还不够，我要求订单服务和库存服务各自维护一张业务状态机表。一条订单数据，在状态上要有明确的流转路径：待支付、已支付、库存扣减中、库存扣减成功、库存扣减失败、订单完成。状态机的意义是，任何一条消息进来，只有“合法状态迁移”才能被接受。比如订单已经是“库存扣减成功”了，又来一条“库存扣减失败”的补偿消息，那这条消息就应该被忽略，因为状态机不允许从成功态回到失败态。这种约束让系统在面对乱序消息、重复消息和延迟消息时都有了兜底能力。
3.3 对账补偿：兜底逻辑为什么必须存在
即便有了消息表、幂等、状态机这些机制，我依然坚持要做对账，因为任何机制都有概率出现不可预知的问题。对账的思路很简单，每天凌晨跑批任务，对比订单服务的订单状态、账户流水和库存服务当天的扣减流水，找出不一致的记录。
第一次上线对账任务的时候，查出了147条两边对不上的记录。原因五花八门：有消息表状态被错误更新成“已发送”但实际没发出去的，有消费端明明处理成功了但位移提交失败导致重复消费了两次扣了双份库存的，还有一个是代码上线时临时改过状态机配置引发的转换异常。这些场景在设计时很难全部预见到，但对账把它们全部暴露出来了。
对账之后要有补偿手段。我们设计了一张补偿任务表，状态不一致的记录会被生成补偿任务，由运维或者值班开发手动或半自动触发补偿。补偿逻辑要考虑业务含义，比如库存扣了双份，那就不能简单地把库存加回去，还要检查这个订单是否真的只买了一件商品。对账补偿的不是技术数据，而是业务事实。这一点很多人会忽略，过度追求“流水一致”反而会制造新的订单错误。
我在团队内部常讲一个观点：最终一致性不是靠一个方案实现的，是靠“消息可靠传递+幂等消费+状态机约束+对账补偿”四层一起托底实现的。少一层，线上就能给你颜色看。
4. 多语言工程团队下的一致性治理：SDK、契约与流程约束
4.1 多语言带来的“野生实现”问题
我们的技术栈一直不是统一的Java。订单服务是Java的，库存服务是Go的，后台管理端和一些数据处理脚本是PHP的，后来又加了Python写的分析服务。多语言本身没什么问题，问题在于多语言环境下，每个团队对分布式事务的理解和实现都可能不一样。
最早出现的“野生实现”是PHP团队自己写的一套事务状态回调，回调地址是硬编码的，生产环境和测试环境指向同一个地址。还有Go团队的同学为了方便，直接把订单消息里的JSON字段按自己的喜好改了结构，导致Java消费端解析失败。这些问题本质上不是语言的问题，是缺乏统一的约定和约束。我把这个阶段总结为：多语言业务代码越写越欢，跨语言数据一致性越来越碎。
4.2 契约先行与SDK标准化
为了解决这个问题，我们引入了两个东西：消息契约和轻量SDK。
消息契约其实是JSON Schema的扩展版，我们把每一条核心业务消息（订单创建、支付完成、库存扣减请求、库存扣减结果）都定义成标准的结构，字段名、字段类型、是否必填、取值范围全部用Schema描述清楚。所有语言的团队在生产和消费消息之前，先通过Schema校验，校验不过的消息直接进死信。最开始推进的时候阻力不小，大家觉得校验消息太麻烦，直到Java端从消息里取一个“orderId”字段，Go团队给的是“OrderId”，大小写对不上，解析直接报错，生产了一次告警之后，契约校验才真正被所有人接受。
SDK这一层我们做得比较轻，没有做成重量级框架，只提供了三个能力：消息ID生成与透传、幂等表操作封装、消息Schema校验客户端。每种语言一个版本，实现逻辑对齐，但接口风格尽量贴近各语言的习惯。比如Java版用了Builder模式，Go版用结构体加Option模式，PHP版就一个简单的类。SDK的维护由我当时临时组建的“事务治理小组”负责，小组里每种语言至少有一个熟悉核心逻辑的人，防止某一种语言出现问题没人接得住。
跨语言场景里还有一个特别容易被忽视的问题是超时与重拾语义。Java的HTTP客户端和Go的context超时、PHP的default_socket_timeout，默认超时时间完全不一样。同一个接口在多语言调用链上的超时行为不一致，会导致同一笔业务在不同调用方眼里状态不同。我们后来统一做了调用协议层面的约束，每个外部调用必须显式声明超时时间，禁止使用语言默认值，并且所有跨服务调用的超时时间集中在一份配置中心管理。
4.3 跨语言事务上下文的传递方案
分布式事务在跨语言场景下，还涉及一个非常实际的问题：事务上下文怎么传递。本地消息表方案对事务上下文的依赖比TCC小，但并仍然需要把一些关键信息透传下去，比如全局唯一的业务流水号、消息ID、请求来源、时间戳。
我们在多语言服务之间传递这些上下文时用过几个方案，最终稳定下来的是在HTTP头部和MQ消息头各放一套标准的追踪字段。HTTP调用用请求头传，比如X-Transaction-ID、X-Message-ID、X-Source-App这些自定义头部；MQ消息则在消息属性里带上同一组字段。每种语言的SDK负责在发送方自动填充、接收方自动解析，业务代码不用手动处理，这样就避免了多语言团队各自定义一套字段名导致链路追踪断裂的问题。
这些上下文的价值在故障排查中体现得非常明显。以前排查一条“库存扣减失败”的工单，要在Java日志、Go日志、PHP脚本日志里来回翻，纯靠订单号字符串去匹配。统一了事务上下文之后，日志系统里面按X-Transaction-ID一搜，整条链路的日志就全出来了。排查时间从小时级降到了分钟级，团队幸福感提升了一个档次。
5. 高可靠架构的故障演练与容量评估：我们踩过的坑和压测数据
5.1 故障演练发现的三个典型问题
架构设计得再漂亮，没有经过真实故障检验都是纸面文章。我们在推进高可靠架构的过程中，定期做故障演练。印象最深的一次演练，直接把三个隐藏问题同时暴露出来了。
第一个问题是消息推送任务在数据库连接池耗尽时会引发连锁阻塞。本地消息表的扫描任务虽然是异步的，但它连接的是订单主库。促销高峰时主库连接池被打满，扫描任务拿不到连接，消息就不能及时推送给MQ。而订单服务又会因为同步调用库存超时失败而不断重试，反而加重了主库的压力。我们随后给扫描任务单独配置了一个小型的只读从库连接池，通过主从复制延迟实现数据读取，有效把消息推送对主库的影响降到了最低。
第二个问题是消费端扩容后，库存服务出现了“踢足球”式的重复消费。Kafka的消费者组重新均衡时需要时间，期间同一个分区会被多个消费者临时消费，如果不做消费前加锁，库存扣减就可能执行两次。幂等表在这里又立了功，但同时也暴露了性能问题：库存服务在消费端没有做本地去重，导致同一个事务ID被重复解析多次，白白增加了耗时。后来我们在消费者进程内加了一层内存布隆过滤器来预判消息ID是否已经见过，见过就直接短路，大幅降低了幂等表的写入压力。
第三个问题最隐蔽：Go库存服务的内存缓存与数据库扣减之间出现了短暂的不一致。Go服务在读取库存时缓存了热卖商品的库存值，扣减流水落库之后再更新本地缓存。演练时发现，同一个商品在两个不同的请求里拿到的是同一个缓存旧值，导致叠加扣减时少扣了一次库存。这个问题的根源是扣减并不是原子的，在更新缓存前要先锁定一个本地互斥锁，或者直接走数据库原子扣减后重新同步缓存。后来我们改成了“数据库原子扣减加缓存异步失效”的方案，才算稳定。
5.2 容量评估与人仰马翻的教训
故障演练之外，容量评估是另一个绕不开的话题。分布式事务链路比单服务复杂很多，任何一环节的容量瓶颈都会导致整条链路上的事务状态堆积。
我们有过一次惨痛教训。当时预估订单量增长只需要把订单服务的实例数翻倍，忽略了本地消息表的扫描任务是同一套代码部署在订单服务里的。实例翻倍之后，每个实例都启动了自己的扫描定时任务，这就相当于扫表并发翻了倍。原本不会出现的死锁出现了，很多消息在“已发送未确认”状态卡了很久。后来我们用分布式锁（基于数据库行锁或者Redis的SETNX）来保证同一条消息只有一个实例在推送，扫表并发才稳定下来。
容量评估时，我建议至少写清楚三个数字：正常水位、压测峰值、安全余量。正常水位是平时每秒钟的消息送量；压测峰值是在压测环境里模拟真实读写加上两倍流量后的最大吞吐；安全余量一般预留百分之三十到百分之五十的CPU和连接池资源。这几个数字要写进运维手册，不能让后续接手的人靠猜来扩缩容。
5.3 多活与容灾的一些实践边界
最后说多活与容灾。我们在做高可靠架构时也规划过“同城双活”，但实现过程中发现，分布式事务和双活架构之间存在天然的矛盾。如果订单主库在A机房，库存主库在B机房，两个库之间的网络延迟会直接影响事务链路的延迟。大多数团队说的双活其实是“应用层双活、数据库主备”，要认真评估双活真正带来的收益。
我们的实践是，把订单服务和库存服务在应用层做了多机房部署，数据库层面依然是主备模式，重要数据实时同步。应用层多活可以解决单点机器故障的问题，但数据库主备切换期间，本地消息表的状态可能会短暂读不到，这个时候要接受投递延迟，不能为了追求实时性去消费从库的脏读数据。多活架构里，最终一致性的容错能力比强一致更实用，因为网络分区本身就是常态。
容灾演练时我们要求每个值班开发亲手操作一遍主备切换脚本，我自己的体验是，大多数主备切换工具在正常状态下很好用，但真正故障时可能因为日志堆积、权限变化而执行失败。所以容灾演练不能只验证脚本本身，还要验证备用环境上的数据是否完整，消息表是否追得上，下游服务是否能接受切换带来的延迟。这些细节，不演练是根本发现不了的。
最后的实际操作心得
如果让我重新选择一次，我依然会用本地消息表加状态机加对账这套组合来做核心交易链路，因为它把分布式事务的不确定性收敛到了我们可以理解和控制的范围内。多语言团队并不可怕，可怕的是没有统一的消息契约和可复用的SDK。故障演练和容量评估看起来很费时间，但它们能让系统在真正出事的时候保持体面。
再分享一个小技巧：最终一致性系统的监控告警不应该只看技术指标（消息积压量、消费失败数），一定要加业务指标，比如“每分钟新增的库存扣减成功流水数”和“每分钟新增的订单完成数”之间的比例。趋势一旦背离，即使所有技术指标都在正常范围，团队也能在用户投诉之前发现级联问题。这个指标我们内部叫“业务心跳”，它比任何框架里的状态面板都更贴近真实业务。
