一个典型的分布式事务案例是电商平台的下单扣库存流程。

当用户在电商系统中下单时，需要同时完成三个操作：

1. 订单服务：创建订单，写入订单数据库。
2. 库存服务：扣减商品库存，更新库存数据库。
3. 支付服务：生成支付记录，准备支付流程。

这三个服务通常部署在不同服务器上，使用独立的数据库，属于典型的跨服务、跨数据库的分布式事务场景。

如果其中一个环节失败（比如库存不足或支付异常），整个订单流程必须回滚，否则会出现“订单已生成但库存未扣”或“库存已扣但订单未创建”的数据不一致问题。

常见解决方案：

• TCC 模式：

  • Try：订单服务尝试创建订单，库存服务“锁定”库存（预留）。
  • Confirm：若所有服务都成功，正式提交订单和库存。
  • Cancel：若任一环节失败，释放锁定的库存，取消订单。

  优点：性能高，适合高并发场景。

• 本地消息表 + 消息队列：

  • 订单服务在本地数据库写入订单，并向“本地消息表”写入一条“扣库存”消息。
  • 消息队列（如 Kafka）异步通知库存服务执行扣减。
  • 库存服务处理成功后，更新消息状态为“已完成”。

  优点：系统解耦，支持最终一致性，适合对实时性要求不高的场景。

• Seata 的 AT 模式：
  基于全局事务协调器（TC）自动管理分支事务，通过数据快照和回滚日志实现自动回滚，开发者无需手动写补偿逻辑。

✅ 实际中，大多数电商平台采用“本地消息表 + 消息队列”或“TCC”模式，兼顾一致性与系统可用性。
📌 关键点：事务的原子性由业务逻辑和补偿机制保障，而非数据库本地事务。