分布式事务 方案对比 三种主流分布式事务方案优劣详解

三种主流方案优劣详解

场景引入：电商下单的“连环坑”

想象一下，你在电商平台下单买了个新手机，点击支付后，系统需要同时完成：

1. 扣减库存（商品服务）
2. 生成订单（订单服务）
3. 扣款（支付服务）

如果订单生成了，但支付失败，库存却扣了——用户没付钱，货却没了，老板可能要找你“喝茶”，这就是典型的分布式事务问题：多个独立服务的数据如何保证“要么全成功，要么全回滚”？

今天我们就掰开揉碎，聊聊三种主流分布式事务方案：2PC（两阶段提交）、TCC（Try-Confirm-Cancel）和SAGA，看看它们各自的“生存法则”。

2PC（两阶段提交）

核心思想：像小组长开会，先问大家“能搞定吗？”（准备阶段），再喊“那就干吧！”（提交阶段）。

优点

• 强一致性：所有节点要么全部提交，要么全部回滚，数据不会“精神分裂”。
• 实现简单：数据库（如MySQL XA协议）、中间件（如Seata）原生支持。

缺点

• 性能差：事务协调者（TM）要等所有参与者（RM）响应，网络抖动时容易“卡死”。
• 同步阻塞：参与者资源锁定时间长，高并发下可能拖垮系统。
• 单点故障：协调者挂了，全体“躺平”。

适用场景：传统银行转账、内部系统低并发场景。

TCC（Try-Confirm-Cancel）

核心思想：把事务拆成三步——

1. Try：预留资源（如冻结库存100件）。
2. Confirm：真正提交（扣减冻结的100件）。
3. Cancel：回滚（解冻100件）。

优点

• 性能较好：资源提前预留，最终提交时效率高。
• 无阻塞：Try阶段后释放连接，适合高并发。

缺点

• 代码侵入性强：每个服务要写Try/Confirm/Cancel三个接口，开发量翻倍。
• 业务设计复杂：冻结库存”需要额外字段，可能引入逻辑漏洞。

适用场景：秒杀、电商等高并发业务，钱和库存不能出错的场景。

SAGA

核心思想：长事务拆成多个本地事务，每个事务完成后触发下一个，如果中间失败，就逆向调用补偿操作（生成订单”的补偿是“删除订单”）。

优点

• 松耦合：服务间通过事件驱动，适合微服务架构。
• 高性能：无全局锁，异步执行。

缺点

• 数据可能临时不一致：补偿操作前，用户可能看到“订单已生成但支付失败”的中间状态。
• 补偿逻辑难写：已发货”的订单不能简单删除，得走退货流程。

适用场景：物流系统、跨系统长流程（如旅游订票：酒店+机票+租车）。

怎么选？记住这三点

1. 钱不能错（如支付）：优先TCC。
2. 速度第一（如秒杀）：SAGA或TCC。
3. 旧系统改造：2PC最省事，但做好性能兜底。

最后提醒：没有银弹！实际业务中常会混合使用，比如用TCC处理支付,SAGA处理物流。