有了2阶段提交为什么还需要3阶段提交？

在分布式事务中，通常使用两阶段协议或三阶段协议来保障分布式事务的正常运行，它也是 X/Open 公司定义的一套分布式事务标准。 X/Open 公司是由多家国际计算机厂商所组成的联盟组织，它建立之初是为了向 UNIX 环境提供标准。 分布式事务是指在分布式系统中，多个节点之间进行的事务操作。比如在分布式系统中，用户在下单时，需要同时创建订单信息和减库存的操作，然而创建订单信息和减库存是分布在不同服务器和不同数据库中的，如下图所示：  此时我们就需要一个分布式事务介入，保证所有操作，要么一起提交，要么一起回滚。 1.两阶段提交 两阶段提交（Two-Phase Commit，简称 2PC）是一种分布式事务协议，确保所有参与者在提交或回滚事务时都处于一致的状态。2PC 协议包含以下两个阶段： 准备阶段（prepare phase）：在这个阶段，事务协调者（Transaction Coordinator）向所有参与者（Transaction Participant）发出准备请求，询问它们是否准备好提交事务。参与者执行所有必要的操作，并回复协调者是否准备好提交事务。如果所有参与者都回复准备好提交事务，协调者将进入下一个阶段。如果任何参与者不能准备好提交事务，协调者将通知所有参与者回滚事务。 提交阶段（commit phase）：在这个阶段，如果所有参与者都已准备好提交事务，则协调者向所有参与者发送提交请求。参与者执行所有必要的操作，并将其结果记录在持久性存储中。一旦所有参与者都已提交事务，协调者将向它们发送确认请求。如果任何参与者未能提交事务，则协调者将通知所有参与者回滚事务。 2PC 协议可以确保分布式事务的原子性和一致性，但是其效率较低，可能会出现阻塞等问题。因此，在实际应用中，可以使用其他分布式事务协议，如 3PC（Three-Phase Commit）或 Paxos 协议来代替。 两阶段提交问题 两阶段提交存在以下几个问题： 同步阻塞问题：执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。也就是说从投票阶段到提交阶段完成这段时间，资源是被锁住的。 单点故障：由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。 数据不一致问题：在 2PC 最后提交阶段中，当协调者向参与者发送 commit 请求之后，发生了局部网络异常或者在发送 commit 请求过程中协调者发生了故障，这会导致只有一部分参与者接受到了 commit 请求。而在这部分参与者接到 commit 请求之后就会执行 commit 操作。但是其他部分未接到 commit 请求的机器则无法执行事务提交，于是整个分布式系统便出现了数据不一致性的现象。 2.三阶段提交 三阶段提交（Three-Phase Commit，简称3PC）是在 2PC 协议的基础上添加了一个额外的阶段来解决 2PC 协议可能出现的阻塞问题。 3PC 协议包含三个阶段： CanCommit 阶段（询问阶段）：在这个阶段，事务协调者（Transaction Coordinator）向所有参与者（Transaction Participant）发出 CanCommit 请求，询问它们是否准备好提交事务。参与者执行所有必要的操作，并回复协调者它们是否可以提交事务。 PreCommit 阶段（准备阶段）：如果所有参与者都回复可以提交事务，则协调者将向所有参与者发送PreCommit 请求，通知它们准备提交事务。参与者执行所有必要的操作，并回复协调者它们是否已经准备好提交事务。 DoCommit 阶段（提交阶段）：如果所有参与者都已经准备好提交事务，则协调者将向所有参与者发送DoCommit 请求，通知它们提交事务。参与者执行所有必要的操作，并将其结果记录在持久性存储中。一旦所有参与者都已提交事务，协调者将向它们发送确认请求。如果任何参与者未能提交事务，则协调者将通知所有参与者回滚事务。 与 2PC 协议相比，3PC 协议将 CanCommit 阶段（询问阶段）添加到协议中，使参与者能够在 CanCommit 阶段发现并解决可能导致阻塞的问题。这样，3PC 协议能够更快地执行提交或回滚事务，并减少不必要的等待时间。需要注意的是，与 2PC 协议相比，3PC 协议仍然可能存在阻塞的问题。 3.两阶段提交 VS 三阶段提交 2PC 和 3PC 是分布式事务中两种常见的协议，3PC 可以看作是 2PC 协议的改进版本，相比于 2PC 它有两点改进： 引入了超时机制，同时在协调者和参与者中都引入超时机制（2PC 只有协调者有超时机制）； 3PC 相比于 2PC 增加了 CanCommit 阶段，可以尽早的发现问题，从而避免了后续的阻塞和无效操作。 也就是说，3PC 相比于 2PC，因为引入了超时机制，所以发生阻塞的几率变小了；同时 3PC 把之前 2PC 的准备阶段一分为二，变成了两步，这样就多了一个缓冲阶段，保证了在最后提交阶段之前各参与节点的状态是一致的。 4.数据一致性问题和解决方案 3PC 虽然可以减少同步阻塞问题和单点故障问题，但依然存在数据一致性问题（概率很小），而解决数据一致性问题的方案有很多，比如 Paxos 算法或柔性事物机制等。 4.1 Paxos 算法 Paxos 算法是一种基于消息传递的分布式一致性算法，并在 2013 年获得了图灵奖。 图灵奖（ACM A.M. Turing Award）是计算机科学领域最高荣誉之一，由美国计算机协会（ACM）于 1966 年设立，每年颁发一次，表彰对计算机科学领域做出杰出贡献的人士或团体。 简单来说，Paxos 算法是一种分布式共识算法，用于在分布式系统中实现数据的一致性和共识，保证分布式系统中不同节点之间的数据同步和一致性。 Paxos 算法由三个角色组成：提议者、接受者和学习者。当一个节点需要发起一个提议时，它会向其他节点发送一个提议，接受者会接收到这个提议，并对其进行处理，可能会拒绝提议，也可能会接受提议。如果有足够多的节点接受了该提议，那么提议就会被确定下来，并且通知给所有学习者，最终所有节点都会达成共识。 Paxos 算法看起来很简单，但它实际上是非常的复杂。 Paxos 算法应用的产品也很多，比如以下几个： Redis：Redis 是一个内存数据库，使用 Paxos 算法实现了分布式锁服务和主从复制等功能。 MySQL：MySQL 5.7 推出的用来取代传统的主从复制的 MySQL Group Replication 等。 ZooKeeper：ZooKeeper 是一个分布式协调服务，使用 Paxos 算法实现了分布式锁服务和数据一致性等功能。 Apache Cassandra：Cassandra 是一个分布式数据库系统，使用 Paxos 算法实现了数据的一致性和复制等功能。 Google Chubby：Chubby 是 Google 内部使用的分布式锁服务，使用 Paxos 算法实现了分布式锁服务和命名服务等功能。 4.2 柔性事务 柔性事务机制：允许一定时间内不同节点的数据不一致，但要求最终一致的机制。 柔性事物有 TCC 补偿事物、可靠消息事物（MQ 事物）等。 小结 在分布式事务中，通常使用两阶段或三阶段提交协议来保障分布式事务的正常执行。两阶段协议包含准备阶段和提交阶段，然而它存在同步阻塞问题、单点故障和数据一致性问题。而三阶段协议可以看作是两阶段协议的改进版，它将两阶段的准备阶段一分为二，多了一个询问阶段，保证了提交阶段之前各参与节点的状态是一致的，同时引入了超时机制，减少了同步阻塞问题发生的几率。但 2PC 和 3PC 都存在数据一致性问题，此时可以采用 Paxos 算法或柔性事务机制等方案来解决事务一致性问题。

