分布式协同 - 分布式事务_2PC 3PC解决方案

导图

Pre

分布式协同 - 分布式事务一二事儿DTP 定义了分布式事务的处理模型，可以针对这个模型提出分布式事务的解决方案，2PC 就是其中一种。

2PC 的全称为两阶段提交（Two Phase Commitment Protocol），是 DTP 模型的最佳实践，解决了在分布式服务或数据库场景下，同一事务对多个节点进行操作的数据一致性问题。

2PC 在一定程度上遵守 ACID 理论的刚性事务的要求，保证了强一致性。 2PC 中有两个概念，

• 一个是事务协调者，对应 DTP 模型中的事务管理器，用来协调事务，所有事务什么时候准备好、什么时候可以提交都由它来协调和管理；
• 另一个是事务参与者，对应 DTP 模型中的资源管理器，主要负责处理具体事务、管理需要处理的资源。例如事务参与者可以处理订票业务，扣款业务。

2PC（Two-Phase Commit）协议

+-----------------+                +------------------+                +-----------------+
|   Transaction   |                |   Coordinator    |                |   Participant   |
|     Client      |                |       Node       |                |       Node      |
+-----------------+                +------------------+                +-----------------+
        |                                  |                                   |
        |----------(1) Request Start ------>                                   |
        |                                  |                                   |
        |                                  | --------------(2) Prepare-------->|
        |                                  |                                   |
        |                                  | <--------- (3) Acknowledge ------|
        |                                  |                                   |
        |                                  |                                   |
        |                                  | --------------(4) Commit--------->|
        |                                  |                                   |
        |                                  | <--------- (5) Acknowledge ------|
        |                                  |                                   |
        |                                  |                                   |
        |                                (End)                               (End)

准备阶段

第一阶段（准备阶段）：如下图 所示

事务协调者（事务管理器）给每个事务参与者（资源管理器）发送准备（prepare）消息，目的是询问大家是不是都准备好了，马上就要执行事务了。事务参与者会根据自身业务和资源情况进行检查，然后给出反馈。检查过程根据业务内容的不同而不同，例如订票业务需要检查是否有剩余票、扣款业务需要检查余额是否足够。

只有检查通过，才能返回就绪（ready）信息。否则，事务将终止，并且等待下次询问。由于检查过程需要完成一些操作，因此需要写 redo 日志和 undo 日志，以便事务失败重试，或者失败回滚时使用。

提交阶段

第二阶段（提交阶段）：如下图所示

如果事务协调者接收到事务参与者检查失败或者超时的消息，会给其发送回滚（rollback）消息，否则发送提交（commit）消息。

情况 1：只要有一个事务参与者反馈未就绪（no ready），事务协调者就会回滚事务

• a) 事务协调者向所有事务参与者发出回滚请求。
• b) 事务参与者使用第一阶段中 undo 日志里的信息执行回滚操作，并且释放整个事务期间占用的资源。
• c) 各事务参与者向事务协调者反馈应答（ack）消息，表示完成操作。
• d) 事务协调者接收到所有事务参与者反馈的应答消息，即完成了事务回滚。

情况 2：当所有事务参与者均反馈就绪（ready）消息时，事务协调者会提交（commit）事务

• a) 事务协调者向所有事务参与者发出正式提交事务的请求。
• b) 事务参与者执行提交（commit）操作，并释放整个事务期间占用的资源。
• c) 各事务参与者向事务协调者反馈应答（ack）消息，表示完成操作。
• d) 事务协调者接收到所有事务参与者反馈的应答（ack）消息，即完成了事务提交。

3PC（Three-Phase Commit）协议

3PC（三阶段提交）是分布式事务中的一种协议，旨在解决2PC协议中的阻塞问题。3PC协议通过在2PC的基础上增加了一个阶段，增加了事务的容错能力，从而避免了协调者或参与者崩溃时可能发生的阻塞现象。

3PC的三个阶段

1. CanCommit 阶段（询问阶段）

   • 协调者向所有参与者发送“CanCommit”请求，询问它们是否可以提交事务。
   • 参与者收到请求后，会检查本地的事务状态。如果没有冲突，且可以提交，它们就返回“Ready”响应；如果事务存在问题，则返回“No”响应，表示无法提交。

