分布式事务解决方案(二):两阶段提交协议(2PC)与三阶段提交协议(3PC)

下面分别结束两阶段提交协议(2PC)及三阶段提交协议(3PC):

如上图,TM实现了多个RM事务的管理,实际上会涉及两个阶段的提交,第一阶段的提交,第一阶段是事务的准备阶段,第二个阶段为事务的提交或者回滚阶段。这两个阶段都是事务管理器发起的。两阶段提交协议的执行流程如下。

（Undo日志是记录修改前的数据，用于数据库回滚，Redo日志是记录修改后的数据，用于提交事务后写入数据文件）

两阶段提交协议

• 准备阶段:事务管理器(TM)通知资源管理器(RM)准备分支事务,记录事务日志,并告知事务管理器准备结果.
• 提交/回滚阶段: 如果所有的资源管理器(RM)在准备阶段都明确返回成功,则事务管理器(TM)向所有的资源管理器(RM)发起事务提交指令完成数据的变更。反之,如果任何一个资源管理器(RM)明确返回失败,则事务管理器(TM)会向所有资源管理器(RM)发送事务回滚指令，具体执行流程如下图:

两阶段提交将一个事务的处理过程分为投票和执行两个阶段,它的优点在于充分考虑到了分布式系统的不可靠因素,并且采用非常简单的方式(两阶段提交)就把由于系统不可靠而导致事务提交失败的概率降到最小。当然，它也并不是完美的，存在以下缺点:

•       同步阻塞: 从上图执行流程来看,所有参与者(RM)都是事务阻塞型的,对应任何一次指令都必须要有明确响应才能进行下一步,否则会处于阻塞状态,占用的资源一直被锁定。
•       过于保守:  任何一个节点失败都会导致事务数据回滚。
•       事务协调者的单点故障： 如果协调者在第二阶段出现了故障,那么其他的参与者commit会一直处于锁定状态。
•       "脑裂"导致数据不一致问题:  在第二阶段事务协调者向所有参与者(RM)发送commit请求后，发生局部网络异常导致只有一部分参与者(RM)接收到commit请求,这部分参与者(RM)接收到请求后会执行commit操作，但是未收到commit请求的节点由于事务无法提交,导致数据出现不一致问题。

  三阶段提交协议

 三阶段提交协议是两阶段提交协议的改进版本,它利用超时机制解决了同步阻塞的问题,三阶段提交协议的具体描述如下:

•         CanCommit(询问阶段): 事务协调者向参与者发送事务执行请求,询问是否可以完成指令,参与者只需要回答是不是即可,不需要做正真的事务操作,这个阶段会有超时终止机制。
•         PreCommit(准备阶段): 事务协调者会根据参与者的反馈结果决定是否继续执行,如果在询问阶段所有参与者都返回可以执行操作,则事务协调者会向所有参与者发送PreCommit请求,参与者收到请求后会写redo和undo日志,执行事务操作但是不提交事务,然后返回ACK响应等待事务协调者的下一步通知。如果询问阶段任意参与者返回不能执行操作的结果,那么事务协调者会向所有参与者发送事务中断请求。
•        DoCommit(提交或回滚阶段): 这个阶段也会存在两种结果,任然根据上一步骤的执行结果来决定DoCommit的执行方式。如果每个参与者在PreCommit阶段都返回成功,那么事务协调者会向所有的参与者发起事务提交指令。反之,如果参与者中的任一个参与者返回失败,那么事务协调者就会发起中转指令来回滚事务。

三阶段提交协议的时序图如下图所示:

三阶段提交与两阶段提交协议相比有一些不同点:

实际上,一旦超时,在三阶段提交协议下仍然可能出现数据不一致的情况，当然概率是比较小的。另外,最大的好处就是基于超时机制来避免资源的永久锁定。需要注意的是,不管是两阶段提交协议还是三阶段提交协议,都是数据一致性解决的方案的实现,我们可以在实际应用中灵活调整。比如Zookeeper集群中的数据一致性，就用到了优化版的两阶段提交协议,优化的地方在于，它不需要所有参与者都在第一阶段返回成功后才能提交事务,而是利用少数服从多数的投票机制来完成数据的提交或者回滚。