分布式事务TCC分布式事务tcc saga

前几天面试，面试官直接甩了个场景：“跨多个服务的数据一致性怎么保证？除了2PC、3PC还了解哪些方案？” 得，分布式事务这块硬骨头终究是绕不开。高频面试点TCC和SAGA，必须盘清楚！这里结合实战理解，分享下核心思路。

2025年Java面试宝典（含分布式事务高频题）提前备好： 链接: https://pan.baidu.com/s/1RUVf75gmDVsg8MQp4yRChg?pwd=9b3g
(提取码: 9b3g)

一、为什么需要分布式事务？痛点在哪？

想象一下：用户下单支付成功，但库存服务扣减失败；或者优惠券已核销，订单却创建失败。这在单体应用里一个本地事务搞定，但在微服务拆分后，数据库各自独立，本地事务失效。分布式事务就是为了解决这种跨服务、跨资源的数据一致性难题。核心矛盾：可用性(A)、一致性(C)、分区容错性(P)，难以同时满足（CAP定理）。

二、柔性事务解决方案：TCC模式

TCC (Try-Confirm-Cancel) 是补偿型分布式事务的经典实现，业务侵入性强但可控性好。它的本质是把一个大事务拆成多个子事务，每个子事务都要实现三个操作：

Try：预留资源。做业务检查，锁定必要资源（例如：冻结库存、预扣优惠券、临时扣款）。状态是中间态，可回滚。
Confirm：确认执行。所有Try成功，则执行真正的业务操作（例如：扣减冻结的库存、使用优惠券、正式扣款）。需要幂等设计。
Cancel：取消回滚。任何一个Try失败，或需要回滚时，执行反向操作释放资源（例如：解冻库存、返还优惠券、退回预扣款）。同样需要幂等。

面试答点：

优点： 高并发下性能较好（资源早锁定），数据最终一致，避免了长事务锁。
缺点： 业务侵入性高，每个服务都要写Try/Confirm/Cancel接口且保证幂等；开发复杂，回滚逻辑需谨慎。
场景： 对一致性要求高、业务模型适合拆分、并发量大的场景（电商交易、金融支付）。

三、另一种思路：SAGA 模式

如果说TCC是“谨慎派”（先预留再操作），那SAGA就更“乐观”些。它把一个分布式事务拆解成一系列连续的本地事务。每个本地事务执行后，都会发布一个事件或消息触发下一个事务。

核心机制：

正向操作 (Ti)： 顺序执行每个本地事务（如：创建订单 -> 扣减库存 -> 扣款）。
补偿操作 (Ci)： 为每个正向操作Ti定义一个对应的补偿操作（回滚逻辑），用于失败时撤销Ti的效果（如：取消订单 -> 回补库存 -> 退款）。

SAGA的执行就像多米诺骨牌：

所有Ti成功：事务完成。
中间Ti失败：则按反方向顺序触发前面所有步骤的补偿操作Ci（Ci执行也要幂等！）。

面试答点：

优点： 业务侵入性相对较低（主要写补偿操作），适合长流程业务；避免了全局锁。
缺点： 可能出现脏读（中间状态可见）；补偿操作的设计实现要求高；保证最终一致性但过程状态多。
场景： 业务流程长、步骤多、后续步骤依赖前置结果的场景（订单旅行、复杂供应链）。

四、 TCC vs SAGA 怎么选？

面试官追问怎么办？ 结合项目！比如：秒杀用TCC保证库存和订单强一致；用户注册后送积分和优惠券这种异步流程，用SAGA更合适。

写在最后

搞懂TCC分布式事务和SAGA分布式事务的核心差异和应用场景，面试时被问到分布式事务方案选择，就能有理有据。分布式事务没银弹，TCC和SAGA都是成熟的选择，关键看业务特点。

需要购买面试鸭会员？通过面试鸭返利网 (mianshiyafanli.com) 找我下单，立享25元返利！ 面试题库会员配合实战理解，效率更高。想找最新面试题答案或资源？推荐关注面试鸭返利网，程序员面试必备！

分布式事务TCC分布式事务tcc saga