分布式 二阶段提交

二阶段提交（Two-Phase Commit，2PC）是一种分布式事务协议，旨在确保分布式系统中所有参与者要么全部完成事务，要么全部回滚事务，从而保证数据的一致性。

阶段 1：准备阶段（Prepare Phase）

1. 协调者（Coordinator）发起事务请求： 协调者向所有参与者（Participants）发送一个 "prepare" 消息，询问是否可以提交事务。
2. 参与者执行事务： 收到 "prepare" 消息后，每个参与者执行以下操作：
   • 尝试执行事务，并在本地完成所有必要的准备工作（例如，锁定资源，写入 redo/undo 日志）。
   • 不提交事务： 关键在于，此时参与者只是准备好提交，但并不真正提交。
   • 回复协调者： 参与者向协调者回复一个 "yes" (同意) 或 "no" (拒绝) 的消息，表明自己是否准备好提交。

阶段 2：提交/回滚阶段（Commit/Rollback Phase）

• 如果所有参与者都同意：

  1. 协调者发送提交请求： 协调者收到所有参与者的 "yes" 消息后，向所有参与者发送 "commit" 消息。
  2. 参与者提交事务： 收到 "commit" 消息后，参与者完成事务的提交。
  3. 参与者回复协调者： 参与者向协调者回复 "ack" 消息，确认提交完成。
  4. 协调者完成事务： 协调者收到所有参与者的 "ack" 消息后，认为事务已成功完成。

• 如果任何一个参与者拒绝，或者协调者超时未收到所有参与者的回复：

  1. 协调者发送回滚请求： 协调者向所有参与者发送 "rollback" 消息。
  2. 参与者回滚事务： 收到 "rollback" 消息后，参与者回滚事务，撤销之前所做的所有操作。
  3. 参与者回复协调者： 参与者向协调者回复 "ack" 消息，确认回滚完成。
  4. 协调者完成事务： 协调者认为事务已回滚。

优缺点

• 优点：
  • 原理简单，容易理解和实现。
  • 尽力保证了分布式事务的一致性。
• 缺点：
  • 同步阻塞： 在整个 2PC 过程中，所有参与者都需要等待协调者的指令，导致资源锁定时间过长，并发性能较差。
  • 单点故障： 协调者是中心节点，如果协调者发生故障，整个系统都将受到影响。
  • 数据不一致的风险： 虽然概率较低，但在某些极端情况下（例如，在第二阶段协调者崩溃），可能导致数据不一致。

适用场景

2PC 适用于对数据一致性要求非常高的场景，例如金融交易等。但是，由于其性能瓶颈，通常只在 ACID 事务可以接受的范围内使用。

希望这些信息对您有所帮助!

TCC 协议

TCC（Try-Confirm-Cancel）是一种分布式事务协议，是针对两阶段提交（2PC）协议的改进版本。它通过将业务逻辑分解为三个阶段来解决 2PC 的一些问题，尤其是在性能和可用性方面。

三个阶段

1. Try 阶段：

   • 资源预留： Try 阶段的主要目标是尝试执行业务操作，并预留所需的资源。
   • 检查和准备： 在这个阶段，系统会检查各种业务约束，并为后续的 Confirm 或 Cancel 阶段做好准备。
   • 可补偿性： Try 阶段的设计必须是可补偿的，也就是说，即使后续的 Confirm 阶段失败，也能通过 Cancel 阶段释放 Try 阶段预留的资源，恢复到事务开始之前的状态。
   • 不提交事务： 类似于 2PC 的 Prepare 阶段，Try 阶段并不实际提交事务。

2. Confirm 阶段：

   • 业务确认： 如果 Try 阶段成功，且所有参与者都同意提交事务，则进入 Confirm 阶段。
   • 完成事务： Confirm 阶段会执行真正的业务操作，完成事务的提交。
   • 快速完成： Confirm 阶段应该设计得尽可能简单快速，避免引入复杂的业务逻辑。通常只需要执行一些状态更新操作。
   • 幂等性： Confirm 阶段必须是幂等的，也就是说，可以重复执行多次，而结果始终保持一致。这是为了应对可能出现的网络异常或系统故障。

3. Cancel 阶段：

   • 资源释放： 如果 Try 阶段失败，或者后续的 Confirm 阶段无法执行，则进入 Cancel 阶段。
   • 事务回滚： Cancel 阶段会释放 Try 阶段预留的所有资源，撤销之前所做的所有操作，将系统恢复到事务开始之前的状态。
   • 可重试性： Cancel 阶段也需要考虑可重试性，以应对可能出现的异常情况。
   • 幂等性： Cancel 阶段同样必须是幂等的。

TCC 的优势

• 性能提升： TCC 将资源锁定时间缩短到只有 Try 阶段，Confirm 和 Cancel 阶段执行速度快，减少了事务的整体阻塞时间，提高了并发性能。
• 灵活性： TCC 允许业务系统自定义事务操作，可以根据实际场景选择合适的资源预留策略。
• 最终一致性： TCC 通过 Confirm 和 Cancel 两个阶段保证了事务的最终一致性。

TCC 的挑战

• 开发复杂度高： 相对于 2PC，TCC 的实现更加复杂，需要开发人员仔细设计 Try、Confirm 和 Cancel 三个阶段的业务逻辑。
• 业务侵入性： TCC 对业务代码有一定的侵入性，需要修改现有的业务逻辑以适应 TCC 的事务模型。
• 异常处理： 需要考虑各种异常情况，例如网络异常、系统故障等，并设计相应的重试和补偿机制。

适用场景

TCC 适用于对性能要求较高，允许最终一致性的分布式事务场景。例如，跨数据库的转账、支付等业务。

与 2PC 的比较

Feature	2PC	TCC
锁定资源	整个事务期间锁定	Try 阶段锁定，Confirm/Cancel 阶段释放
性能	较低	较高
开发复杂度	较低	较高
业务侵入性	较低	较高
一致性	强一致性	最终一致性
适用场景	对一致性要求极高的场景	对性能有较高要求的场景

总而言之，TCC 是一种比 2PC 更灵活、性能更高的分布式事务解决方案，但同时也带来了更高的开发复杂度和对业务的侵入性。选择哪种方案取决于具体的业务需求和系统架构。