Zookeeper笔记二-各种一致性协议解释

我们知道Zookeeper的一致性是解决分布式事务的。

那么分布式事务代表的是强一致性。

强一致性解决的代表有以下协议(注意这几个协议跟zookeeper是没任何关系的,这是分布式的理论基础):

1.  2PC(二阶提交),顾名思义它分成两个阶段,先由一方进行提议(propose)并收集其他节点的反馈(vote),再根据反馈决定提交(commit)或中止(abort)事务。我们将提议的节点称为协调者(coordinator),其他参与决议节点称为参与者(participants, 或cohorts)。

在阶段1中,协调者发起一个提议,分别问询各参与者是否接受。

在阶段2中,协调者根据参与者的反馈,提交或中止事务,如果参与者全部同意则提交,只要有一个参与者不同意就中止。

如下图:

 

在异步环境并且没有节点宕机的模型下,2PC可以满足全认同、值合法、可结束,是解决一致性问题的一种协议。但如果再加上节点宕机的考虑,2PC是否还能解决一致性问题呢? 

答案是可以的

因为协调者如果在发起提议后宕机,那么参与者将进入阻塞状态、一直等待协调者回应以完成该次决议。这时需要另一角色把系统从不可结束的状态中带出来,我们把新增的这一角色叫协调者备份。协调者宕机一定时间后,协调者备份接替原协调者工作,通过问询各参与者的状态,决定阶段2是提交还是中止。这也要求 协调者/参与者 记录历史状态,以备协调者宕机后备份对参与者查询、协调者宕机恢复后重新找回状态。

从协调者接收到一次事务请求、发起提议到事务完成,经过2PC协议后增加了2次RTT(propose+commit),带来的时延增加相对较少。

这种方式有一定的缺点,就是增加了备份参与者,节点的沟通就越频繁,出现网络问题的概率就越大。

因此二阶段提交的总结是:2PC可以在异步网络+节点宕机恢复的模型下实现一致性

 

2.  3PC(三阶段提交)其实就是对二阶段提交进行改进了

在二阶段提交中中一个参与者的状态只有它自己和协调者知晓,假如协调者提议后出现自身宕机,在备用启用之前,一个参与者又宕机了,其他参与者就会进入既不能回滚、又不能强制commit的阻塞状态,直到参与者宕机恢复。

那么会有这样的疑问:

1.可不可以去掉阻塞,使系统可以在commit/abort前回滚到决议发起前的初始状态呢?

2.当次决议中,参与者间可不可以知道对方的状态,又或者参与者间根本不依赖对方的状态

三阶段提交增加了一个准备提交阶段来解决以上问题。如下图:

参阅这如果在不同阶段宕机,3阶段提交的处理方式:

第一阶段:协调者或备份未收到宕机参与者的反馈,直接中止事务;宕机的参与者恢复后,读取记录发现未发出赞成反馈,则自行中止该次事务。

第二阶段:协调者未收到宕机参与者的precommit ACK,之前已经收到了宕机参与者的赞成反馈,因为只有之前已经收到了宕机参与者的赞成反馈才进入了阶段二,协调者进行事务提交;协调者备份可以通过问询其他参与者获得这些信息;宕机的参与者恢复后发现收到precommit或已经发出赞成反馈,则自行commit这次事务。

第三阶段:即使协调者或协调者备份未收到宕机参与者的事务提交的 ACK,也要结束本次事务;宕机的参与者恢复后发现收到事务提交或者提交预授权,也将自行commit本次事务

3PC总结:三阶段提交有了准备提交(prepare to commit)阶段,3PC的事务处理延时也增加了1个RTT,变为3个RTT(propose+precommit+commit),但是它防止参与者宕机后整个系统进入阻塞态,增强了系统的高可用性,对一些特殊的业务场景是非常有用的。

 

这些2PC,3PC体现的层面,在JAVAEE中体现出来的是只要是JTA(Java Transaction API)。

JTA:提供了跨数据库连接(或其他JTA资源)的事务管理能力。JTA事务管理则由JTA容器实现,J2ee框架中事务管理器与应用程序,资源管理器,以及应用服务器之间的事务通讯。

JTA提供的支持有Jboss,Jboss类似与Tomcat的一个容器。Tomcat是天生不支持JTA的,要引入JOTM(Java Open Transaction Manager)可以解决。

3.  NWR。N:代表数据分了多少片,即多少个节点。W:每次写入多少个节点算成功。R:每次读取多少个节点算成功。如下图:

 

 这样NWR也最终可以达到强一致性。

 

 Zookeeper的核心算法——Paxos算法(Master选举算法)

Paxos协议分为两个阶段。

这里我们首先要明确什么是提案:提案:[编号,值]即[key,value]。当Master宕机后,从节点向Acceptor提出提案让我这个从节点做Master,这些体验要给Acceptor决策。

整个过程分为两个阶段:

  • phase1(准备阶段)

    • Proposer向超过半数(n/2+1)Acceptor发起prepare消息(发送编号)

    • 如果prepare符合协议规则Acceptor回复promise消息,否则拒绝

  • phase2(决议阶段或投票阶段)

    • 如果超过半数Acceptor回复promise,Proposer向Acceptor发送accept消息(此时包含真实的值)

    • Acceptor检查accept消息是否符合规则,消息符合则批准accept请求

