在分布式事务中，通常使用两阶段协议或三阶段协议来保障分布式事务的正常运行，它也是 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 算法或柔性事务机制等方案来解决事务一致性问题。
参考 & 鸣谢
https://pdai.tech/md/arch/arch-z-transection.html
本文已收录到我的小站 www.javacn.site，其中包含的内容有：Redis、JVM、并发、并发、MySQL、Spring、Spring MVC、Spring Boot、Spring Cloud、MyBatis、设计模式、消息队列等模块。