两阶段提交（2PC）在理论上可以保证分布式事务的一致性，但在实际场景中存在一些局限性，特别是当系统发生**网络分区**或**节点故障**时，可能导致事务状态悬而未决。为了解决这些问题，三阶段提交（3PC）在 2PC 的基础上做了优化，以进一步提高事务的可用性和避免阻塞。 ### **2PC 的不足之处** 1. **阻塞问题**： - 在 2PC 的提交阶段，协调者（Transaction Manager，TM）如果崩溃，参与者（Resource Manager，RM）会因为等待提交或回滚指令而进入阻塞状态，资源无法释放。 2. **单点故障**： - 如果 TM 崩溃，整个事务状态可能无法确定。 3. **数据不一致**： - 在网络分区的场景中，部分参与者可能未收到提交或回滚指令，导致系统进入不一致状态。 ### **3PC 的改进** 三阶段提交（3PC）通过增加一个**准备提交阶段**，减少了系统阻塞的可能性，并降低了网络分区对事务状态一致性的影响。 #### **三阶段的流程** 1. **CanCommit 阶段（询问阶段）**： - TM 询问所有参与者是否可以执行事务（与 2PC 的第一阶段类似）。 - 如果所有参与者返回 "Yes"，进入第二阶段。 2. **PreCommit 阶段（预提交阶段）**： - TM 向所有参与者发送预提交请求。 - 参与者执行事务并写入日志，但不正式提交。 - 参与者向 TM 返回预提交成功的响应。 3. **DoCommit 阶段（提交阶段）**： - 如果 TM 收到所有参与者的预提交成功响应，则发送正式提交请求。 - 参与者正式提交事务。 - 如果任何参与者在 PreCommit 阶段失败，则 TM 发送回滚请求。 ### **3PC 的改进点** 1. **非阻塞**： - 3PC 在 PreCommit 阶段增加了超时机制。如果参与者未在规定时间内收到 TM 的 DoCommit 或回滚请求，可自行决定是否提交或回滚，减少了阻塞的风险。 2. **减少资源锁定时间**： - 在 PreCommit 阶段，事务尚未正式提交，但资源已准备好，可尽早释放部分锁定。 3. **网络分区容忍**： - 通过超时机制和日志的分阶段写入，参与者可以在部分通信失败的情况下尽量完成事务或回滚，降低不一致的可能性。 ### **为什么需要 3PC** 三阶段提交解决了 2PC 的以下问题： - **阻塞问题**：参与者不再永久等待 TM 的指令，可根据超时或状态自行决策。 - **单点故障**：TM 崩溃后，参与者仍可通过日志状态决定提交或回滚。 - **更高的容错性**：3PC 在网络分区场景下更适应，避免数据长时间不一致。 ### **3PC 的局限性** 尽管 3PC 在理论上优于 2PC，但它也有以下局限性： 1. **实现复杂性高**： - 增加了一个阶段，导致实现成本较高。 2. **性能开销大**： - 更多的网络通信和日志记录增加了事务的延迟。 3. **弱化了一致性**： - 由于参与者可以在超时后自行决策，可能会导致极端情况下出现数据不一致。 ### **实际场景中的选择** - **使用 2PC：** 如果系统的事务规模较小、网络稳定且对性能要求较高，可优先选择 2PC。 - **使用 3PC：** 如果系统对一致性和容错性要求极高，并且能够接受较高的延迟开销，可以考虑 3PC。 - **分布式事务框架（如 Seata）：** 大多数现代分布式事务框架基于 2PC，并通过优化和补偿机制（如 TCC、Saga）解决实际问题，而不是直接采用 3PC。 总结来说，三阶段提交是对两阶段提交的改进，主要解决了阻塞问题和网络分区场景下的一致性问题。但在实际应用中，由于其复杂性和性能开销，更多框架会基于 2PC 进行扩展，而不是直接使用 3PC。