三阶段提交协议

三阶段提交协议 (Three-phase commit protocol, 3PC) 通常被认为是 2PC 的升级版,可以保证一个事务跨越多个节点时保持 ACID 特性。

在三阶段提交协议中,系统一般包含两类机器(或节点):一类为协调者(coordinator),通常一个系统中只有一个;另一类为事务参与者(participants,cohorts或workers),一般包含多个。

运行过程

1、第一阶段(can_commit)

该阶段协调者会去询问各个参与者是否能够正常执行事务,参与者根据自身情况回复一个预估值,相对于真正的执行事务,这个过程是轻量的,具体步骤如下:

(1) 协调者向各个参与者发送事务询问通知,询问是否可以执行事务操作,并等待回复

(2) 各个参与者依据自身状况回复一个预估值,如果预估自己能够正常执行事务就返回确定信息,并进入预备状态,否则返回否定信息

2、第二阶段(pre_commit)

本阶段协调者会根据第一阶段的询盘结果采取相应操作,询盘结果主要有三种:

(1) 所有的参与者都返回确定信息 (2) 一个或多个参与者返回否定信息 (3) 协调者等待超时。

针对第一种情况,协调者会向所有参与者发送事务执行请求,具体步骤如下:

(1) 协调者向所有的事务参与者发送事务执行通知 (2) 参与者收到通知后,执行事务,但不提交 (3) 参与者将事务执行情况返回给客户端

在上面的步骤中,如果参与者等待超时,则会中断事务。 针对第二、三种情况,协调者认为事务无法正常执行,于是向各个参与者发出 abort 通知,请求退出预备状态,具体步骤如下:

(1) 协调者向所有事务参与者发送 abort 通知 (2) 参与者收到通知后,中断事务

3、第二阶段(do_commit)

如果第二阶段事务未中断,那么本阶段协调者将会依据事务执行返回的结果来决定提交或回滚事务,分为三种情况:

(1) 所有的参与者都能正常执行事务 (2) 一个或多个参与者执行事务失败 (3) 协调者等待超时

针对第一种情况,协调者向各个参与者发起事务提交请求,具体步骤如下:

(1) 协调者向所有参与者发送事务 commit 通知 (2) 所有参与者在收到通知之后执行 commit 操作,并释放占有的资源 (3) 参与者向协调者反馈事务提交结果

针对第二、三种情况,协调者认为事务无法正常执行,于是向各个参与者发送事务回滚请求,具体步骤如下:

(1) 协调者向所有参与者发送事务 rollback 通知 (2) 所有参与者在收到通知之后执行 rollback 操作,并释放占有的资源 (3) 参与者向协调者反馈事务提交结果

3PC

和2PC的不同

对于协调者 (Coordinator) 和参与者 (Cohort) 都设置了超时机制(在 2PC 中,只有协调者拥有超时机制,即如果在一定时间内没有收到 cohort 的消息则默认失败)。 在 2PC 的准备阶段和提交阶段之间,插入预提交阶段,使 3PC 拥有 CanCommit、 PreCommit、 DoCommit三个阶段。 PreCommit是一个缓冲,保证了在最后提交阶段之前各参与节点的状态是一致的。

缺点

如果进入 PreCommit 后,Coordinator 发出的是 abort 请求,假设只有一个 Cohort 收到并进行了 abort 操作,而其他对于系统状态未知的 Cohort 会根据 3PC 选择继续 Commit,此时系统状态发生不一致性