先来露怯一波：记得我工作年在做DBA的时候，周末去一个培训机构听数据库相关的讲座，当时提到了广义上分布式事务的问题，旁边一个地中海的老哥，脱口而出两段式提交。当时的我并不太了解这个知识点，网上也搜了下资料，瞬间崩溃，完全看不懂。感叹当初要是有那么一套系列文章该有多好。

在上一篇分布式事务中，我们了解到了什么是分布式事务，分布式事务的分类有哪些。在解决方案上，分布式事务分为刚性事务和柔性事务。

这里我们趁着这个机会重点讲一下刚性事务，顺便解一下当年之痛。

刚性事务

刚性事务是指从底层服务端的解决方案，业务并不需要在业务层面做逻辑调整。实现的是强一致性，但由于同步阻塞的问题，导致并发性差，因此适合短事务。在刚性事务中代表方案为2PC、3PC即两段式提交和三段式提交。

XA协议

在提及分段式提交之前，我们先介绍下XA协议。XA协议是在1994年由Tuxedo提出的，并且提交给X/Open组织，在XA协议提出之后，各大主流的数据库产品也纷纷提供了对XA协议的支持，比如Oracle、MySQL、DB2等。

XA协议定义了接口标准，打通资源管理器(RM)与事务管理器(TM)的通信过程，从而更好的管理分布式事务，为了不影响后续的阅读，我再重新简单介绍下RM和TM的定义。更全面的介绍，请参考上一篇《啥？分布式啥？啥事务？》

资源管理器（Resource Manager）：用来管理系统资源，是通向事务资源的途径。数据库也是RM，每个RM管理着本地事务。
事务管理器（Transaction Manager）：事务管理器是分布式事务的核心管理者。协调各个资源管理器，完成事务处理。

前面提到的2PC、3PC就是XA协议的衍生品。

2PC

2PC全称是Two-phaseCommit，也就是我们俗称的二段式提交，2PC是一个非常经典的强一致、中心化的原子提交协议。网上很多资料在介绍2PC的时候会重新定义协调者(coordinator)和参与者(participants)的角色，这也是为啥大家会蒙的原因之一，实际上这里的协调者和参与者就是对应的事务管理器Transaction Manager和资源管理器Resource Manager。

2PC，顾名思义，整个过程一共分为两个阶段，即

投票表决阶段
提交阶段

阶段主要分为3个小步骤

TM发起事务询问事务管理器(协调者)向所有的资源管理器(参与者)发送事务处理请求，并开始等待各资源管理器的响应。
RM执行本地事务(不提交) 各个资源管理器(参与者)执行本地事务操作,但在执行完成后并不会真正的进行提交本地事务
各RM向TM进行反馈各个资源管理器(参与者)会向事务管理器(协调者)回复是否已经做好准备，如果执行本地事务成功，就反馈YES；如果执行本地事务失败，就反馈NO。

此时在阶段执行完成后，会面临两个结果

A、存在资源管理器(参与者)向事务管理器(协调者)反馈NO
B、所有资源管理器(参与者)都向事务管理器(协调者)反馈的YES

第二阶段分为2个小步骤

如果阶段结果为A，则作为异常处理。

事务管理器(协调者)会通知所有的资源管理器(参与者)进行Rollack回滚处理
资源管理器(参与者)会进行本地事务的回滚

如果阶段结果为，即资源管理器(参与者)全部反馈的A，则作为正常处理。

事务管理器(协调者)会通知所有的资源管理器(参与者)进行Commit提交处理
资源管理器(参与者)会进行本地事务的提交

无论第二阶段是异常回滚还是正常提交，都标志着当前事务的结束

2PC的缺陷

2PC虽然将XA规范方案细化成思路，也形成了流程图，大部情况下确实能提供原子性操作，但是缺存在着几个问题:

同步阻塞影响性能整个2PC的过程中，无论事务管理器(协调者)还是资源管理器(参与者)都是事务阻塞型的，这期间公共资源会一直持有并锁定，其他操作想持有资源，必须等待必须等待原事务的第二阶段结束，导致性能下降，因此2PC不适合高并发场景

解决方案:引入超时机制

事务管理器(协调者)单点问题事务管理器(协调者)在二阶段还没有发送指令前宕机，这时所有资源管理器(参与者)都会陷入阻塞情况；

解决方案:引入事务管理器(协调者)的HA选举的机制；同时事务管理器(协调者)会在操作先留下checkpoint，当检测到事务管理器(协调者)宕机一段时间后，事务管理器(协调者)会进行重新选举，之后读取操作checkpoint，并向所有资源管理器(参与者)进行问询，恢复原事务流程进度。

数据不一致事务管理器(协调者)在二阶段发送指令后宕机，部分资源管理器(参与者)执行提交或者回滚成功，部分因为自身原因或者网络问题没有收到指令从而执行失败，会出现数据不一致的情况

解决方案:资源管理器(参与者)引入重试机制；资源管理器(参与者)之间的加入互相通信机制；当资源管理器(参与者)在二阶段提交本地事务失败后，为了保证事务的原子性，需要再通知事务管理器(协调者)，然后再次给所有资源管理器(参与者)广播中断事务

