分布式事务

分布式事务的方案选型我自己查过好几轮，这篇把 TCC、Saga、可靠消息、2PC、Seata AT 各自的原理和最适合的场景讲得比较清楚，整理一份存档。 在微服务架构下，跨服务的数据一致性保证是个绕不开的难题。如果在一次业务操作中，写多个 DB，或既写本地 DB、又调外部 RPC 接口，就会面临一致性问题，怎么保证跨库、跨系统的操作要么都成功、要么都失败呢？ 先说结论，最常用的分布式事务方案是：TCC、Saga、可靠消息。最推荐的开源框架是 Apache Seata，支持多种分布式事务模式，包括 TCC、Saga、AT 等。下面展开介绍。 BASE 理论 在一个数据库事务内，多个 SQL 写操作可以保证强一致。而到了分布式场景，只能做到最终一致。这就引出了 BASE 理论：基本可用、软状态、最终一致性，即允许系统存在中间不一致状态，只要最终达到一致即可。分布式事务方案大多在 BASE 理论指导下，放弃强一致，追求最终一致。 主流方案和最佳场景 下面每种方案都用一个独立的、最适合的业务场景来介绍。 1. TCC 最佳场景：下单时扣库存、扣余额 比如下单流程，涉及订单服务、库存服务、支付服务。需要同时创建订单、冻结库存、冻结余额，并发量较高，且对一致性要求严格。 原理与实现机制 TCC 需要一个协调者，一般称为事务管理器，负责编排整个流程。但资源锁定做到了业务层、而非 DB 层，由应用代码显式实现 Try、Confirm、Cancel 三个接口。 TM（事务管理器）：负责调用各个服务的 Try 方法，根据结果决定全部 Confirm 或全部 Cancel。需记录事务日志，处理重试和异常。 RM（资源管理器）：各业务服务自身，需要提供 Try/Confirm/Cancel 三个接口，并保证幂等（可能会调多次）。 流程细节 TM 依次调用每个服务的 Try 接口，预留业务资源（如冻结库存、冻结余额），不用上数据库行锁。 若所有 Try 成功，TM 依次调用 Confirm 接口，将预留资源实际消耗或状态推进。 若任何 Try 失败或超时，TM 调用所有已成功服务的 Cancel 接口，释放预留资源。 框架需要处理空回滚（Try 未执行但 Cancel 被调用）、悬挂（Cancel 比 Try 先到）、幂等（接口被重复调用）等问题，一般通过记录全局事务状态，并用全局事务 ID 查询状态来实现。 举例：库存服务 Try/Confirm/Cancel ...