分布式事务2PC分布式事务 2pc 3pc tcc
🔥 2025年Java面试宝典重磅分享：
链接: https://pan.baidu.com/s/1RUVf75gmDVsg8MQp4yRChg?pwd=9b3g
提取码: 9b3g
(建议保存备用，涵盖分布式事务等高频考点)
为什么分布式事务是面试必考题？
现在稍微大点的系统都是分布式架构，但多个服务/数据库之间如何保证数据一致性？面试官就爱问这个！分布式事务解决方案里，2PC、3PC、TCC这三个兄弟出场率超高，今天咱们掰开揉碎讲明白。
一、2PC：两阶段提交协议
分布式事务协调者（Coordinator）像导演一样指挥参与者（Participant）：
-
准备阶段：协调者问所有参与者："能提交不？"
参与者检查自身状态（比如资源是否锁定），回复YES/NO。 -
提交阶段：
- 如果全员YES → 协调者发"提交"指令
- 如果有人NO → 协调者发"回滚"指令
✅ 优点：强一致性保证，适合数据库层（如MySQL XA）
❌ 致命伤：
- 同步阻塞：参与者卡在等待指令（万一协调者挂了就死锁）
- 单点故障：协调者崩了全系统瘫痪
📌 面试坑点：很多面试官会追问："2PC超时了怎么办？" —— 记住这是2PC最大痛点！
二、3PC：三阶段提交的改进
为了解决2PC阻塞问题，3PC多加了预提交阶段：
- CanCommit：协调者问："有提交的能力不？"（轻量检查）
- PreCommit：全员YES则发预提交指令，参与者锁定资源
- DoCommit：正式提交
🔁 优化点：
- 参与者超时未收到指令会自动提交（降低阻塞概率）
- 引入协调者选举机制（比如用ZooKeeper）避免单点故障
💡 本质：3PC用复杂度换可用性，但依然无法100%避免数据不一致（比如网络分区时）
三、TCC：业务层的补偿模式
TCC（Try-Confirm-Cancel）把分布式事务控制权交给业务代码：
- Try：预留资源（如冻结库存）
- Confirm：真正提交（扣减库存）
- Cancel：失败回滚（解冻库存）
✈️ 场景：电商下单（订单+库存+优惠券服务）
- Try阶段：创建订单（待支付）、锁库存、锁优惠券
- Confirm：支付成功，确认生效
- Cancel：支付失败，全部解锁
⚠️ 注意事项：
- 所有服务需实现Try/Confirm/Cancel接口
- 需配合重试+幂等（防止网络抖动导致重复调用）
四、三种方案怎么选？
| 方案 | 一致性 | 性能 | 适用场景 |
|-------|--------|-------|-------------------|
| 2PC | 强一致 | 低 | 数据库层（如XA） |
| 3PC | 较强 | 中 | 少用，过渡方案 |
| TCC | 最终一致 | 高 | 业务复杂场景 |
💰 实战技巧：
- 资金交易用TCC（比如转账必须可回滚）
- 简单查询用异步消息（如发短信通知）
- 强一致性要求用2PC+重试补偿
五、面试怎么答能加分？
- 一定说清楚2PC阻塞问题和TCC的补偿思想
- 提一嘴Seata框架（它实现了这些模式）
- 强调最终一致性的trade-off："根据业务容忍度选方案"
👉 重要提示：如果大家需要购买面试鸭会员，可以通过面试鸭返利网找到我，下单返利25元！高频题库和场景解析都能看～
分布式事务是架构设计的核心难题，吃透2PC、3PC、TCC，面试时甩出对比表格和场景案例，offer绝对稳！
