04.分布式事务

分布式事务相关算法：

角色：

• 协调者
• 参与者

XA模式、AT模式：

• XA模式：2PC，使用回滚
• AT模式：TCC，利用补偿

2PC ：

• 准备阶段：
  • 协调者向所有参与者发送准备请求，参与者执行预操作并记录日志，但不提交，进入准备阶段。
• 提交阶段：
  • 如果所有参与者都准备就绪，协调者发送提交请求，参与者提交操作；
  • 否则，协调者发送回滚请求，参与者回滚操作。
• 存在的问题：
  • 协调者单点故障问题
  • 参与者等待指令期间阻塞
  • 延迟问题
• 适用场景：
  • 在某些需要强一致性的分布式事务管理系统
  • MySQL、ZooKeeper

3PC ：

• 目标：在2PC基础上减少阻塞和单点故障问题
• 准备阶段：
  • 每个参与者执行事务操作，但不提交，只写入日志并锁定资源，进入准备阶段
• 预备提交阶段：
  • 协调者在收到所有参与者的准备好的响应后，向所有参与者发送预备提交请求
  • 参与者在接收到预备提交请求后，执行预备提交操作，将事务状态标记为"可以提交"，但仍不实际提交事务，进入预备提交阶段。
  • 优点：
    • 参与者无需阻塞在准备阶段，进一步减少了协调者和参与者的等待时间
    • 协调者发生故障，参与者也能根据事务状态决定是否提交或回滚
  • 本质：通过减少锁粒度，避免阻塞
• 提交阶段：
• 存在的问题：
  • 比2PC更复杂，需要处理更多的状态和通信步骤
  • 多了一个预备提交阶段的RTT
  • 仍然存在阻塞问题
• 适用场景：
  • 分布式文件系统、大型分布式系统的配置管理工具

TCC ：

• 定义：

  • TCC本质上是一个应用层面的2PC，对代码的侵入性强
  • TCC（Try-Confirm/Cancel）模式是一种柔性事务管理方式，适用于长时间运行的分布式事务。
  • TCC模式通过将事务分为三个步骤：Try、Confirm和Cancel，来确保分布式系统中的一致性和可靠性。

• 核心：

  • 业务涉及上针对每个操作，都要实现对应的确认和补偿操作

• Try 阶段：

  • 在Try阶段，各个参与者执行必要的检查和资源预留操作，确保后续的Confirm阶段能够顺利进行。这一步主要用于验证所有操作是否可以成功执行，并预留所需资源。

• Confirm 阶段：

  • 各个参与者正式提交之前预留的资源和操作。这一步确保所有参与者的操作被最终确认和提交。

• Cancel 阶段：

  • 在Cancel阶段，如果Try阶段的任何操作失败或事务被取消，各个参与者回滚之前预留的资源和操作，确保系统恢复到初始状态。

• 缺点：

  • 实现复杂，业务耦合度较高，开发成本高

• 优点：

  • 灵活性高，允许在事务的每个阶段进行检查和预留资源
  • 减少阻塞时间，将事务分为三个步骤
  • 补偿机制，Cancel阶段回滚

• 适用场景：

  • 分布式订单系统、分布式支付系统