一致性协议
发布日期:2021-11-18 17:47:08 浏览次数:13 分类:技术文章

本文共 4335 字,大约阅读时间需要 14 分钟。

系列文章目录

为了解决分布式一致性问题,在长期的探索研究过程中,涌现出了一大批经典的一致性 协议和算法,其中最著名的就是二阶段提交协议、三阶段提交协议和 Paxos算法了。

文章目录


一、2PC

顾名思义,二阶段提交协议是将事务的提交过程分成了两个阶段来进行处理,其执行流程如下。

阶段一:提交事务请求
1.事务询问。
协调者向所有的参与者发送事务内容,询问是否可以执行事务提交操作,并开始等待各参与者的响应
2.执行事务。
各参与者节点执行事务操作,并将Undo和Redo信息记入事务日志中。
3.各参与者向协调者反馈事务询问的响应
如果参与者成功执行了事务操作,那么就反馈给协调者Yes响应,表示事务可以执行;如果参与者没有成功执行事务,那么就反馈给协调者No响应,表示事务不可以执行。

由于上面讲述的内容在形式上近似是协调者组织各参与者对一次事务操作的投票表态过程,因此二阶段提交协议的阶段一也被称为“投票阶段”,即各参与者投票表明是否要继续执行接下去的事务提交操作.

阶段二:执行事务提交

在阶段二中,协调者会根据各参与者的反馈情况来决定最终是否可以进行事务提交操作,
正常情况下,包含以下两种可能。
执行事务提交
假如协调者从所有的参与者获得的反馈都是Yes响应,那么就会执行事务提交。
1.发送提交请求
协调者向所有参与者节点发出 Commit请求。
2.事务提交。
参与者接收到 Commit请求后,会正式执行事务提交操作,并在完成提交之后释放在整个事务执行期间占用的事务资源。
3.反馈事务提交结果。
参与者在完成事务提交之后,向协调者发送Ack消息。
4.完成事务。
协调者接收到所有参与者反馈的Ack消息后,完成事务。
中断事务
假如任何一个参与者向协调者反馈了No响应,或者在等待超时之后,协调者尚无法接收到所有参与者的反馈响应,那么就会中断事务。
1.发送回滚请求。
协调者向所有参与者节点发出 Rollback请求。
2.事务回滚。
参与者接收到 Rollback请求后,会利用其在阶段一中记录的Undo信息来执行事务回滚操作,并在完成回滚之后释放在整个事务执行期间占用的资源
3.反馈事务回滚结果。
参与者在完成事务回滚之后,向协调者发送Ack消息。
4.中断事务
协调者接收到所有参与者反馈的Ack消息后,完成事务中断。
以上就是二阶段提交过程中,前后两个阶段分别进行的处理逻辑。简单地讲,二阶段提交将一个事务的处理过程分为了投票和执行两个阶段,其核心是对每个事务都采用先尝试后提交的处理方式,因此也可以将二阶段提交看作一个强一致性的算法.

优缺点

二阶段提交协议的优点:原理简单,实现方便。
阶段提交协议的缺点:同步阻塞、单点问题、脑裂、太过保守
同步阻塞
二阶段提交协议存在的最明显也是最大的一个问题就是同步阻塞,这会极大地限制分布式系统的性能。在二阶段提交的执行过程中,所有参与该事务操作的逻辑都处于阻塞状态,也就是说,各个参与者在等待其他参与者响应的过程中,将无法进行其他任何操作。
单点问题
在上面的讲解过程中,相信读者可以看出,协调者的角色在整个二阶段提交协议起到了非常重要的作用。一旦协调者出现问题,那么整个二阶段提交流程将无法运转,更为严重的是,如果协调者是在阶段二中出现问题的话,那么其他参与者将会直处于锁定事务资源的状态中,而无法继续完成事务操作。
数据不一致
在二阶段提交协议的阶段二,即执行事务提交的时候,当协调者向所有的参与者发送 Commit请求之后,发生了局部网络异常或者是协调者在尚未发送完 Commit请求之前自身发生了崩溃,导致最终只有部分参与者收到了 Commit请求。于是,这部分收到了 Commit请求的参与者就会进行事务的提交,而其他没有收到 Commit请求的参与者则无法进行事务提交,于是整个分布式系统便出现了数据不一致性现象。
太过保守
如果在协调者指示参与者进行事务提交询问的过程中,参与者出现故障而导致协调者始终无法获取到所有参与者的响应信息的话,这时协调者只能依靠其自身的超时机制来判断是否需要中断事务,这样的策略显得比较保守。换句话说,二阶段提交协议没有设计较为完善的容错机制,任意一个节点的失败都会导致整个事务的失败。

二、3PC

3PC,是 Three-Phase Commit的缩写,即三阶段提交,是2PC的改进版,其将二阶段提交协议的“提交事务请求”过程一分为二,形成了由 Can Commit、 Pre commit和 do commit三个阶段组成的事务处理协议.