2. PreCommit 阶段（预提交阶段）

   • 如果所有参与者都返回了“Ready”，协调者就会向所有参与者发送“PreCommit”命令，表示准备提交事务，并让它们锁定相关资源。
   • 参与者在接收到“PreCommit”命令后，执行事务的预提交操作并返回确认。

3. DoCommit 阶段（提交阶段）

   • 如果所有参与者都返回了预提交确认（“PreCommit”），协调者会向所有参与者发送“DoCommit”命令，正式提交事务。
   • 参与者接收到“DoCommit”命令后，执行提交操作，事务完成。

3PC 的流程

+-----------------+                +------------------+                +-----------------+
|   Transaction   |                |   Coordinator    |                |   Participant   |
|     Client      |                |       Node       |                |       Node      |
+-----------------+                +------------------+                +-----------------+
        |                                  |                                   |
        |----------(1) Request Start ------>                                   |
        |                                  |                                   |
        |                                  |  --------(2) CanCommit --------->|
        |                                  |                                   |
        |                                  | <----------(3) Ready/No --------|
        |                                  |                                   |
        |                                  |  --------(4) PreCommit --------->|
        |                                  |                                   |
        |                                  | <----------(5) PreCommitAck -----|
        |                                  |                                   |
        |                                  |  --------(6) DoCommit ---------->|
        |                                  |                                   |
        |                                  | <----------(7) DoCommitAck ------|
        |                                  |                                   |
        |                                (End)                               (End)

3PC 和 2PC 的主要区别

1. 阶段数量不同

• 2PC 有两个阶段：

  1. Prepare: 协调者询问参与者是否能提交事务。
  2. Commit/Abort: 根据参与者的响应，协调者决定是否提交或回滚事务。

• 3PC 有三个阶段：

  1. CanCommit: 协调者询问参与者是否准备提交。
  2. PreCommit: 协调者发送预提交命令，参与者准备提交并锁定资源。
  3. DoCommit: 协调者发送最终提交命令，事务正式提交。

2. 容错能力

• 2PC 在协调者或参与者崩溃时可能会出现阻塞。例如，如果协调者崩溃后，参与者不知道是应该提交还是回滚，系统可能会陷入阻塞状态，无法继续执行。
• 3PC 增加了一个额外的阶段（PreCommit），并且在每个阶段都有明确的响应协议，可以减少系统在协调者或参与者崩溃时的阻塞风险。3PC通过引入超时机制和预提交锁定，有效减少了数据不一致和系统停滞的概率。

3. 协议的安全性与复杂性

• 2PC 协议相对简单，但存在阻塞问题，且在部分情况下（例如，协调者崩溃），事务无法保证最终一致性。
• 3PC 协议在设计上更加复杂，通过引入预提交阶段，提高了系统的容错能力，但也增加了协议的开销和实现的复杂性。

4. 阻塞问题

• 2PC 存在阻塞问题，特别是在协调者或参与者崩溃的情况下，事务无法继续或回滚，可能会导致长时间的停滞。
• 3PC 通过引入额外的阶段，并要求所有参与者在每个阶段都给予明确的响应，避免了阻塞的可能性。当协调者或参与者崩溃时，系统会通过超时机制自动恢复，减少了长时间的停滞。

5. 事务资源锁定

• 2PC 中，事务资源在提交后才被释放，可能会因为参与者的延迟或崩溃导致长时间的资源占用。
• 3PC 引入了预提交阶段，在PreCommit时就锁定了资源并确保它们在提交前是有效的，因此能更有效地管理资源的占用。

6. 性能开销

• 2PC 因为只有两个阶段，协议简单，性能相对较好，但当系统出现故障时，性能和一致性会受到较大影响。
• 3PC 虽然增加了一个阶段，但引入了更多的容错机制，可能会有稍微的性能开销，但能在故障恢复时保持更高的可用性。

总结

• 2PC 由于其简单的设计，适用于一些不涉及复杂容错的场景，但它容易因为崩溃或故障导致阻塞问题，事务可能无法继续进行。
• 3PC 在 2PC 的基础上增加了一个阶段，提升了系统容错能力，减少了由于协调者或参与者崩溃导致的阻塞，但相应地增加了协议的复杂度和性能开销。

在选择2PC还是3PC时，需要根据具体应用场景的容错要求、性能需求以及系统复杂度进行权衡。