约束条件:

   1.Acceptor必须接受他接收到的第一个提案。注意:这个是不完备的。如果恰好一半Acceptor接受的提案具有value A,另一半接受的提案具有value B,那么就无法形成多数派,无法批准任何一个value。

  2.当且仅当Acceptor没有回应过编号大于n的prepare请求时,Acceptor接受(accept)编号为n的提案。

  3.只有Acceptor没有接受过提案Proposer才能采用自己的Value,否者Proposer的Value提案为Acceptor中编号最大的Proposer Value;

  4.一个提案被选中需要过半数的Acceptor接受。

根据上述过程当一个proposer发现存在编号更大的提案时将终止提案。这意味着提出一个编号更大的提案会终止之前的提案过程。如果两个proposer在这种情况下都转而提出一个编号更大的提案,就可能陷入活锁,违背了Progress的要求。这种情况下的解决方案是选举出一个leader,仅允许leader提出提案。但是由于消息传递的不确定性,可能有多个proposer自认为自己已经成为leader。Lamport在The Part-Time Parliament一文中描述并解决了这个问题。

step1:,设置时钟:proposer令localClock=globalClock.incrementAndGet()。为了让这套系统能正确运行,我们需要一个精确的时钟。由于操作系统的物理时钟经常是有偏差的,所以我们决定采用一个逻辑时钟。时钟的目的是给系统中 发生的每一个事件编排一个序号。假设我们有一台单独的机器提供了一个全局的计数器服务。它只支持一个方法:incrementAndGet()。这个方法 的作用是将计数器的值加一,并且返回增加后的值。我们将这个计数器称为globalClock。globalClock的初始值为0。然后,系统中的每个其它机器,都有一个自己的localClock,它的初始值来自globalClock。

step2:prepare:proposer向所有Acceptor发送一个prepare消息。接收方应返回它最近一次accept的value,以及 accept的时间,若在它还没有accept过value,那么就返回空。proposer只有在收到过半数的response之后,才可进入下一个阶段。一旦收到reject消息,那么就重头来。

step3:构造Proposal:proposer从prepare阶段收到的所有values中选取时间戳最新的一个。如果没有,那么它自己提议一个value。


step4:发送Proposal:proposer把value发送给其它所有机器,消息的时间戳取自localClock。接收方只要检查消息时间戳合法,那么就接受此value,把这个value和时间戳写入到硬盘上,然后答复OK,否则拒绝接受。proposer若收到任何的reject答复,则回到 step1。否则,在收到过半数的OK后,此Proposal被通过。

 

算法图解如下:

 

 

 

Phase1(准备阶段)
每个Server都向Proposer发消息称自己要成为leader,Server1往Proposer1发、Server2往Proposer2发、Server3往Proposer3发;
现在每个Proposer都接收到了Server1发来的消息但时间不一样,Proposer2先接收到了,然后是Proposer1,接着才是Proposer3;
Proposer2首先接收到消息所以他从系统中取得一个编号1,Proposer2向Acceptor2和Acceptor3发送一条,编号为1的消
息;接着Proposer1也接收到了Server1发来的消息,取得一个编号2,Proposer1向Acceptor1和Acceptor2发送一条,编号为2的消息; 最后Proposer3也接收到了Server3发来的消息,取得一个编号3,Proposer3向Acceptor2和Acceptor3发送一条,编号为3的消息;

这时Proposer1发送的消息先到达Acceptor1和Acceptor2,这两个都没有接收过请求所以接受了请求返回[2,null]给Proposer1,并承诺不接受编号小于2的请求;
此时Proposer2发送的消息到达Acceptor2和Acceptor3,Acceprot3没有接收过请求返回[1,null]给Proposer2,并承诺不接受编号小于1的请求,但这时Acceptor2已经接受过Proposer1的请求并承诺不接受编号小于的2的请求了,所以Acceptor2拒绝Proposer2的请求;
最后Proposer3发送的消息到达Acceptor2和Acceptor3,Acceptor2接受过提议,但此时编号为3大于Acceptor2的承诺2与Accetpor3的承诺1,所以接受提议返回[3,null];
Proposer2没收到过半的回复所以重新取得编号4,并发送给Acceptor2和Acceptor3,然后Acceptor2和Acceptor3通过


Phase2(决议阶段)
Proposer3收到过半(三个Server中两个)的返回,并且返回的Value为null,所以Proposer3提交了[3,server3]的议案;
Proposer1收到过半返回,返回的Value为null,所以Proposer1提交了[2,server1]的议案;
Proposer2收到过半返回,返回的Value为null,所以Proposer2提交了[4,server2]的议案;
Acceptor1、Acceptor2接收到Proposer1的提案[2,server1]请求,Acceptor2承诺编号大于4所以拒绝了通过,Acceptor1通过了请求;
Proposer2的提案[4,server2]发送到了Acceptor2、Acceptor3,提案编号为4所以Acceptor2、Acceptor3都通过了提案请求;
Acceptor2、Acceptor3接收到Proposer3的提案[3,server3]请求,Acceptor2、Acceptor3承诺编号大于4所以拒绝了提案;
此时过半的Acceptor都接受了Proposer2的提案[4,server2],Larner感知到了提案的通过,Larner学习提案,server2成为Leader;

 

posted @ 2018-01-24 00:11  妮蔻  阅读(...)  评论(...编辑  收藏