架构师必知必会之分段式提交|推荐收藏
先来露怯一波:记得我工作年在做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了。
相关文章