分布式事务解决方案：一线实战中的最佳实践

引言

分布式系统已经成为后端架构的标配，尤其在高并发、多服务、微服务盛行的今天。我们团队在构建一个核心业务系统时，遇到了一个典型却又极具挑战的问题：如何保障多个服务之间的数据一致性？

这个问题本质上就是我们在开发中常说的“分布式事务”问题。一开始我们只是把它当作普通的本地事务来处理，直到生产环境出现订单状态与支付状态不一致、积分发放失败但用户已扣款等现象，才发现事情远没有想象中简单。

这篇文章是我结合过去一年带领团队解决分布式事务问题的真实经历所写，希望能给正在或即将面临类似困境的同学一些实用建议和参考。

---

项目背景

我们是一个电商平台的技术团队，在公司战略调整后，决定将原有的单体应用拆分为多个服务，包括：

• 订单服务（Order Service）
• 支付服务（Payment Service）
• 积分服务（Points Service）
• 用户服务（User Service）
• 商品服务（Product Service）

每个服务都独立部署、使用独立数据库，并通过 Rest API 和消息队列进行交互。这确实带来了灵活性和可扩展性上的提升，但也引入了新的问题——跨服务的数据一致性难以保证。

例如：

当用户下单并支付成功后，我们需要：

• 更新订单状态为“已支付”
• 扣除用户的余额
• 增加用户的积分
• 减少商品库存

这些操作分布在四个不同的服务里，若其中任何一个失败，整个流程就可能出现不一致的状态。而这一切，都需要在一个用户下单动作中完成。

我们初期尝试用本地事务 + 调用链回滚的方式处理，结果发现代码臃肿且容易出错。于是开始深入调研分布式事务方案，并在实际项目中逐步落地了一些有效策略。

---

遇到的挑战

挑战一：服务间调用失败如何兜底？

我们最早采用的是“串行调用 + 回滚”的方式。也就是：

1. 下单 → 更新订单表
2. 调用支付服务 → 扣款
3. 调用积分服务 → 加积分
4. 调用商品服务 → 减库存

一旦某个服务调用失败，我们就尝试执行前面所有服务的“反向补偿”接口，比如：

public void rollBack(Order order) {
    orderService.rollBackStatus(order.getId());
    paymentService.refund(order.getUserId(), order.getAmount());
    pointsService.deductPoints(order.getUserId(), order.getPoints());
    productService.restoreStock(order.getProductId(), order.getCount());
}

听起来挺合理，但实际开发过程中我们遇到了几个大坑：

• 服务之间依赖太多，补偿逻辑复杂：每个服务都要提供一个“可逆”的API，维护成本很高。
• 补偿失败怎么办？：有时候调用一次补偿失败，需要重试。但重试本身又可能引发重复补偿问题。
• 网络超时难判断状态：当调用支付服务时返回超时，无法判断是否扣款成功，这时候是继续执行还是终止订单，很难决策。

挑战二：异步操作与最终一致性冲突

在某些场景下，为了提升性能，我们采用了异步调用。比如在下单后，通过 Kafka 向积分服务发送一个事件消息，由消费者异步处理。

但这样带来的问题是：

• 如果订单服务提交了订单状态，而积分服务的消息消费失败或者延迟，会造成状态不同步。
• 用户看到订单已支付，但积分还没到账，投诉率直线上升。

虽然我们可以容忍“最终一致性”，但不能让用户感知到这种不一致。

---

解决方案选型与实现思路

面对上述问题，我们先后尝试了几种不同的分布式事务方案，并最终选择了更适合当前业务特点的一套组合方案。

方案一：TCC（Try-Confirm-Cancel）模式

这是我们在第一个版本中选择的主要方案，适用于对一致性要求较高的交易类业务。

实现原理

TCC 的核心在于：每个服务对外暴露三个接口：

• Try：资源预检查和锁定
• Confirm：正式执行业务逻辑
• Cancel：出错时回滚

以支付为例：

1. Try阶段：检查用户余额是否足够，冻结部分金额；
2. Confirm阶段：扣除冻结金额；
3. Cancel阶段：解冻金额。

我们是如何落地的？

我们在各服务内封装了一个 TCC 组件，统一管理事务流程。流程大致如下：

TransactionContext tx = new TransactionContext();
tx.begin();

try {
    orderService.tryCreateOrder(userId, productId);
    paymentService.tryFreezeAmount(userId, amount);
    pointsService.tryReservePoints(userId, points);
    productService.tryLockStock(productId, count);

    // 所有 Try 成功
    orderService.confirmCreateOrder(tx);
    paymentService.confirmDeductAmount(tx);
    pointsService.confirmAddPoints(tx);
    productService.confirmReduceStock(tx);

} catch (Exception e) {
    // 出现异常触发 Cancel
    orderService.cancelCreateOrder(tx);
    paymentService.cancelFreezeAmount(tx);
    pointsService.cancelReservePoints(tx);
    productService.cancelLockStock(tx);
}

实施效果

• 数据一致性有了保障；
• 服务接口设计变得规范；
• 补偿逻辑集中在 Cancel 接口中，便于维护。

但我们也发现了 TCC 的局限性：

• 对业务侵入性强：必须把业务逻辑拆成 Try、Confirm、Cancel；
• 不适合异步场景；
• 多个服务之间需共享事务 ID，否则无法识别上下文；
• 若某一 Cancel 失败，后续需人工干预，增加了运维压力。

因此我们并未在所有模块都采用 TCC，只将其用于核心交易环节，如订单创建+支付流程。

---

方案二：基于 Kafka + 本地事务表的最终一致性方案

对于非核心流程，比如积分奖励、通知、优惠券发放等场景，我们采取了更加轻量的“最终一致性”方案。

实现原理

