-
二阶段提交协议,三阶段提交协议
2020-08-14 22:49:32其实三者都是为了解决分布式一致性问题而存在的协议和算法。首先先来了解几个概念。 协调者(coordinator):...一:二阶段提交协议 1.投票阶段 协调者向所有的参与者发送事务的内容,询问是否可以执行事务,提交操作其实三者都是为了解决分布式一致性问题而存在的协议和算法。首先先来了解几个概念。
协调者(coordinator):在分布式系统中,当事务操作需要跨越多个分布式节点的时候,为了保持分布式处理的ACID特性,需要引入它来统一调度所有节点的执行逻辑。
参与者(participant):协调者调度的这些节点就是参与者了
在实际的过程中,协调者负责调度参与者的行为,并最终决定这些参与者是否要把事务真正进行提交。
一:二阶段提交协议
1.投票阶段- 协调者向所有的参与者发送事务的内容,询问是否可以执行事务,提交操作然后等待参与者的回复。
- 参与者节点收到讯息,执行事务操作,并将undo和redo信息记录到日志信息中。
- 然后参与者将是否执行事务的结果反馈给协调者,如果成功执行就返回Yes否则返回No。
2.执行阶段
2.1如果都是返回Yes,则执行事务提交- 协调者向所有的参与者节点发出commit请求。
- 参与者收到commit的请求后,会正式的执行事务并提交。完成提交之后释放所有的事务资源。
- 参与者完成提交之后会向协调者发送ack的消息。
- 协调者收到ack之后表示此次事务完成。
2.2如果有返回是No,则执行中断事务
- 协调者向所有的参与者节点发送Rollback的请求。
- 参与者收到请求后会利用其在第一阶段记录的undo日志信息来执行事务回滚操作。释放资源。
- 完成回滚之后,参与者会向协调者发送ack的消息。
- 协调者收到所有的参与者的ack之后,完成事务中断。
一阶段
二阶段
那么二阶段提交会有哪些问题呢?
首先,由于投票阶段需要等待所有的都给协调者反馈才会进行下一个阶段,那么显而易见的出现了同步阻塞的问题。每个参与者都会等待,直到到了下一个阶段。
其次,我们考虑这么一种情况,如果协调者挂了,是不是都会一直等待?这也就是我们所说的单点问题。
再然后,如果在二阶段在协调者发送commit的时候出现了局部的网络异常,导致有一部分参与者收到了消息,一部分参与者并没有收到消息,这就导致了数据的不一致。
最后,这种方式其实他过于的保守了。二:三阶段提交
1.canCommit阶段
协调者发送cancommit的请求。参与者返回是否可以的响应。
2.preCommit阶段
2.1若canCommit阶段都是返回的Yes则直接preCommit,各个参与者记录预提交的redo和undo日志。
2.2若有返回为No的参与者,协调者向所有的参与者发送abort命令。或者等待超时后参与者直接中断事务。
3.doCommit阶段
3.1若都成功,则直接返回ack,参与者提交事务,完成整个流程。
3.2若协调者发现其中的参与者有发送No的,则向所有的参与者发送abort,参与者接到消息或者等待超时后中断任务,进行事务回滚。
仔细的同学可能发现了,如果第三阶段我协调者挂了,或者说出现协调者和参与者无法通信,其他的参与者还是会执行doCommit,那不是必定出现数据不一致嘛?是的,这就是三阶段提交的缺点,但是相较于二阶段提交,它很大程度上减小了参与者的阻塞范围,并且就算出现单点问题最后参与者还是能达成一致,这是我们希望看到的。 -
分布式一致性——二阶段提交协议,三阶段提交协议
2018-08-06 11:30:53分布式系统,这早已不是什么新鲜的东西了,在分布式系统的架构设计过程中,往往会存在分布式一致性的问题,经过前人的辛苦探究,提出了二阶段提交协议,三阶段提交协议,Paxos算法等等,用来解决分布式一致性的问题...分布式系统,这早已不是什么新鲜的东西了,在分布式系统的架构设计过程中,往往会存在分布式一致性的问题,经过前人的辛苦探究,提出了二阶段提交协议,三阶段提交协议,Paxos算法等等,用来解决分布式一致性的问题。今天我就讲一下,二阶段提交协议和三阶段提交协议的过程,以及它们的优缺点。
2PC,就是二阶段提交协议。顾名思义,就是将事务的提交过程分成两个阶段来处理。那我们来看看这两个阶段分别做了什么。
阶段一:
1.提交事务请求:
协调者向所有的参与者发送事务内容,询问是否可以执行事务提交操作,并开始等待各参与者的响应。
2.执行事务:
各个参与者节点执行事务操作。并将Undo和Redo信息记入事务日志中。
3.各参与者向协调者反馈事务询问的响应:
如果参与者成功执行了事务操作,那么就反馈给协调者Yes响应,表示事务可以执行;如果参与者没有成功执行事务,那么就反馈给协调者No响应,表示事务不可以执行。
阶段二:
1.执行事务提交:
假如协调者从所有参与者获得的响应都为Yes,那么就执行事务提交,协调者向所有参与者节点发出Commit请求。
2.参与者提交事务:
参与者接收到Commit请求后,会正式执行事务提交操作,并在完成提交之后释放在整个事务执行期间占用的事务资源,并向协调者发送Ack消息。
3.完成事务:
协调者接收到所有参与者反馈的Ack消息后,完成事务。
这里我画了一张时序图,来说明其中的过程,如图所示:
中断事务
假如任何一个参与者反馈给协调者No响应,或者在等待超时之后,协调者没有收到所有参与者的响应,那么就会中断事务。
1.发送回滚请求
协调者向所有参与者发送Rollback请求。
2.事务回滚
参与者接收到Rollback请求后,会利用其在阶段一中记录的Undo信息来执行事务回滚操作,完成回滚之后释放在整个事务执行期间占用的资源,并向协调者发送Ack消息,协调者接收到所有的参与者反馈的Ack消息后,完成事务中断。
中断的过程就是这样,下面一张时序图,描述中断事务的过程。
二阶段提交协议的整个过程就是这样,这种先请求后提交的方式,能够保证所有节点在进行事务处理过程中保持原子性,进行统一的提交或回滚,可以看作是一个强一致性的算法。那我们就来思考一下,它有哪些优点,以及会带来什么问题。
优点:简单好用,实现方便。
缺点:同步阻塞,单点问题,还是会有数据不一致的情况出现。
同步阻塞:在二阶段提交事务的过程中,所有参与该事务操作的逻辑都处于阻塞状态,各个参与者在等待其他参与者的响应过程中,无法做其他的操作。
单点问题:在二阶段提交协议中,协调者这个角色是很重要的,一旦协调者挂掉,将导致整个提交流程无法运转,若是在第二阶段协调者挂掉,参与者将一直处于锁定事务资源的状态,无法继续完成事务操作。
数据不一致:若是在第二阶段,协调者在向所有参与者发送commit请求时,由于局部网络的故障,只有部分参与者受到commit请求,提交事务,这样没有受到commit请求的就没有提交事务,出现了数据不一致的情况。
3PC,就是三阶段提交协议,顾名思义,就是把事务的提交过程分为三个阶段,实际上它就是在原来二阶段提交上做了一部分改进,那我们就来看看它的过程,以及它到底改进了什么。
阶段一:CanCommit
事务询问:
协调者向所有的参与者发送一个包含事务内容的canCommit请求,询问是否可以执行事务提交操作,并开始等待各个参与者的响应。参与者接收请求后,正常情况下,如果认为其自身可以顺利执行事务,那么会反馈Yes响应,并进入预备状态,否则反馈No响应。
阶段二:PreCommit
在阶段二,协调者根据各参与者的反馈情况来决定是否可以进行事务的PreCommit操作,正常情况下,包含两种可能。一种是参与者全部反馈Yes响应,则进入预提交阶段,另一种时有参与者反馈No响应或者等待超时后,没有收到全部的反馈响应,则会中断事务,我们来分别看一下这两种情况。
第一种:预提交:
协调者向所有的参与者发送PreCommit请求,并进入Prepared阶段。
参与者接收到preCommit的请求,执行事务操作,并将Undo和Redo信息记录到事务日志中,然后向协调者反馈Ack响应,等待最终的指令提交或中止。
第二种:中断事务:
协调者向所有的参与者发出abort请求,参与者无论是收到协调者的abort请求,还是等待请求过程中超时,参与者都会中断事务。
阶段三:doCommit
这一阶段,即将开始真正的事务提交,同样也会存在两种可能的情况。
第一种:执行提交:
1.发送提交请求:
进入这一阶段:假如协调者处于正常的工作状态,并且它接收到了来自所有参与者的Ack响应,那么它将从预提交状态转换到提交状态,并向所有的参与者发送doCommit请求。
2.事务提交:
参与者接收到doCommit请求后,会正式执行事务提交操作,并在完成提交之后释放在整个事务执行期间占用的事务资源,并向协调者发送Ack消息。协调者接收到所有参与者反馈的Ack消息后,完成事务。
第二种:中断事务:
进入这一阶段,假设协调者处于正常状态(这个很关键),并且有任意一个参与者向协调者反馈了No响应,或者等待超时之后,协调者无法接收到所有参与者的反馈响应。那么就会中断事务。
协调者向所有参与者节点发送abort请求。
各个参与者接收到abort请求后,会利用其在阶段二中记录的Undo信息来执行事务回滚操作,并在完成回滚之后释放在整个事务执行期间占用的资源,并向参与者发送Ack消息。协调者接收到所有参与者反馈的Ack消息后,中断事务。
一旦进入到阶段三,可能会存在两种故障:1.协调者出现问题;2.协调者和参与者之间的网络出现故障。
无论出现哪种情况,最终都会导致参与者无法及时接收到来自协调者doCommit或是abort请求,针对这样的异常情况,参与者都会在等待超时之后,继续提交事务操作。
到这里三阶段提交协议就讲完了,相比较于二阶段提交协议,它降低了参与者的阻塞范围,并在出现单点故障后,继续达成一致。同样三阶段提交协议也会带来数据不一致的问题,在第二阶段,协调者向所有参与者发送preCommit请求时,如果这时网络出现问题,协调者无法和参与者进行正常通信,参与者此时仍然会提交事务,而协调者等待超时后,进行事务中断,这样就会带来数据不一致的情况。
总结:二阶段提交协议和三阶段提交协议都是解决分布式数据一致性问题的优秀算法,尽管从根本上并不能保证绝对的一致性,但也并不影响它们在实际工程上的使用。有句话是这么说的,在存在消息丢失的不可靠信道上试图通过消息传递的方式达到一致性是不可能的,有兴趣的朋友可以研究一下paxos算法以及它的证明过程。
-
三阶段提交
2019-03-26 16:34:21由于二阶段提交存在很多的问题,我们对其做了一定的改进,也就是三阶段提交,过程图如下: 主要有2个优化点: 1 引入超时机制。同时在协调者和参与者中都引入超时机制。 2 在第一阶段和第二阶段中插入一个准备...由于二阶段提交存在很多的问题,我们对其做了一定的改进,也就是三阶段提交,过程图如下:
主要有2个优化点:
1 引入超时机制。同时在协调者和参与者中都引入超时机制。
2 在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。CanCommit阶段
协调者向参与者发送commit请求,参与者如果可以提交就返回Yes响应,否则返回No响应。
PreCommit阶段
协调者根据参与者的反应情况来决定是否可以进行事务的PreCommit操作。根据响应情况,有以下两种可能。
假如协调者从所有的参与者获得的反馈都是Yes响应,那么就会执行事务的预执行。
1.发送预提交请求 协调者向参与者发送PreCommit请求,并进入Prepared阶段。
2.事务预提交 参与者接收到PreCommit请求后,会执行事务操作,并将undo和redo信息记录到事务日志中。
3.响应反馈 如果参与者成功的执行了事务操作,则返回ACK响应,同时开始等待最终指令。
假如有任何一个参与者向协调者发送了No响应,或者等待超时之后,协调者都没有接到参与者的响应,那么就执行事务的中断。
1.发送中断请求 协调者向所有参与者发送abort请求。
2.中断事务 参与者收到来自协调者的abort请求之后(或超时之后,仍未收到协调者的请求),执行事务的中断。
doCommit阶段
该阶段进行真正的事务提交,也可以分为以下两种情况。
执行提交
1.发送提交请求 协调接收到参与者发送的ACK响应,那么他将从预提交状态进入到提交状态。并向所有参与者发送doCommit请求。
2.事务提交 参与者接收到doCommit请求之后,执行正式的事务提交。并在完成事务提交之后释放所有事务资源。
3.响应反馈 事务提交完之后,向协调者发送Ack响应。
4.完成事务 协调者接收到所有参与者的ack响应之后,完成事务。
中断事务 协调者没有接收到参与者发送的ACK响应(可能是接受者发送的不是ACK响应,也可能响应超时),那么就会执行中断事务。
1.发送中断请求 协调者向所有参与者发送abort请求
2.事务回滚 参与者接收到abort请求之后,利用其在阶段二记录的undo信息来执行事务的回滚操作,并在完成回滚之后释放所有的事务资源。
3.反馈结果 参与者完成事务回滚之后,向协调者发送ACK消息
4.中断事务 协调者接收到参与者反馈的ACK消息之后,执行事务的中断。
在doCommit阶段,如果参与者无法及时接收到来自协调者的doCommit或者rebort请求时,会在等待超时之后,会继续进行事务的提交。(其实这个应该是基于概率来决定的,当进入第三阶段时,说明参与者在第二阶段已经收到了PreCommit请求,那么协调者产生PreCommit请求的前提条件是他在第二阶段开始之前,收到所有参与者的CanCommit响应都是Yes。(一旦参与者收到了PreCommit,意味他知道大家其实都同意修改了)所以,一句话概括就是,当进入第三阶段时,由于网络超时等原因,虽然参与者没有收到commit或者abort响应,但是他有理由相信:成功提交的几率很大。 )
2PC与3PC的区别
相对于2PC,3PC主要解决的单点故障问题,并减少阻塞,因为一旦参与者无法及时收到来自协调者的信息之后,他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题,因为,由于网络原因,协调者发送的abort响应没有及时被参与者接收到,那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。
-
Zookeeper研究系列之二阶段提交到Paoxs协议到ZAB协议的演进
2020-06-05 11:33:23两阶段提交 存在的问题: 同步阻塞: 协调者发起命令后只能无限等待参与者响应 单点问题:协调者宕机则整个集群不可用 脑裂问题:网络分化后,导致部门节点提交成功,部分节点失败,造成数据不一致 Paoxs...要解决的问题:分布式数据一致性(当客户端发起写入数据请求时,各个节点的数据保持一致)
两阶段提交
存在的问题:
- 同步阻塞: 协调者发起命令后只能无限等待参与者响应
- 单点问题:协调者宕机则整个集群不可用
- 脑裂问题:网络分化后,导致部门节点提交成功,部分节点失败,造成数据不一致
Paoxs协议
问题背景:假设我们有下图的系统,想要在server1,server2,server3选一个master。
prepare阶段
1. 每个server向proposer发送消息,表示自己要当leader,假设proposer收到消息的时间不一样,顺序是: proposer2 -> proposer1 -> proposer3,消息编号依次为1、2、3。
紧接着,proposer将消息发给acceptor中超过半数的子成员(这里选择两个),如图所示,proposer2向acceptor2和acceptor3发送编号为1的消息,proposer1向acceptor1和accepto2发送编号为2的消息,proposer3向acceptor2和acceptor3发送编号为3的消息。
2. 假设这时proposer1发送的消息先到达acceptor1和acceptor2,它们都没有接收过请求,所以接收该请求并返回【pok,null,null】给proposer1,同时acceptor1和acceptor2承诺不再接受编号小于2的请求;
紧接着,proposer2的消息到达acceptor2和acceptor3,acceptor3没有接受过请求,所以返回proposer2 【pok,null,null】,acceptor3并承诺不再接受编号小于1的消息。而acceptor2已经接受proposer1的请求并承诺不再接收编号小于2的请求,所以acceptor2拒绝proposer2的请求;
最后,proposer3的消息到达acceptor2和acceptor3,它们都接受过提议,但编号3的消息大于acceptor2已接受的2和acceptor3已接受的1,所以他们都接受该提议,并返回proposer3 【pok,null,null】;
此时,proposer2没有收到过半的回复,所以重新取得编号4,并发送给acceptor2和acceptor3,此时编号4大于它们已接受的提案编号3,所以接受该提案,并返回proposer2 【pok,null,null】。accept阶段
1
Proposer3收到半数以上(两个)的回复,并且返回的value为null,所以,proposer3提交了【3,server3】的提案。
Proposer1也收到过半回复,返回的value为null,所以proposer1提交了【2,server1】的提案。
Proposer2也收到过半回复,返回的value为null,所以proposer2提交了【4,server2】的提案。(这里要注意,并不是所有的proposer都达到过半了才进行第二阶段,这里只是一种特殊情况)
2
Acceptor1和acceptor2接收到proposer1的提案【2,server1】,acceptor1通过该请求,acceptor2承诺不再接受编号小于4的提案,所以拒绝;
Acceptor2和acceptor3接收到proposer2的提案【4,server2】,都通过该提案;
Acceptor2和acceptor3接收到proposer3的提案【3,server3】,它们都承诺不再接受编号小于4的提案,所以都拒绝。所以proposer1和proposer3会再次进入第一阶段,但这时候 Acceptor2和acceptor3已经通过了提案(AcceptN = 4,AcceptV=server2),并达成了多数,所以proposer会递增提案编号,并最终改变其值为server2。最后所有的proposer都肯定会达成一致,这就迅速的达成了一致。
原文链接:https://blog.csdn.net/u013679744/article/details/79222103存在问题:
- 活锁问题:假如提案者1因为不能获得过半响应而将自己的编号变为maxN+1=3,而此时提案者2的提案号是2<3,因此也会将自己的编号maxN+1=4,and so on, 造成活锁问题
ZAB协议
广播模式
无历史数据时,选举leader
有历史数据,则按照zxid, myid 顺序选择最大的节点
-
深入理解分布式技术 - 彻底搞懂两阶段提交协议和三阶段提交协议
2021-01-25 22:44:59文章目录问题协调者统一调度二阶段提交协议 问题 在分布式系统中,各个节点之间在物理上相互独立,通过网络进行沟通和协调。 在关系型数据库中,由于存在事务机制,可以保证每个独立节点上的数据操作满足 ACID。 ... -
八 三阶段提交事务
2020-07-28 18:06:47因为2阶段提交存在单点故障,同步阻塞,网络脑裂等问题,所以在两阶段的基础上做了改良,并提出了3 阶段提交的概念 2阶段提交和3阶段提交的区别 3阶段在2阶段的基础上做了2个改进点∶ 1.增加了起时机制,同时为协授者和... -
理解分布式一致性协议:二、三阶段提交
2017-08-07 17:15:19由于毕设和Lab项目需要,最近在看《从paxos到zookeeper分布式一致性原理与实践》, 2和3PC算法流程,网上...2PC 二阶段提交2PC其实就是先尝试执行事务再提交的策略,如果有一个参与者出现问题,则回滚尝试期间做的事务 -
关于分布式事务、两阶段提交协议、三阶提交协议
2018-06-25 10:08:45随着大型网站的各种高并发访问、海量数据处理等场景越来越多,如何实现网站的高可用、易...本文将简单介绍如何有效的解决分布式的一致性问题,其中包括什么是分布式事务,二阶段提交和三阶段提交。分布式一致性回顾在... -
两阶段提交与三阶段提交【分布式数据一致性】
2019-08-11 21:40:551、任何一个技术,都是为了解决某个问题,有它的使用场景。2、考虑下面的应用场景:一个指挥官,A,B,C... 第二个阶段: 指挥官确认四个将军是否都准备好,如果都准备好,下发命令,明天攻城。如果存在没有准备好的... -
[分布式]:关于分布式事务、两阶段提交协议、三阶提交协议
2018-05-24 17:02:40随着大型网站的各种高并发访问、海量数据处理等场景越来越多,如何实现网站的高可用、易...本文将简单介绍如何有效的解决分布式的一致性问题,其中包括什么是分布式事务,二阶段提交和三阶段提交。分布式一致性回顾在... -
关于分布式事务、两阶段提交、一阶段提交、Best Efforts 1PC模式和事务补偿机制的研究
2017-03-30 09:55:58随着大型网站的各种高并发访问、海量数据处理等场景越来越多,如何实现网站的高可用、易伸缩、可...本文将简单介绍如何有效的解决分布式的一致性问题,其中包括什么是分布式事务,二阶段提交和三阶段提交。 分布式 -
事务提交 commit 会失败么_关于分布式事务、两阶段提交协议、三阶提交协议
2020-12-05 19:57:51随着大型网站的各种高并发访问、海量数据处理等场景越来越多,如何实现网站的高可用、易...本文将简单介绍如何有效的解决分布式的一致性问题,其中包括什么是分布式事务,二阶段提交和三阶段提交。分布式一致性回顾在... -
分布式事务、两阶段提交协议、三阶提交协议
2016-12-20 23:08:21随着大型网站的各种高并发访问、海量数据处理等场景越来越多,如何实现网站的高可用、易伸缩、可扩展、安全...本文将简单介绍如何有效的解决分布式的一致性问题,其中包括什么是分布式事务,二阶段提交和三阶段提交...
-
基于Qt的LibVLC开发教程
-
Bootstrap中的工具提示
-
【Java核心技术】Java集合技术详解
-
项目经理成长之路
-
轮廓-源码
-
用研成长日记之“海淘用户调研项目”心得
-
SpringCloud Bus消息总线
-
基于Flink+Hudi构建企业亿级云上实时数据湖教程(PC、移动、小
-
Dependence of surface-enhanced Raman scattering from Calf thymus DNA on anions
-
可调波长半导体激光法布里珀罗干涉仪
-
win10计算机局域网工作组内只能看到少量其它计算机
-
一种新策略的肺结节检测算法
-
适用于共形胶囊类型应用的单层双/三频倒F天线
-
C++生成-1到1之间的随机浮点数
-
一种基于改进FCM的自动图像分割算法
-
python 使用 enumerate简化遍历
-
数模笔记_随机模型之马尔可夫链
-
突破单IP频繁反爬虫限制的小技巧
-
基于python的dango框架购物商城毕业设计毕设源代码使用教程
-
牛牛量化策略交易