阶段一: Can Commit
1.事务询问。
协调者向所有的参与者发送一个包含事务内容的 can Commit请求,询问是否可以执行事务提交操作,并开始等待各参与者的响应。
2.各参与者向协调者反馈事务询问的响应。
参与者在接收到来自协调者的 can Commit请求后,正常情况下,如果其自身认为可以顺利执行事务,那么会反馈Yes响应,并进入预备状态,否则反馈No响应。
阶段二: Pre Commit
在阶段二中,协调者会根据各参与者的反馈情况来决定是否可以进行事务的 PreCommit操作,正常情况下,包含两种可能。
执行事务预提交
假如协调者从所有的参与者获得的反馈都是Yes响应,那么就会执行事务预提交。
1.发送预提交请求。
协调者向所有参与者节点发出 pre Commit的请求,并进入 Prepared阶段。
2.事务预提交。
参与者接收到 pre Commit请求后,会执行事务操作,并将Undo和Redo信息记录到事务日志中。
3.各参与者向协调者反馈事务执行的响应
如果参与者成功执行了事务操作,那么就会反馈给协调者Ack响应,同时等待最终的指令:提交( commit)或中止( abort)。
中断事务
假如任何一个参与者向协调者反馈了No响应,或者在等待超时之后,协调者尚无法接收到所有参与者的反馈响应,那么就会中断事务。
1.发送中断请求。
协调者向所有参与者节点发出 abort请求
2.中断事务
无论是收到来自协调者的 abort请求,或者是在等待协调者请求过程中出现超时,参与者都会中断事务
阶段三: docommit
该阶段将进行真正的事务提交,会存在以下两种可能的情况。
执行提交
1.发送提交请求
进入这一阶段,假设协调者处于正常工作状态,并且它接收到了来自所有参与者的Ack响应,那么它将从“预提交”状态转换到“提交”状态,并向所有的参与者发送 doCommit请求
2.事务提交
参与者接收到 doCommit请求后,会正式执行事务提交操作,并在完成提交之后释放在整个事务执行期间占用的事务资源。
3.反馈事务提交结果。
参与者在完成事务提交之后,向协调者发送Ack消息
4.完成事务
协调者接收到所有参与者反馈的Ack消息后,完成事务。
中断事务
进入这一阶段,假设协调者处于正常工作状态,并且有任意一个参与者向协调者反馈了No响应,或者在等待超时之后,协调者尚无法接收到所有参与者的反馈响应,那么就会中断事务。
1.发送中断请求
协调者向所有的参与者节点发送abot请求。
2.事务回滚。
参与者接收到 abort请求后,会利用其在阶段二中记录的Undo信息来执行事务回滚操作,并在完成回滚之后释放在整个事务执行期间占用的资源。
3…反馈事务回滚结果。
参与者在完成事务回滚之后,向协调者发送Ack消息
4.中断事务
协调者接收到所有参与者反馈的Ack消息后,中断事务。

需要注意的是,一旦进入阶段三,可能会存在以下两种故障。

  • 协调者出现问题。
  • 协调者和参与者之间的网络出现故障。
    无论出现哪种情况,最终都会导致参与者无法及时接收到来自协调者的 doCommit或是
    aboπt请求,针对这样的异常情况,参与者都会在等待超时之后,继续进行事务提交。
    优缺点
    *三阶段提交协议的优点:*相较于二阶段提交协议,三阶段提交协议最大的优点就是降低了参与者的阻塞范围,并且能够在出现单点故障后继续达成一致。
    *三阶段提交协议的缺点:*三阶段提交协议在去除阻塞的同时也引入了新的问题,那就是在参与者接收到 pre Commit消息后,如果网络出现分区,此时协调者所在的节点和参与者无法进行正常的网络通信,在这种情况下,该参与者依然会进行事务的提交,这必然出现数据的不一致性。

与两阶段提交不同的是,三阶段提交有两个改动点。

1、引入超时机制。同时在协调者和参与者中都引入超时机制。2、在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。

2PC与3PC的区别

相对于2PC,3PC主要解决的单点故障问题,并减少阻塞,因为一旦参与者无法及时收到来自协调者的信息之后,他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题,因为,由于网络原因,协调者发送的abort响应没有及时被参与者接收到,那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。

2.总结

两阶段提交协议:

第一阶段,准备阶段:协调者向参与者发起指令,参与者评估自己的状态,如果参与者评估指令可以完成,则会写redo或者undo日志,然后锁定资源,执行操作,但并不提交;

第二阶段:如果每个参与者明确返回 都准备成功,则协调者向参与者发生提交指令,参与者释放锁定的资源,如果任何一个参与者明确返回准备失败,则协调者会发生终止指令,参与者取消已经变更的事务,释放锁定的资源。

两阶段提交方案应用很广泛,几乎所有的商业OLTP数据库都支持XA协议,但是两阶段提交方案锁定资源时间长,对于性能影响很大,基本不适合于解决微服务事务问题。

两阶段提交协议弊端(缺点):如果协调者宕机,参与者没有协调者指挥,则会一直阻塞。

三阶段提交协议:

增加了一个询问阶段(在两阶段提交协议之前增加了一询问阶段),询问阶段可以确保尽可能早的发现无法执行的操作而需要终止的行为,但是它并不能发现所有的这种行为,只会减少这种情况的发生;在准备阶段以后,协调者和参与者执行的任务中都增加了超时,一旦超时,协调者和参与者都继续提交事务,默认为成功,这也是根据概率统计上超时后默认成功的正确性最大。

超时,终止提交,进行回滚。

三阶段提交协议与两阶段提交协议相比,具有如上的优点,但是一旦发生超时,系统仍然会发生不一致,只不过这种情况很少见罢了,好处就是至少不会阻塞和永远锁定资源。

转载地址:https://blog.csdn.net/weixin_37850264/article/details/111658278 如侵犯您的版权,请留言回复原文章的地址,我们会给您删除此文章,给您带来不便请您谅解!

上一篇:Git
下一篇:分布式理论

发表评论

最新留言

很好
[***.229.124.182]2024年04月04日 23时25分37秒