事务执行进度丢失当事务管理器(协调者)在二阶段发送指令后宕机，而接受到信息的资源管理器(参与者)在执行本地事务后也宕机了，当后续事务管理器(协调者)恢复后和资源管理器(参与者)，无法得知是否已经执行事务。

3PC

3PC全称是Three-phaseCommit，也就是我们俗称的三段式提交， 3PC的提出主要是在2PC的基础上进行改良，为了解决两段式提交协议的同步阻塞问题，2PC存在的问题是当事务管理器(协调者)崩溃或者宕机的时候，资源管理器(参与者)不能做出后的选择。因此资源管理器(参与者)会在协作者事务管理器(协调者)保持阻塞。

3PC整体流程如下图所示：

CanCommit阶段

3PC的CanCommit阶段其实和2PC的准备阶段很像。

事务管理器(协调者)向资源管理器(参与者)发送CanCommit请求
资源管理器(参与者)如果认为自身具备事务提交的可能就返回Yes响应，否则返回No响应，不进行实际的动作，并不会锁定资源。

PreCommit阶段

事务管理器(协调者)根据资源管理器(参与者)在CanCommit阶段的反馈情况来确定时候需要继续下一步，执行PreCommit操作。

阶段完成后会面临两种情况:

Result-A: 所有的资源管理器(参与者)反馈的都是Yes

事务管理器(协调者)向所有的资源管理器(参与者)发送PreCommit请求
资源管理器(参与者)会执行事务操作，但不进行事务提交，同时将undo和redo信息记录到事务日志中，对资源进行加锁，
资源管理器(参与者)本地事务执行完成后向事务管理器(协调者)进行返回ACK

Result-B: 资源管理器(参与者)反馈中的存在No，或者超时时间内没有收到响应

事务管理器(协调者)向所有的资源管理器(参与者)发送事务中断的abort请求
资源管理器(参与者)收到abort请求后开始，执行事务的中断。若在超时时间内没有收到来自事务管理器(协调者)，同样进行执行中断

DoCommit阶段

该阶段进行真正的事务提交，即对所有资源进行释放，也涉及到两种情况

阶段完成后会面临两种情况:

Result-A: 所有的资源管理器(参与者)都有反馈ACK

事务管理器(协调者)在PreCommit阶段接收到资源管理器(参与者)发送的ACK响应，向所有资源管理器(参与者)发送doCommit请求
资源管理器(参与者)接收到doCommit请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资源。
资源管理器(参与者)在事务提交完之后，向事务管理器(协调者)发送Ack响应。
事务管理器(协调者)协接收到所有资源管理器(参与者)的ack响应之后，完成事务。

Result-B: 资源管理器(参与者)在超时时间内没有反馈ACK

事务管理器(协调者)向所有资源管理器(参与者)发送abort请求
资源管理器(参与者)接收到abort请求之后，利用其在阶段二记录的undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。
资源管理器(参与者)完成事务回滚之后，向事务管理器(协调者)发送ACK消息
事务管理器(协调者)接收到资源管理器(参与者)反馈的ACK消息之后，执行事务的中断。

在2PC的基础上，3PC主要优化了上面提到1、2、4问题：

在事务管理器(协调者)和资源管理器(参与者)之间都引入了超时机制。这里注意在资源管理器(参与者)向事务管理器(协调者)返回信息时，如若超时均会被认为失败，执行中断或回滚事务的流程；而在DoCommit阶段中，资源管理器(参与者)即使在超时时间内没有收到事务管理器(协调者)的信息，也会进行本地的事务提交处理；这样就解决了同步阻塞时间长的问题。但如果事务管理器(协调者)执行的是Abort请求，但资源管理器(参与者)在网络阻塞或其他原因没有收到信息，也会执行Commit操作，这样又引入了新的数据不一致问题。
3PC对2PC的个阶段进行了拆分，得到CanCommit阶段、PreCommit阶段、DoCommit阶段，3PC的CanCommit阶段并不会持有资源，如果事务管理器(协调者)宕机也降低范围会降低；
对于事务管理器(协调者)和资源管理器(参与者)都宕机，引发事务执行进度丢失的问题，3PC中当事务管理器(协调者)恢复(选举机制暂时不过多解释)时，会询问其他的资源管理器(参与者)事务执行进度，这里其他节点要么是Commit阶段，要么是PreCommit阶段或者是Rollback阶段。

2PC && 3PC总结

2PC和3PC一般应用于数据库当中，但2PC和3PC也不是银弹，并不适合高并发的场景。

并且无论是哪一个都不能彻底解决分布式系统一致性的问题，有数据一致性的隐患存在。

Google Chubby的作者Mike Burrows说过， there is only one consensus protocol, and that’s Paxos” – all other approaches are just broken versions of Paxos. 意即：世上只有一种一致性算法，那就是Paxos，看来真的需要后续我们研究一下Paxos了。

ITPub博客

架构师必知必会之分段式提交｜推荐收藏