分布式事务的实战经验分享：一次真实项目的挑战与突破
在我参与的一个电商平台重构项目中，我们遇到了一个非常典型、也非常棘手的问题——如何在多个微服务之间保障数据的一致性。这个平台原本是一个单体应用，后来随着业务增长，逐渐拆分成了订单中心、库存中心、支付中心等多个微服务模块。
项目初期，一切还算顺利，直到上线前夕的一次压力测试暴露了一个严重问题：高并发下单场景下，出现了“超卖”和“扣款不发货”的情况。当时我作为后端团队的技术负责人，第一时间意识到这是典型的分布式事务问题。于是，一场关于分布式事务方案的选择与落地实践就此展开……
一、背景与问题描述：当一致性遇上分布式架构
这次重构的核心目标是解耦各个业务模块，提升系统的可维护性和扩展性。订单中心负责处理用户下单逻辑，库存中心管理商品库存，支付中心则对接第三方支付平台。每个模块都有独立的数据库实例和服务接口。
但在联调测试中，特别是在压测环节，我们发现如下问题：
- 数据不一致：用户付款成功，但库存没有扣减（或者扣少了），导致后续出现发货异常。
- 系统不可靠：由于某个服务响应慢或超时，整个下单流程失败率大幅上升。
- 补偿机制缺失：缺乏自动回滚机制，只能人工介入修复数据，效率低且容易出错。
这些现象背后的原因其实很明确：在多个服务间执行的业务操作需要满足ACID中的“原子性”和“一致性”，而传统的本地事务无法跨越多个数据库实例或服务边界。
这时候我们就不得不正视一个问题：我们该选择哪种分布式事务方案？
二、解决方案选型：从理论到落地，逐步打磨
针对这个问题，我们首先梳理了几种主流的分布式事务方案，并逐一评估它们在我们系统中的适用性。
1. 两阶段提交（2PC）
虽然2PC是经典模型，但它需要引入协调者，存在性能瓶颈，而且一旦协调者宕机就会造成整个事务阻塞。对于我们这种对响应时间要求较高的电商下单来说，显然不太合适。
2. TCC（Try-Confirm-Cancel）
TCC是一种基于补偿机制的方案，它把每一个操作都分解为Try（预处理）、Confirm（执行）和Cancel（回滚）。这个模式的好处在于可以细粒度控制资源锁定，适用于长周期业务。
我们在订单+库存+支付的场景中做了初步尝试。比如：
- Try阶段：冻结用户账户余额、锁定库存
- Confirm阶段：完成支付、扣除库存
- Cancel阶段：释放余额冻结、恢复库存
但我们很快遇到了几个问题：
- 需要大量的补偿代码，逻辑复杂
- 每个服务都要实现try/confirm/cancel三组接口，开发工作量大
- 如果Cancel阶段本身也失败，还需要再加重试逻辑
最终我们认为：TCC适合交易链路较长且幂等性强的金融类业务，对我们当前的电商场景略显笨重。
3. Saga模式
Saga是一种轻量级的补偿式事务模型，每一步都有对应的补偿动作，失败时逆向执行即可。相比TCC，它不需要预先申请资源，减少了锁的竞争。
我们在实际编码中尝试了这种方式，设计了一个状态驱动的状态机来驱动各个步骤的流转。例如：
start -> create_order -> pay_order -> deduct_stock -> finish_order
↗ ↘ ↗
↗ → compensate on error
优点很明显：开发成本低，逻辑清晰，运维调试也比较方便。但也有一些不足：
- 状态机容易失控，特别是当步骤较多、错误路径多时
- 不适合对“强一致性”有极高要求的场景（比如转账）
4. 最终选择：本地消息 + 补偿机制 + 幂等校验
最终，我们采用了更轻量、更适合我们业务特性的方案：本地消息表 + 异步补偿 + 幂等性处理。
具体做法如下：
（1）本地事务写入消息表
以订单创建为例，当用户下单时，我们在同一个本地事务中插入订单记录和一个“待发送的消息事件”。这样能保证订单创建和事件发出是原子的，不会出现只建单不发消息的情况。
BEGIN;
INSERT INTO orders (user_id, product_id, ...) VALUES (...);
INSERT INTO message_queue (type='order_created', order_id=...);
COMMIT;
（2）异步消费消息进行后续操作
我们使用了一个独立的服务监听消息队列（如RabbitMQ），根据不同的事件类型触发相应的外部服务调用：
- 订单创建 -> 触发库存扣减
- 支付完成 -> 标记订单为已支付
如果某一步失败，消息会被重新投递（利用死信队列+重试机制）。
（3）幂等性设计贯穿始终
为了防止重复处理同一个消息，我们在关键接口中加入了幂等校验，比如使用business_id + request_id的方式做去重。
举个例子，在库存扣减接口中，我们先查询是否已经处理过此请求，如有就直接返回成功。
if (stockDeductionLog.exists(requestId)) {
return Result.success();
}
这套机制上线后，整体故障率下降了80%以上，数据一致性得到了明显提升。
三、结果与收益：从混乱到可控的转变
经过一个月的研发优化和灰度上线，我们最终取得了以下成果：
- 数据一致性显著提高：订单、库存、支付三者的联动逻辑更加稳定可靠，基本杜绝了“只扣钱不发货”的问题。
- 性能影响较小：由于采用的是异步补偿方式，核心链路的压力大大减少，QPS提升了30%左右。
- 运维友好：所有消息和补偿记录都有迹可循，出了问题也能快速定位。
- 开发人员接受度高：相比复杂的TCC，这套本地消息+补偿的设计逻辑更简单，新人上手更快。
更重要的是，我们建立了一套可复用的事件驱动架构范式。现在其他业务线也开始借鉴这套机制来解决跨服务的数据一致性问题。
四、一些实战经验与建议
在这次分布式事务的实践中，我总结了一些经验和教训，想和大家共勉：
✅ 技术选型永远服务于业务场景
很多人一开始就想追求“最先进”的方案，却忽略了自身业务的特点。比如我们最初尝试TCC，结果发现并不适合电商下单这种“短周期、高并发”的场景。适合的，才是最好的。
✅ 重视幂等性设计
不管用什么分布式事务方案，幂等性是必备的基础能力。否则很容易因为网络重传、消息重复等原因导致数据错误。
✅ 多使用异步手段降低风险
同步调用链越长，失败概率越高。异步+补偿的设计思维非常重要，不仅能提升系统吞吐量，还能让主流程更稳定。
✅ 日志和监控不能少
在生产环境中，你永远不知道哪条消息会丢，哪个服务会卡住。所以一定要做好日志追踪、消息记录、补偿次数监控等工作，出现问题时才能快速找到原因。
✅ 适当容忍短暂不一致
很多同学对数据一致性的理解太绝对化了，其实在分布式系统中，短暂的不一致是可以被接受的，只要能在合理时间内达到最终一致就行。这为我们节省了不少工程开销。
五、未来展望与技术趋势
如今，随着云原生的发展，Seata、DTM等分布式事务中间件越来越成熟，也在一定程度上降低了使用门槛。不过我认为，在真正落地之前还是要结合自身系统规模、业务特征来权衡。
我个人还是倾向于尽量用本地事务+异步补偿的方式解决问题，只有在业务非常复杂、强一致性要求极高的时候才考虑像TCC这样的高级方案。
另外，我也在关注基于Event Sourcing的最终一致性方案，它通过将所有的变更记录为事件日志，来构建完整的系统状态。虽然目前还没在我们的系统中大规模应用，但我认为它是未来发展的重要方向之一。
六、结语：分布式事务的本质是设计哲学
写到这里，我想说，分布式事务从来不是一个单纯的技术问题，它更是一种系统设计的思维方式。面对多个服务、多个数据源时，我们要学会放掉“一次性全部成功”的执念，转而拥抱“最终一致性”。
这篇文章里的每一个细节都是我在一线开发中亲手踩过的坑，希望这些经验能帮你在自己的项目中少走弯路。
如果你也在面临类似的挑战，欢迎留言交流。我们一起探讨，一起进步。
本文作者：一名热爱写代码的老码农，专注后端架构与稳定性建设，经历过多次线上事故洗礼，坚信“优雅的系统应该像水一样流动，而不是像石头一样坚硬”。
评论 0