分布式事务实战：电商订单与库存的最终一致性方案

1. 问题背景与场景还原

上周排查一个线上问题时，遇到了典型的跨库事务不一致案例。用户下单后，订单主表写入成功，但库存扣减却失败了。这种"半成功"状态在分布式系统中尤为棘手——两个数据库分别位于不同的物理服务器，无法通过本地事务保证原子性。

我遇到的具体场景是：电商系统中，订单服务使用MySQL的orders库，库存服务单独使用inventory库。当用户购买某件库存仅剩1件的商品时，如果这两个操作不在同一个事务中，就可能出现订单创建成功但库存未扣减的致命错误。

关键点：真正的生产环境往往采用微服务架构，不同服务有独立的数据库实例。这时传统的ACID事务无法直接跨服务生效。

2. 跨库事务的技术本质

2.1 本地事务的局限性

在单数据库环境下，事务的ACID特性由数据库引擎保证。以MySQL为例：

sql复制START TRANSACTION;
INSERT INTO orders(...);  -- 操作1
UPDATE inventory SET stock=stock-1 WHERE product_id=123; -- 操作2
COMMIT;

当这两个表在同一个数据库实例时，任何一条语句失败都会导致整个事务回滚。但一旦分属不同数据库，这个机制就失效了。

2.2 分布式事务的两种实现路径

实践中解决跨库事务主要有两种思路：

1. 强一致性方案：如XA协议、Seata等分布式事务框架

   • 优点：严格保证ACID
   • 缺点：性能损耗大（全局锁）、架构复杂度高

2. 最终一致性方案：如消息队列+定时任务补偿

   • 优点：高性能、松耦合
   • 缺点：存在短暂不一致窗口

下表对比两种方案的特性：

3. 实战解决方案设计

3.1 方案选型决策树

根据我们的业务特点（电商订单），选择最终一致性方案更合适。具体决策依据：

1. 业务容忍度：用户对秒级库存延迟可见是可接受的
2. 性能要求：大促期间需要支持3000+ TPS
3. 故障恢复：需要有自动补偿机制而非人工介入

3.2 基于消息队列的具体实现

核心流程如下图所示（文字描述）：

1. 订单服务：

   • 开启本地事务
   • 写入订单表（状态为"处理中"）
   • 发送库存扣减MQ消息
   • 提交事务

2. 库存服务：

   • 消费MQ消息
   • 尝试扣减库存
   • 失败时写入失败记录表

3. 定时任务：

   • 每5分钟扫描"处理中"超时订单
   • 检查库存扣减结果
   • 更新订单最终状态

关键代码示例（订单服务部分）：

java复制@Transactional
public void createOrder(OrderDTO order) {
    // 1. 保存订单（初始状态为PROCESSING）
    order.setStatus(OrderStatus.PROCESSING);
    orderMapper.insert(order);
    
    // 2. 发送库存消息（保证与订单事务同步）
    inventoryProducer.sendDeductMessage(
        new InventoryDeductDTO(order.getProductId(), order.getQuantity()));
    
    // 3. 事务提交时消息才会真正投递
}

3.3 必须处理的异常情况

在实际编码中，这几个边界条件必须处理：

1. 消息发送失败：

   • 方案：本地事务回滚，前端提示用户重试
   • 代码：在@Transactional内捕获MQ异常并转换为RuntimeException

2. 库存不足：

   • 方案：库存服务返回特定错误码
   • 处理：更新订单状态为"库存不足"，触发退款流程

3. 重复消费：

   • 方案：MQ消息携带唯一业务ID
   • 实现：库存操作实现幂等性

4. 性能优化实践

4.1 消息投递的可靠性保障

我们采用RabbitMQ的confirm模式增强可靠性：

java复制// 发送消息时设置确认回调
rabbitTemplate.setConfirmCallback((correlationData, ack, cause) -> {
    if (!ack) {
        log.error("消息投递失败: {}", cause);
        // 触发告警并记录到异常表
    }
});

同时配置生产端的重试策略：

yaml复制spring:
  rabbitmq:
    template:
      retry:
        enabled: true
        initial-interval: 1000ms
        multiplier: 2
        max-attempts: 3

4.2 定时任务的优化技巧

补偿任务需要特别注意：

1. 分页查询：每次处理100条，避免大结果集
2. 乐观锁：更新时带状态条件

   sql复制UPDATE orders 
   SET status = 'FAILED' 
   WHERE id = ? AND status = 'PROCESSING'
   

3. 错峰执行：不同服务节点设置随机延迟

5. 监控与运维要点

5.1 必须监控的核心指标

1. 订单状态分布看板：

   • PROCESSING状态的订单占比（应<1%）
   • 平均处理耗时（应<30秒）

2. 消息堆积告警：

   • inventory.deduct.queue的积压量
   • 消费者处理耗时

5.2 日志规范建议

关键日志必须包含：

• 业务流水号（贯穿订单、消息、库存操作）
• 各环节时间戳（便于排查延迟）
• 操作结果状态码

示例日志格式：

code复制[订单创建] orderId=20230815123456, status=PROCESSING, cost=45ms
[库存扣减] orderId=20230815123456, productId=789, result=SUCCESS

6. 演进方向探讨

这套方案后续可以进一步优化：

1. 引入Saga模式：将大事务拆分为多个可补偿的子事务
2. 尝试DTF框架：如阿里云的GTS（适合混合云场景）
3. 事件溯源设计：用事件流重建状态，便于审计

不过在实际项目中，我建议先从简单的消息队列方案开始，等真正遇到规模瓶颈再考虑更复杂的方案。毕竟，没有完美的架构，只有适合当前业务阶段的架构。