分布式事务2PC分布式事务 2pc 3pc tcc

分布式事务2PC分布式事务 2pc 3pc tcc

🔥 2025年Java面试宝典重磅分享：
链接: https://pan.baidu.com/s/1RUVf75gmDVsg8MQp4yRChg?pwd=9b3g
提取码: 9b3g
(建议保存备用，涵盖分布式事务等高频考点)

为什么分布式事务是面试必考题？

现在稍微大点的系统都是分布式架构，但多个服务/数据库之间如何保证数据一致性？面试官就爱问这个！分布式事务解决方案里，2PC、3PC、TCC这三个兄弟出场率超高，今天咱们掰开揉碎讲明白。

一、2PC：两阶段提交协议

分布式事务协调者（Coordinator）像导演一样指挥参与者（Participant）：

1. 准备阶段：协调者问所有参与者："能提交不？"
   
   参与者检查自身状态（比如资源是否锁定），回复YES/NO。

2. 提交阶段：

   • 如果全员YES → 协调者发"提交"指令
   • 如果有人NO → 协调者发"回滚"指令

✅ 优点：强一致性保证，适合数据库层（如MySQL XA）
❌ 致命伤：

• 同步阻塞：参与者卡在等待指令（万一协调者挂了就死锁）
• 单点故障：协调者崩了全系统瘫痪

📌 面试坑点：很多面试官会追问："2PC超时了怎么办？" —— 记住这是2PC最大痛点！

二、3PC：三阶段提交的改进

为了解决2PC阻塞问题，3PC多加了预提交阶段：

1. CanCommit：协调者问："有提交的能力不？"（轻量检查）
2. PreCommit：全员YES则发预提交指令，参与者锁定资源
   
3. DoCommit：正式提交

🔁 优化点：

• 参与者超时未收到指令会自动提交（降低阻塞概率）
• 引入协调者选举机制（比如用ZooKeeper）避免单点故障

💡 本质：3PC用复杂度换可用性，但依然无法100%避免数据不一致（比如网络分区时）

三、TCC：业务层的补偿模式

TCC（Try-Confirm-Cancel）把分布式事务控制权交给业务代码：

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

✈️ 场景：电商下单（订单+库存+优惠券服务）

• Try阶段：创建订单（待支付）、锁库存、锁优惠券
• Confirm：支付成功，确认生效
• Cancel：支付失败，全部解锁

⚠️ 注意事项：

1. 所有服务需实现Try/Confirm/Cancel接口
2. 需配合重试+幂等（防止网络抖动导致重复调用）

四、三种方案怎么选？

| 方案 | 一致性 | 性能 | 适用场景 |
|-------|--------|-------|-------------------|
| 2PC | 强一致 | 低 | 数据库层（如XA） |
| 3PC | 较强 | 中 | 少用，过渡方案 |
| TCC | 最终一致 | 高 | 业务复杂场景 |

💰 实战技巧：

• 资金交易用TCC（比如转账必须可回滚）
• 简单查询用异步消息（如发短信通知）
• 强一致性要求用2PC+重试补偿

五、面试怎么答能加分？

1. 一定说清楚2PC阻塞问题和TCC的补偿思想
2. 提一嘴Seata框架（它实现了这些模式）
3. 强调最终一致性的trade-off："根据业务容忍度选方案"

👉 重要提示：如果大家需要购买面试鸭会员，可以通过面试鸭返利网找到我，下单返利25元！高频题库和场景解析都能看～

分布式事务是架构设计的核心难题，吃透2PC、3PC、TCC，面试时甩出对比表格和场景案例，offer绝对稳！

返回首页