分布式事务2PC分布式事务2pc tcc
2025年Java面试宝典抢先下载：
🔗 点击获取《2025 Java面试高频考点》（提取码: 9b3g）
备战金三银四，这份资料助你轻松过关！
为什么分布式事务这么难？
想象一下：你去银行跨行转账，钱从A卡扣了，但B卡没收到。在单系统里，数据库事务能保证ACID。可一旦服务拆成多个，比如订单服务、库存服务、支付服务各管一摊，如何保证它们操作一致？这就是分布式事务的核心痛点。
二阶段提交（2PC）：事务协调者的双保险
2PC事务通过一个协调者（Coordinator）来管理多个参与者（Participant），分两步走：
-
准备阶段（Prepare）
协调者问所有参与者：“能提交吗？”
参与者锁资源、写undo日志，回复“YES”或“NO”。
（2PC事务准备阶段流程示意） -
提交阶段（Commit/Rollback）
如果全员YES → 协调者发commit命令，参与者正式提交。
但凡有一个NO → 协调者发rollback命令，全员回滚。
✅ 优点：强一致性，所有节点状态一致。
❌ 致命伤：
- 同步阻塞：所有参与者阻塞等待协调者指令。
- 协调者单点故障：协调者挂了，参与者原地卡死。
- 数据不一致风险：Commit消息丢失时，部分节点提交、部分未提交。
面试被问2PC事务，一定要点出它的阻塞问题和单点隐患！
TCC事务：把大事务拆成小动作
TCC事务（Try-Confirm-Cancel）是2PC的改进版，核心思想是业务补偿：
- Try阶段：冻结资源（例如：库存锁定10件，账户预扣100元）
- Confirm阶段：正式执行（实际扣库存100元，实际扣款）
- Cancel阶段：回滚补偿（解冻库存，返还预扣金额）
✅ 优势：
- 异步化：各阶段可并行，减少阻塞时间
- 避免长事务锁：Try阶段只是资源预留
❌ 难点：
- 业务侵入性强：每个服务都要实现Try/Confirm/Cancel三个接口
- 补偿逻辑复杂：Cancel需要能处理各种中间状态（比如Try成功但Confirm失败）
（TCC事务三阶段流转模型）
2PC事务 vs TCC事务 怎么选？
| 特性 | 2PC事务 | TCC事务 | |----------------|--------------------|--------------------| | 一致性 | 强一致 | 最终一致 | | 性能 | 低（同步阻塞） | 高（异步化） | | 业务侵入 | 低（数据库层实现） | 高（需写补偿代码） | | 适用场景 | 短事务、低并发 | 高并发、长业务流程 |
👉 面试技巧：被问“分布式事务如何选型？” 可以这样答：
“短事务用2PC事务简单省事，但怕协调者宕机；高并发场景用TCC事务更抗压，但得自己写补偿逻辑。现在很多公司用Seata这类中间件，底层支持AT模式（类似2PC）和TCC模式。”
遇到分布式事务面试题怎么破？
- 先明确场景：是跨服务调用？还是跨库更新？
- 对比方案：2PC、TCC、消息表、Saga 各自优劣
- 提实际缺陷：比如2PC协调者单点、TCC空回滚问题
- 结合中间件：提一嘴Seata、RocketMQ事务消息
（分布式事务方案决策树）
面试资源福利站
如果你正在备战分布式系统面试，强烈推荐使用面试鸭会员题库。覆盖2PC事务、TCC事务、分布式锁、CAP理论等高频考点，附逐题解析和踩坑指南。
🔥 限时福利：
通过 面试鸭返利网 开通会员，可享 25元现金返利！
👉 直达链接：mianshiyafanli.com
用好工具+吃透原理，拿下Offer事半功倍！ 🚀