• 每个服务先执行本地事务；
• 再往 Kafka 发送一条事件消息；
• 消费者监听事件，执行自身业务；
• 如果失败则重试，直到最终成功；
• 引入“本地事务表”机制记录事务状态。

举个例子

用户下单完成后，我们需要增加用户积分：

1. 订单服务本地事务中

   BEGIN;
   UPDATE orders SET status = 'paid' WHERE id = #{orderId};
   INSERT INTO events_log (order_id, event_type, status) VALUES (#{orderId}, 'ADD_POINTS', 'pending');
   COMMIT;
   

2. 定时任务读取 pending 事件，推送到 Kafka

   List<EventLog> logs = eventLogDao.findPending();
   for (EventLog log : logs) {
       kafkaProducer.send("points_event", log.toJson());
       log.setStatus("sent");
       eventLogDao.update(log);
   }
   

3. 积分服务监听 Kafka 消息并处理

   @KafkaListener(topics = "points_event")
   public void onMessage(String message) {
       EventLog log = parse(message);
       try {
           pointsService.addPoints(log.getUserId(), log.getPoints());
           log.setStatus("processed");
       } catch (Exception e) {
           log.setRetryCount(log.getRetryCount() + 1);
           if (log.getRetryCount() > MAX_RETRY_TIMES) {
               log.setStatus("failed");
           }
       }
       eventLogDao.update(log);
   }
   

优点与缺点

• 优点：

  • 降低服务耦合度；
  • 提高吞吐能力；
  • 可支持大规模异步处理。

• 缺点：

  • 存在短时间内的状态不一致；
  • 需要有监控报警机制，及时发现未处理事件；
  • 需要处理消息去重和幂等性问题；

为了应对幂等性，我们在积分服务中加入了“防重复处理”的逻辑：

if (pointRecordDao.exists(orderId)) {
    // 已处理过该订单的积分赠送，直接跳过
    return;
}

---

方案三：Saga 模式（备用方案）

Saga 是一种轻量级的补偿型事务模式，特别适合长周期、跨服务的业务流程。

我们原本打算在退货退款场景中使用 Saga，但在初步试验后发现：

• Saga 模式要求每个步骤都能自动回滚；
• 业务逻辑复杂时，编写补偿操作非常麻烦；
• 缺乏现成的框架支持（尤其是 Java 生态）；
• 日志追踪与调试困难。

所以目前我们仍处于观望状态，仅作为备选方案储备。

---

最终方案总结与对比

方案	使用场景	一致性级别	是否推荐
TCC	核心交易流程（订单+支付）	强一致	✅ 推荐
Kafka + 本地事务表	积分发放、消息推送等异步流程	最终一致	✅ 推荐
Saga	长周期业务，如退换货流程	最终一致	⚠️ 有条件使用

我们的经验是：根据业务性质选择合适的事务模型，而不是追求统一方案。

---

效果与收益

实施上述方案之后，我们得到了以下成果：

• 订单与支付状态同步率从 92% 提升至 99.8%
• 积分异步任务成功率稳定在 99.9% 以上
• 投诉率下降 60%，用户满意度显著提升
• 系统具备更高的容错能力和可观测性
• 架构更清晰，服务职责明确，易于扩展

此外，在运维层面我们也做了几点改进：

• 引入日志追踪 ID，全链路跟踪事务执行情况；
• 设置定时巡检脚本清理超时未处理事件；
• Kafka 消费失败自动告警通知；
• 对 TCC 事务日志做持久化存储，防止宕机丢失上下文。

---

经验分享与建议

作为一个经历过多次迭代和踩坑的技术负责人，我想给大家分享几个关键经验和建议：

1. 别指望一套方案打天下，根据业务来定

不要盲目追求强一致性或最终一致性，关键是看你的业务能否容忍短暂不一致。像支付流程必须强一致，但积分发放就可以接受几分钟的延迟。

建议： 先画清楚业务流程图，再评估每一步的数据一致性需求。

2. 保持服务低耦合，事务逻辑尽量下沉

我们在最开始的时候，把大量事务逻辑放在调用方，导致主流程越来越复杂。后来我们进行了重构，让每个服务自己实现 Try/Cancel 方法，从而降低了调用方的责任负担。

建议： 将补偿逻辑收敛在各自服务内部，调用方只需发起请求即可。

3. 日志、幂等、重试机制不可少

不管用哪种分布式事务方案，以下三样东西必须做好：

• 唯一事务 ID + 链路追踪，方便定位问题；
• 每个操作必须幂等，避免重复处理；
• 失败重试机制 + 告警机制，确保异常能被发现并及时处理。

4. 监控和运维要跟上

我们之前出现过几次事件堆积的情况，如果没有监控，根本发现不了。后来加上 Prometheus + Grafana 的统计仪表盘，实时查看消息积压、失败次数等指标，大大提升了故障响应速度。

建议： 每个服务都应集成健康检查接口，并接入统一的日志平台。

---

结语

分布式事务不是一个新问题，但它始终是分布式系统中最让人头疼的部分之一。这几年我带着团队一路摸索，从本地事务回滚，到 TCC，再到 Kafka + 本地事务表，每次技术演进的背后都是无数次踩坑和重构。

如果你也正在面对这样的挑战，不妨先问自己几个问题：

• 这个操作可以容忍多久的数据不一致？
• 它属于哪个级别的业务流程？
• 出现失败我能怎么兜底？

这些问题想明白了，你就离找到最适合自己的分布式事务方案不远了。

最后送给所有开发者一句话：

“优雅的分布式事务，不是靠某一项技术，而是靠你对业务的理解和架构设计的能力。”

希望这篇文章能带给你一些启发，也欢迎留言交流你们在实际项目中遇到的分布式事务难题。

— By 一个踩过很多坑的老程序员