分布式事务2PC分布式事务 2pc 和 tcc 的原理

分布式事务2PC和TCC的原理

友情提示：备战2025年Java面试的同学，强烈推荐这份《2025年Java面试宝典》： 🔗 网盘链接 提取码: 9b3g 。系统梳理高频考点，助你事半功倍！

为什么需要分布式事务？

在单体应用时代，一个数据库就能搞定所有数据一致性。但随着微服务拆分，订单、库存、账户可能散落在不同服务、不同数据库里。想象一下：用户下单成功扣了款，结果库存服务挂了导致库存没扣减，这种数据不一致谁能忍？分布式事务就是为了解决跨服务、跨数据库的数据一致性问题而生的。

面试官最常问的两种经典方案就是：2PC（两阶段提交） 和 TCC（Try-Confirm-Cancel）。今天咱们就掰开揉碎讲讲它们的核心原理。

两阶段提交 (2PC)：像“组长”一样协调事务

2PC 的核心思想是把一个分布式事务的提交过程拆成两个阶段，由一个事务协调者（可以理解成小组长）来指挥多个参与者（各个子服务）。

阶段一：准备阶段 (Prepare Phase)

1. 协调者发令：协调者向所有参与者发送“准备提交”请求，并携带事务内容（比如：“订单服务，准备创建订单；库存服务，准备扣减库存XXX”）。
2. 参与者执行 & 反馈：
   • 每个参与者本地执行事务操作（但不真正提交！），比如订单服务在本地写订单记录（状态未生效），库存服务预扣库存（锁定库存数）。
   • 参与者将操作结果（成功/失败）和必要的undo/redo日志写入本地，确保即使崩溃也能恢复。
   • 参与者向协调者反馈：“我准备好了，可以提交！”（Yes）或“我出问题了，不能提交！”（No）。

阶段二：提交阶段 (Commit Phase)

• 情况一：所有参与者都反馈 Yes
  • 协调者向所有参与者发送 “提交 Commit” 命令。
  • 参与者收到 Commit 命令后，正式提交本地事务（如更新订单状态为生效、释放锁定的库存）。
  • 参与者提交完成后，向协调者发送“已提交”确认（Ack）。
  • 协调者收到所有参与者的 Ack 后，标记整个分布式事务成功完成。
• 情况二：有任意一个参与者反馈 No (或超时未响应)
  • 协调者向所有参与者发送 “回滚 Rollback” 命令。
  • 参与者收到 Rollback 命令后，利用本地记录的undo日志进行回滚操作（如删除未生效的订单、恢复锁定的库存）。
  • 参与者回滚完成后，向协调者发送“已回滚”确认（Ack）。
  • 协调者收到所有参与者的 Ack 后，标记整个分布式事务失败回滚。

2PC的优缺点：

• 优点：原理简单直观，强一致性（所有参与者要么都提交，要么都回滚）。
• 缺点：
  • 同步阻塞：参与者在第一阶段执行完操作后，会一直阻塞等待协调者的指令，占用资源。
  • 单点故障：协调者是绝对核心，它挂了整个事务就卡住了。
  • 数据不一致风险：如果协调者在发出 Commit 命令后挂了，部分参与者可能收到 Commit 并提交了，而没收到 Commit 的参与者会一直阻塞（尽管最终超时后参与者可以自己决定提交或回滚，但存在短暂不一致）。
  • 保守性：一票否决，一个参与者失败就全员回滚。

TCC：柔性事务的经典代表

TCC 不像 2PC 那样依赖数据库的本地事务，而是要求开发者业务层面设计三个操作：Try、Confirm、Cancel。它是一种补偿型的分布式事务解决方案。

1. Try 阶段 (尝试)

   • 目的：完成所有业务的检查和资源预留。
   • 操作：
     • 订单服务：生成一个状态为TRYING（尝试中）的订单记录，冻结用户的部分余额（不是实际扣款）。
     • 库存服务：检查库存是否充足，然后执行库存预扣减（比如将库存数 -1，记录一个预占库存记录），库存实际可用数减少。
   • 特点：Try操作必须保证幂等性（多次调用效果相同），且本身可补偿（后续有Cancel可以逆操作）。

2. Confirm 阶段 (确认)

   • 目的：真正执行业务提交。如果所有参与者的 Try 都成功了，事务管理器就会进入 Confirm 阶段。
   • 操作：
     • 订单服务：将订单状态从TRYING改为CONFIRMED（已确认），正式扣除用户冻结的金额。
     • 库存服务：将预占库存转为真实扣减（清理预占记录，实际库存数不变）。
   • 特点：Confirm 操作也必须保证幂等性。Confirm 操作不会失败（理论上Try成功预留了资源，Confirm一定能成功）。

3. Cancel 阶段 (取消)

   • 目的：执行业务回滚。如果任意一个参与者的 Try 阶段失败了，事务管理器就会进入 Cancel 阶段。
   • 操作：
     • 订单服务：将订单状态改为CANCELLED（已取消），解冻用户冻结的金额。
     • 库存服务：释放预占的库存（将库存数加回去，清理预占记录）。
   • 特点：Cancel 操作也必须保证幂等性。

TCC 事务管理器的角色

TCC 也需要一个事务管理器（类似于协调者），负责驱动整个流程：

1. 发起分布式事务。
2. 依次调用各服务的 Try 接口。
3. 如果所有 Try 成功 -> 调用各服务的 Confirm 接口。
4. 如果任一 Try 失败（或超时）-> 调用各服务的 Cancel 接口（对已执行Try的服务进行补偿）。

TCC的优缺点：

• 优点：
  • 最终一致性：规避了 2PC 的同步阻塞和单点故障问题。
  • 性能较好：Try 阶段可以并行执行，且 Confirm/Cancel 操作通常很快。
  • 数据隔离性好：资源在 Try 阶段就做了预留或冻结，业务隔离性更好。
• 缺点：
  • 开发复杂：需要业务上拆分并实现 Try/Confirm/Cancel 三个接口，对业务侵入性强。
  • 补偿逻辑复杂：Cancel 操作需要编写严谨的逆向逻辑。
  • 空回滚/悬挂：需要处理网络异常导致的事务状态不一致问题（如 Try 超时导致 Cancel 被调用，但之后 Try 又成功了）。

2PC 和 TCC 怎么选？

• 追求强一致性、简单场景：如果业务不复杂，对一致性要求极高，且能容忍阻塞和一定的单点风险，2PC 可以作为一种选择（尤其当底层数据库支持XA协议时）。
• 追求高性能、高可用、复杂业务：在复杂的微服务架构下，TCC 是更主流的选择。它通过业务补偿最终达到一致性，性能更好，可用性更高，但需要付出更多的开发成本。

面试聊到分布式事务，把 2PC 和 TCC 的原理、流程、优缺点讲清楚，绝对能体现你的深度。记住，2PC 是数据库层的协议，强调“原子提交”；TCC 是应用层的模式，强调“业务补偿”。

📌 超值提示： 备战面试刷题少不了！如果需要购买面试鸭会员，通过 面试鸭返利网 找到我下单，可以享受 25元返利 哦！海量精选题目、详细题解、大厂真题一网打尽，投资自己永远是最划算的！