两阶段提交协议(2PC),先询问,执行事物操作,然后提交。
阶段一:协调者向所有的参与者发送事物内容,询问是否可以提交;各参与者执行事物,记录Undo和redo日志;成功执行了事物反馈Yes响应,否则反馈no响应。
阶段二:如果所有参与者都是Yes响应,在发送commit请求,参与者收到后执行提交操作,并反馈ACK消息,协调者收到所有ACK消息后完成事物。如果任一参与者反馈可no响应,或者超时,则会中断事物,发送回滚请求。
三阶段提交协议(3PC),2PC改进版,先询问,然后执行事物操作,最后提交。
阶段一:协调者向所有的参与者发送事物内容,询问是否可以提交,各参与者反馈Yes响应或no响应
阶段二:协调者收到no响应,或超时,协调者会中断事物;参与者收到abort请求或超时,参与者会中断事物。
阶段三:协调者收到no响应,或超时,协调者会中断事物;参与者无法及时收到提交请求,参与者都会提交。
降低了阻塞范围,但也引入了数据不一致性的问题。
Paxos算法,在多个成员之间对某个值(提议)达成一致的一致性协议。这个值是client发送过来期望多节点一起保存的一致性内容,举例:一句日志,某个配置等。当一个提议被多数派接受后,这个提议对应的值被选定,一旦有一个值被选定,那么只要按照协议的规则继续交互,后续被选定的值都是同一个值,也就是这个选定值的一致性问题。Paxos并不指代一个协议,而是一类协议的统称,比较常见的paxos类协议有:basic paxos ,以及 multi-paxos。
约束:P2b. 如果一项值为v的提议被确定,那么proposer后续只发起值为v的提议
basic paxos
阶段一:proposer选择一个提案编号M,向超过半数的acceptor发送prepare请求;acceptor收到请求后,判断M大于它已经批准过的最大编号N,则将N的提案发给proposer,并承诺不会再批准编号小于M的提案。
阶段二:如果proposer收到超过半数对其发出的编号为M的提议的响应,则发送一个【M,V】提案的accept请求给acceptor,v为收到的响应中编号最大提案的值,如果响应中不包含任何提案,则其为任意值。
有助于理解basic paxos 协议的小细节:
- proposer是可以有多个,所以它叫做proposer,而不叫leader
- proposer并不强制要发送propose到全部acceptor,也可以发送70%的acceptor,只要通过的有半数以上,就认为协议是成功的
- 容易看出,第二阶段的时候client仍需要等着,只有在第二阶段大半acceptor返回accepted后,client才能得到成功的信息
- 有一些错误场景中,proposer会互相锁住对方的递交,可通过选举主proposer,并规定只有主proposer可以提出议案解决
multi-paxos
其实不断地进行“确定一个值”的过程、再为每个过程编上序号,就能得到具有全序关系(total order)的系列值,进而能应用在数据库副本存储等很多场景。我们把单次“确定一个值”的过程称为实例(instance),它由proposer/acceptor/learner组成,下图说明了A/B/C三机上的实例:
不同序号的实例之间互相不影响,A/B/C三机输入相同、过程实质等同于执行相同序列的状态机(state machine)指令 ,因而将得到一致的结果。
proposer leader在Multi Paxos中还有助于提升性能,常态下统一由leader发起提议,可节省prepare步骤(leader不用问询acceptor曾接受过的ID最大的提议、只有leader提议也不需要acceptor进行promise)直至发生leader宕机、重新选主。
当某个节点通过选举成为master后,使用一个新分配的编号N来广播一个prepare消息,该prepare消息会被当前所有未决和未来的instance共用,acceptor接受到prepare消息后,将所有未决的instance封装成一个消息包返回,然后master对所有未决的instance和未来的instance分别执行“propose-accept”阶段的处理。
应用:
Goole Chubby,高可用的分布式锁服务。Hypertable,针对分布式海量数据的高并发数据库。
以下来自转载:https://www.imooc.com/article/18715?block_id=tuijian_wz#
Paxos算法
Paxos算法是莱斯利·兰伯特(Leslie Lamport)于1990年提出的一种基于消息传递的一致性算法。 Paxos 算法是一个解决分布式系统中,多个节点之间就某个值(注意是某一个值,不是一系列值)达成一致的通信协议。能够处理在少数派离线的情况下,剩余的多数派节点仍然能够达成一致。 Lamport是通过故事的方式提出Paxos 问题:
希腊岛屿Paxon 上的执法者在议会大厅中表决通过法律(一次paxos过程),并通过服务员(proposer)传递纸条的方式交流信息,每个执法者会将通过的法律记录在自己的账目上。问题在于执法者和服务员都不可靠,他们随时会因为各种事情离开议会大厅(服务器拓机或网络断开),并随时可能有新的执法者进入议会大厅进行法律表决(新加入机器),使用何种方式能够使得这个表决过程正常进行,且通过的法律不发生矛盾(对一个值达成一致)。 注意:paxos过程中不存在拜占庭将军问题(消息不会被篡改)和两将军问题(信道可靠)。 paxos 协议中有四种角色:
client 议题产生者,产生一个待分布式系统达成一致的值v
proposer 提议者,用client产生的值v,向acceptor发出提议
acceptor 决策者,决定是否接受proposer的提议,大多数接受了提议,结果达成一致,达成一致的结果不可更改
learner 决策学习者,学习最终达成一致的结果。一旦学习成功,关闭对应的paxos过程(paxos instance),并通知acceptor(或acceptor主动向learner获取)。
这四种角色中,proposer和acceptor比较重要,协议主要的交互逻辑都在这两种角色中。
paxos 是一个两阶段的通信协议:
第一阶段 Prepare
client产生一个值v,并告知proposer,我这里产生了一个待accept的值。
proposer收到通知后,生成一个全局唯一并且递增的提案ID,带着这个ID(不需要携带v)向集群中的所有acceptor发送PrepareRequest请求。 acceptor收到PrepareRequest请求后,检查一下之前接收到的提案ID(包括第一阶段和第二阶段),新接收的提案ID用n表示,之前接收到的提案ID用N表示。如果n <= N,返回拒绝,并携带N的值。如果n > N,把n记录下来,以后不再接收提案ID比n小的提议,这时分两种情况:
之前没有accept任何值v,返回可以接收提议
之前已经accept过值,返回可以接收提议,并携带已经accept的,并且提案ID最大的值
第二阶段 Accept
如果proposer收到大多数acceptor的拒绝应答,回到第一阶段,根据接收到的最大的N,把提案ID增大,继续发送PrepareRequest。
如果proposer收到大多数acceptor可以接收提议的应答,从多个应答中选出提案ID最大的值(第一阶段如果acceptor已经accept过值,会返回提案ID最大的值),作为提案值。如果应答中没有值,选择client产生的值v作为提案值。然后携带当前的提案ID,一起向集群中所有acceptor发送AccpetRequest请求。 对这段话进行解释:第一阶段client产生的值v,不一定作为Accept阶段的提案值。为了更快的达成一致,如果之前已经accept了值,那么proposer会倾向于把提案值修改为之前接受的值。各个proposer不是针锋相对,而是合作共赢。 acceptor收到AccpetRequest后,检查请求中携带的提案ID,如果此提案ID大于或等于acceptor记录的提案ID(在第一阶段和第二阶段,acceptor记录最大的提案ID),接受提议并记录提案ID和提案值。否则拒绝,并返回记录的提案ID。 proposer收到大多数acceptor接受提案的应答,形成决议,达成一致。
如果proposer收到大多数acceptor拒绝的应答,回到第一阶段,把提案增大(增加幅度依据acceptor返回的提案ID),发送PrepareRequest。
举个例子帮助理解paxos协议,把整个paxos协议的流程想象成一次竞标。有两个老板(client),每个老板都有一个属于自己的秘书(proposer),还有3个政府官员(acceptor)。
第一阶段
两个老板(client)分别提出议题:“XXX项目我要中标”,各自的秘书(proposer)带着现金(提案ID),去找政府官员(acceptor)。
作为政府官员(acceptor),谁给的钱多答应给谁中标(只是口头答应,并没有签约)。钱少的直接拒绝。
场景1:秘书p1带着10000美金去找3个官员a1、a2、a3,这时候还没有人来找过a1、a2、a3,所以这3个官员直接就答应了p1,并告诉p1他们之前没有接受过任何提议。这样p1在一阶段获得了全票支持。过一会,秘书p2带着8000美金去找3个官员,3个官员一看只有8000美金,直接拒绝p2,告诉p2别人已经出价10000。
场景2:p1的行为和第一个场景相同。p2带着12000美金去找3个官员,3个官员一看p2给的钱比p1多,把p2的钱记下来,很高兴的告诉p2,可以接收p2的提议。这样在第一阶段p1和p2都获得了全票支持。
场景3:p1和p2同时带着10000美金去找3个官员,p1先找到了a1、a2,此时没有人找过a1和a2,a1和a2答应p1,告诉p1他们之前没有接受过任何提议。p2在p1之前找到了a3,之前没有人找过a3,a3答应p2,告诉p2他之前没有接受过任何提议。这时候p1也找到了a3,a3一看和之前收到的钱一样多,拒绝了p1。同样,在p2找到a1和a2时,应为钱数一样,也被拒绝。最终,在第一阶段,p1获得2票(a1和a2),超过半数,p1可以进入第二阶段。p2获得1票,少于半数,p2被打回第一阶段。
第二阶段
场景1:在第一阶段p1获得了全票支持,p1带着老板的议题去找官员签合同,并告诉官员之前已经给了10000美金。官员看了一下收款记录,没错是10000美金,3个官员和p1成功签约,达成一致。在第一阶段p2被拒绝,这时p2回到第一阶段,带了12000美金去找官员。官员一看12000比刚才接受的10000多,告诉p2,你的钱多,可以接受你的议题,但是之前已经接受了p1的议题,p1的议题内容为“XXXXXX”。p2看了下p1的议题,觉得自己的老板没前途,干脆跟着p1的老板干算了,于是把自己的议题修改为p1的议题(为了更快达成一致)。p2带着修改之后的议题去找官员,告诉官员之前给了12000。官员看了一下记录,没错是12000,接受了p2的议题(这时p2的议题和p1一样,虽然官员同时接受了p1和p2,但是系统仍然是一致的)。
场景2:在第一阶段p1获得了全票支持,p1带着老板的议题去找官员签合同,并告诉官员之前已经给了10000美金。官员看了一下收款记录,记录上写的是12000,于是告诉p1,已经有人出了12000,我们不能accept你的提议。在第一阶段p2也获得了全票支持,这时候p2来找官员,告诉官员之前给了12000,官员核实了一下记录,发现没错,接受了p2的议题。p1被拒绝后,回到第一阶段,带了14000美金去找官员。官员一看14000比刚才接受的12000多,告诉p1,你的钱多,可以接受你的议题,但是之前已经接受了p2的议题,p2的议题内容为“XXXXXX”。p1看了下p2的议题,觉得自己的老板没前途,干脆跟着p2的老板干算了,于是把自己的议题修改为p2的议题(为了更快达成一致)。p1带着修改之后的议题去找官员,告诉官员之前给了14000。官员看了一下记录,没错是14000,接受了p1的议题(这时p1的议题和p2一样,虽然官员同时接受了p1和p2,但是系统仍然是一致的)。
场景3-1:在第一阶段p1获得a1、a2的应答,p1带着老板的议题去找a1、a2签合同,并告诉a1、a2之前已经给了10000美金。核实之后,a1和a2接受了p1的议题。由于大多数官员接受了p1的议题,所以p1的议题被确定接受。
场景3-2:在第一阶段p1获得a1、a2的应答,p1带着老板的议题去找a1、a2签合同。但是p2在被打回第一阶段后,以很快的速度带着12000美金,赶在p1之前再次找到a1和a2以及a3。a1、a2、a3答应p2,并把记录金额修改为12000,并告诉p2,我们没有接受任何议题(p1还在签约途中)。这时p1终于找到了a1和a2,准备签约,但是a1和a2告诉p1,我们刚才收了12000,比你给的10000要多,拒绝接受你的议题,p1被打回第一阶段。在第一阶段p2获得全票,于是带着议题去找a1、a2、a3签约,a1、a2、a3核实金额之后,成功签约,达成一致。
paxos协议中的活锁问题
在上边描述的场景中,如果在官员签约之前,p1和p2一直不停的往上加金额,就算进入第二阶段,也会因为有更高的报价,导致签约失败被打回第一阶段。就像拍卖会中,多个买家一直往上飙价格,最后一件东西都没有卖出去。这种情况称为活锁,没有产生阻塞,但是一直无法达成一致。
有三种解决方案:
在被打回第一阶段再次发起PrepareRequest请求前加入随机等待时间。
设置一个超时时间,到达超时时间后,不再接收PrepareRequest请求。
在proposer中选举出一个leader,通过leader统一发出PrepareRequest和AcceptRequest。
multi paxos
一次paxos过程(paxos instance)只能对一个值达成一致。multi paxos是运行多个paxos instance来对多个值达成一致。
下边以MySQL组复制为例,说明multi paxos。
MySQL组复制中存在多个master,可以同时接受client写入和读取数据,并且可以保证多个master中数据一致,每一次写入数据都会生成一条log日志,通过paxos协议进行一致性处理,达成一致之后完成log复制。针对一系列操作,需要运行多次paxos过程(paxos instance),需要引入一个ID来标识相应的paxos instance,这里用logID表示。每一次写入操作,都生成一个logID与log日志对应,也同时与paxos instance对应,logID全局唯一且自增。
有了logID之后,每个paxos instance独立运行,可以对每条log日志达成一致。这样问题貌似已经解决了,但是还有优化的空间。
每一次paxos instance都是一个两阶段过程(prepare和accept),所有proposer地位平等,都可以提出议题。在有多个proposer同时提出议题时,有很大概率冲突,每次冲突都会重新执行prepare阶段,网络和性能开销较大。同时paxos协议本身存在活锁问题,有可能导致一个议题始终无法达成一致。为了解决这两个问题,multi paxos中引入了leader的概念,从多个proposer中选举出一个leader作为提议代表,每个提议都通过leader发出。这样的话,解决了活锁问题(活锁问题的第三个解决方案)。因为提议都是通过leader发出,只要leader保证提案ID自增,就可以跳过prepare阶段,直接进行accept阶段(两阶段变为一阶段)。
那么问题来了,如何选举leader?运行一次paxos instance,提议的v就是“选举自己为leader”。但是还有问题,一次paxos instance只能对一个值达成一致。举个例子:A、B、C三台机器,运行paxos选举leader。第一次选举产生结果,A是leader。之后A拓机,再次运行paxos,选举的结果还是A是leader。运行多个paxos instance(multi paxos)可以选举出不同的leader,但是multi paxos需要选举出一个leader来优化网络损耗和活锁的问题,这里产生一个问题递归依赖。
换个思路,给每一个达成一致的值v一个过期时间,达到过期时间清空v,这样用一个paxos instance就可以选出不同的leader。每台机器上都启动一个倒计时T,leader在存活状态下,不断重置T,T在倒计时为零时清空上次选举的结果,并发起选举。
上边简单说明了一种选举leader的算法,通过选举leader,可以提高paxos的性能(两阶段变为一阶段),并解决活锁问题。paxos的正确性不依赖于选举结果,在选举失败或者同时选出多个leader的情况下,退化为普通paxos。
总结
paxos协议可以归纳为几个原则:
不接受旧值(通过递增ID确定新旧)
为了更快达成一致,proposer会把值修改为最有可能达成一致的值
只有多数派接受了值,值才达成一致
一旦一个值达成一致,不可更改
paxos是一致性协议的基础,其他的协议(raft、zab等)都是paxos的改进版本。paxos侧重理论,实现paxos非常困难。谷歌chubby论文中提到,从paxos出发,在实现过程中处理了很多实际中的细节之后,已经变成另外一个算法了,这时候正确性无法得到理论的保证。所以才出现了许多基于paxos的改进算法。