分布式事务两阶段提交和三阶段提交
在分布式事务中,通常使用两阶段协议或三阶段协议来保障分布式事务的正常运行,它也是 X/Open 公司(国际计算机厂商所组成的联盟组织)定义的一套分布式事务标准。
分布式事务是指在分布式系统中,多个节点之间进行的事务操作。
此时我们就需要一个分布式事务介入,保证所有操作,要么一起提交,要么一起回滚(只是举例,实践情况,对于有些服务不一定一起提交,例如商户余额加款有可能本身就是异步进行,这里只是举个例子)。
两阶段提交
两阶段提交(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 请求的机器则无法执行事务提交,于是整个分布式系统便出现了数据不一致性的现象。
三阶段提交
三阶段提交(Three-Phase Commit,简称3PC)是在 2PC 协议的基础上添加了一个额外的阶段来解决 2PC 协议可能出现的阻塞问题。 3PC 协议包含三个阶段:
- CanCommit 阶段(询问阶段):在这个阶段,事务协调者(Transaction Coordinator)向所有参与者(Transaction Participant)发出 CanCommit 请求,询问它们是否准备好提交事务。参与者执行所有必要的操作,并回复协调者它们是否可以提交事务。
- PreCommit 阶段(准备阶段):如果所有参与者都回复可以提交事务,则协调者将向所有参与者发送PreCommit 请求,通知它们准备提交事务。参与者执行所有必要的操作,并回复协调者它们是否已经准备好提交事务。
- DoCommit 阶段(提交阶段):如果所有参与者都已经准备好提交事务,则协调者将向所有参与者发送DoCommit 请求,通知它们提交事务。参与者执行所有必要的操作,并将其结果记录在持久性存储中。一旦所有参与者都已提交事务,协调者将向它们发送确认请求。如果任何参与者未能提交事务,则协调者将通知所有参与者回滚事务。
与 2PC 协议相比,3PC 协议将 CanCommit 阶段(询问阶段)添加到协议中,使参与者能够在 CanCommit 阶段发现并解决可能导致阻塞的问题。这样,3PC 协议能够更快地执行提交或回滚事务,并减少不必要的等待时间。需要注意的是,与 2PC 协议相比,3PC 协议仍然可能存在阻塞的问题。
两阶段提交 VS 三阶段提交
2PC 和 3PC 是分布式事务中两种常见的协议,3PC 可以看作是 2PC 协议的改进版本,相比于 2PC 它有两点改进:
- 引入了超时机制,同时在协调者和参与者中都引入超时机制(2PC 只有协调者有超时机制);
- 3PC 相比于 2PC 增加了 CanCommit 阶段,可以尽早的发现问题,从而避免了后续的阻塞和无效操作。
也就是说,3PC 相比于 2PC,因为引入了超时机制,所以发生阻塞的几率变小了;同时 3PC 把之前 2PC 的准备阶段一分为二,变成了两步,这样就多了一个缓冲阶段,保证了在最后提交阶段之前各参与节点的状态是一致的。
数据一致性问题和解决方案
3PC 虽然可以减少同步阻塞问题和单点故障问题,但依然存在数据一致性问题(概率很小),而解决数据一致性问题的方案有很多,比如 Paxos 算法或柔性事物机制等。
Paxos 算法
Paxos 算法是一种基于消息传递的分布式一致性算法,并在 2013 年获得了图灵奖。
简单来说,Paxos 算法是一种分布式共识算法,用于在分布式系统中实现数据的一致性和共识,保证分布式系统中不同节点之间的数据同步和一致性。
Paxos 算法由三个角色组成:提议者、接受者和学习者。当一个节点需要发起一个提议时,它会向其他节点发送一个提议,接受者会接收到这个提议,并对其进行处理,可能会拒绝提议,也可能会接受提议。
如果有足够多的节点接受了该提议,那么提议就会被确定下来,并且通知给所有学习者,最终所有节点都会达成共识。
- Redis:Redis 是一个内存数据库,使用 Paxos 算法实现了分布式锁服务和主从复制等功能。
- MySQL:MySQL 5.7 推出的用来取代传统的主从复制的 MySQL Group Replication 等。
- ZooKeeper:ZooKeeper 是一个分布式协调服务,使用 Paxos 算法实现了分布式锁服务和数据一致性等功能。
- Apache Cassandra:Cassandra 是一个分布式数据库系统,使用 Paxos 算法实现了数据的一致性和复制等功能。
- Google Chubby:Chubby 是 Google 内部使用的分布式锁服务,使用 Paxos 算法实现了分布式锁服务和命名服务等功能。
柔性事务
柔性事务机制:允许一定时间内不同节点的数据不一致,但要求最终一致的机制。 柔性事物有 TCC 补偿事物、可靠消息事物(MQ 事物)等。
小结
在分布式事务中,通常使用两阶段或三阶段提交协议来保障分布式事务的正常执行。两阶段协议包含准备阶段和提交阶段,然而它存在同步阻塞问题、单点故障和数据一致性问题。而三阶段协议可以看作是两阶段协议的改进版,它将两阶段的准备阶段一分为二,多了一个询问阶段,保证了提交阶段之前各参与节点的状态是一致的,同时引入了超时机制,减少了同步阻塞问题发生的几率。但 2PC 和 3PC 都存在数据一致性问题,此时可以采用 Paxos 算法或柔性事务机制等方案来解决事务一致性问题。