分布式 一致性Paxos算法(转载)

文章1比较通俗易懂,可以入门,转载地址是http://www.cnblogs.com/linbingdong/p/6253479.html

Paxos算法在分布式领域具有非常重要的地位。但是Paxos算法有两个比较明显的缺点:1.难以理解 2.工程实现更难。

网上有很多讲解Paxos算法的文章,但是质量参差不齐。看了很多关于Paxos的资料后发现,学习Paxos最好的资料是论文《Paxos Made Simple》,其次是中、英文版维基百科对Paxos的介绍。本文试图带大家一步步揭开Paxos神秘的面纱。

Paxos是什么

Paxos算法是基于消息传递且具有高度容错特性一致性算法,是目前公认的解决分布式一致性问题最有效的算法之一。

Google Chubby的作者Mike Burrows说过这个世界上只有一种一致性算法,那就是Paxos,其它的算法都是残次品

虽然Mike Burrows说得有点夸张,但是至少说明了Paxos算法的地位。然而,Paxos算法也因为晦涩难懂而臭名昭著。本文的目的就是带领大家深入浅出理解Paxos算法,不仅理解它的执行流程,还要理解算法的推导过程,作者是怎么一步步想到最终的方案的。只有理解了推导过程,才能深刻掌握该算法的精髓。而且理解推导过程对于我们的思维也是非常有帮助的,可能会给我们带来一些解决问题的思路,对我们有所启发。

问题产生的背景

在常见的分布式系统中,总会发生诸如机器宕机网络异常(包括消息的延迟、丢失、重复、乱序,还有网络分区)等情况。Paxos算法需要解决的问题就是如何在一个可能发生上述异常的分布式系统中,快速且正确地在集群内部对某个数据的值达成一致,并且保证不论发生以上任何异常,都不会破坏整个系统的一致性。

注:这里某个数据的值并不只是狭义上的某个数,它可以是一条日志,也可以是一条命令(command)。。。根据应用场景不同,某个数据的值有不同的含义。

相关概念

Paxos算法中,有三种角色:

在具体的实现中,一个进程可能同时充当多种角色。比如一个进程可能既是Proposer又是Acceptor又是Learner

还有一个很重要的概念叫提案(Proposal。最终要达成一致的value就在提案里。

注:

Proposer可以提出(propose)提案;Acceptor可以接受(accept)提案;如果某个提案被选定(chosen),那么该提案里的value就被选定了。

回到刚刚说的『对某个数据的值达成一致』,指的是ProposerAcceptorLearner都认为同一个value被选定(chosen)。那么,ProposerAcceptorLearner分别在什么情况下才能认为某个value被选定呢?

问题描述

假设有一组可以提出(proposevaluevalue在提案Proposal里)的进程集合。一个一致性算法需要保证提出的这么多value中,只有一个value被选定(chosen)。如果没有value被提出,就不应该有value被选定。如果一个value被选定,那么所有进程都应该能学习(learn到这个被选定的value。对于一致性算法,安全性(safaty要求如下:

我们不去精确地定义其活性(liveness要求。我们的目标是保证最终有一个提出的value被选定。当一个value被选定后,进程最终也能学习到这个value

Paxos的目标:保证最终有一个value会被选定,当value被选定后,进程最终也能获取到被选定的value

假设不同角色之间可以通过发送消息来进行通信,那么:

推导过程

最简单的方案——只有一个Acceptor

假设只有一个Acceptor(可以有多个Proposer),只要Acceptor接受它收到的第一个提案,则该提案被选定,该提案里的value就是被选定的value。这样就保证只有一个value会被选定。

但是,如果这个唯一的Acceptor宕机了,那么整个系统就无法工作了!

因此,必须要有多个Acceptor

多个Acceptor

多个Acceptor的情况如下图。那么,如何保证在多个Proposer和多个Acceptor的情况下选定一个value呢?

下面开始寻找解决方案。

如果我们希望即使只有一个Proposer提出了一个value,该value也最终被选定。

那么,就得到下面的约束:

P1:一个Acceptor必须接受它收到的第一个提案。

但是,这又会引出另一个问题:如果每个Proposer分别提出不同的value,发给不同的Acceptor。根据P1Acceptor分别接受自己收到的value,就导致不同的value被选定。出现了不一致。如下图:

刚刚是因为『一个提案只要被一个Acceptor接受,则该提案的value就被选定了』才导致了出现上面不一致的问题。因此,我们需要加一个规定:

规定:一个提案被选定需要被半数以上Acceptor接受

这个规定又暗示了:『一个Acceptor必须能够接受不止一个提案!』不然可能导致最终没有value被选定。比如上图的情况。v1v2v3都没有被选定,因为它们都只被一个Acceptor的接受。

最开始讲的『提案=value』已经不能满足需求了,于是重新设计提案,给每个提案加上一个提案编号,表示提案被提出的顺序。令『提案=提案编号+value』。

虽然允许多个提案被选定,但必须保证所有被选定的提案都具有相同的value值。否则又会出现不一致。

于是有了下面的约束:

P2:如果某个valuev的提案被选定了,那么每个编号更高的被选定提案的value必须也是v

一个提案只有被Acceptor接受才可能被选定,因此我们可以把P2约束改写成对Acceptor接受的提案的约束P2a

P2a:如果某个valuev的提案被选定了,那么每个编号更高的被Acceptor接受的提案的value必须也是v

只要满足了P2a,就能满足P2

但是,考虑如下的情况:假设总的有5AcceptorProposer2提出[M1,V1]的提案,Acceptor2~5(半数以上)均接受了该提案,于是对于Acceptor2~5Proposer2来讲,它们都认为V1被选定。Acceptor1刚刚从宕机状态恢复过来(之前Acceptor1没有收到过任何提案),此时Proposer1Acceptor1发送了[M2,V2]的提案(V2≠V1M2>M1),对于Acceptor1来讲,这是它收到的第一个提案。根据P1(一个Acceptor必须接受它收到的第一个提案。),Acceptor1必须接受该提案!同时Acceptor1认为V2被选定。这就出现了两个问题:

所以我们要对P2a约束进行强化!

P2a是对Acceptor接受的提案约束,但其实提案是Proposer提出来的,所有我们可以对Proposer提出的提案进行约束。得到P2b

P2b:如果某个valuev的提案被选定了,那么之后任何Proposer提出的编号更高的提案的value必须也是v

P2b可以推出P2a进而推出P2

那么,如何确保在某个valuev的提案被选定后,Proposer提出的编号更高的提案的value都是v呢?

只要满足P2c即可:

P2c:对于任意的NV,如果提案[N, V]被提出,那么存在一个半数以上的Acceptor组成的集合S,满足以下两个条件中的任意一个:

Proposer生成提案

为了满足P2b,这里有个比较重要的思想:Proposer生成提案之前,应该先去『学习』已经被选定或者可能被选定的value,然后以该value作为自己提出的提案的value。如果没有value被选定,Proposer才可以自己决定value的值。这样才能达成一致。这个学习的阶段是通过一个Prepare请求』实现的。

于是我们得到了如下的提案生成算法

(a) Proposer承诺保证不再接受任何编号小于N的提案

(b) 如果Acceptor已经接受过提案,那么就向Proposer响应已经接受过的编号小于N最大编号的提案

我们将该请求称为编号为NPrepare请求

Acceptor接受提案

Acceptor可以忽略任何请求(包括Prepare请求和Accept请求)而不用担心破坏算法的安全性。因此,我们这里要讨论的是什么时候Acceptor可以响应一个请求。

我们对Acceptor接受提案给出如下约束:

P1a:一个Acceptor只要尚未响应过任何编号大于NPrepare请求,那么他就可以接受这个编号为N的提案

如果Acceptor收到一个编号为NPrepare请求,在此之前它已经响应过编号大于NPrepare请求。根据P1a,该Acceptor不可能接受编号为N的提案。因此,该Acceptor可以忽略编号为NPrepare请求。当然,也可以回复一个error,让Proposer尽早知道自己的提案不会被接受。

因此,一个Acceptor只需记住1. 已接受的编号最大的提案 2. 已响应的请求的最大编号。

Paxos算法描述

经过上面的推导,我们总结下Paxos算法的流程。

Paxos算法分为两个阶段。具体如下:

(a) Proposer选择一个提案编号N,然后向半数以上Acceptor发送编号为NPrepare请求

(b) 如果一个Acceptor收到一个编号为NPrepare请求,且N大于Acceptor已经响应过的所有Prepare请求的编号,那么它就会将它已经接受过的编号最大的提案(如果有的话)作为响应反馈给Proposer,同时该Acceptor承诺不再接受任何编号小于N的提案

(a) 如果Proposer收到半数以上Acceptor对其发出的编号为NPrepare请求的响应,那么它就会发送一个针对[N,V]提案Accept请求半数以上Acceptor。注意:V就是收到的响应编号最大的提案的value,如果响应中不包含任何提案,那么V就由Proposer自己决定

(b) 如果Acceptor收到一个针对编号为N的提案的Accept请求,只要该Acceptor没有对编号大于NPrepare请求做出过响应,它就接受该提案

Learner学习被选定的value

Learner学习(获取)被选定的value有如下三种方案:

如何保证Paxos算法的活性

通过选取Proposer,就可以保证Paxos算法的活性。至此,我们得到一个既能保证安全性,又能保证活性分布式一致性算法——Paxos算法

 

 

 

文章2,来自http://blog.csdn.net/21aspnet/article/details/50700123

Paxos算法莱斯利·兰伯特(英语:Leslie LamportLaTeX中的「La」)于1990年提出的一种基于消息传递且具有高度容错特性的一致性算法。

Paxos算法一开始非常难以理解,但是一旦理解其实也并不难,之所以难理解其实是因为作者讲的故事难理解。

Paxos算法维基百科https://en.wikipedia.org/wiki/Paxos_(computer_science)

网上有2篇帖子是讲的非常好的,

分别是:以两军问题为背景来演绎Basic PaxosPaxos算法细节详解()--通过现实世界描述算法

本人是在看了这2个帖子之后再结合原论文才看懂的。

 

Paxos一共4个角色:Client   Proposer      Acceptor     Learner

Client:产生议题者
Proposer
:提议者
Acceptor
:决策者
Learner
:最终决策学习者,也就是执行者。

 

Proposer拿着Client的议题去向Acceptor提议,让Acceptor来决策。
Proposer
提出议题,Acceptor初步接受或者Acceptor初步不接受。
Acceptor
初步接受则Proposer再次向Acceptor确认是否最终接受。
Acceptor
最终接受或者Acceptor最终不接受。

Learner最终学习的目标是向所有Acceptor学习,如果有多数派个Acceptor最终接受了某提议,那就得到了最终的结果,算法的目的就达到了。

 

最基本的Message flow: Basic Paxos演示图如下图所示,其他情况可以参考百科。

图解:

A1,A2A3就是Acceptor

P1p2p3就是Proposer。浅色的P1P2说明是进行提议,深色的P1P2说明是拿到表决。

圆圈123表明是每次提议序号,递增即可。黑色的图表示被黑了,也就是否决。方块表示投票结果,绿方块表示投票通过,红色菱形表示最终的投票结果。

整个事件是按照时间线从左到右发展。

 

事件发展:

第一个框代表第一阶段--提议

1.p2最先找到A2P2提议序号是2A2记录下,因为之前没有其他的序号所以成功了,然后返回标志给p2;

2.p1找到A1P1提议序号是1A1记录下,因为之前没有其他的序号所以成功了,然后返回标志给p1;

3.p1找到A3P1提议序号是1A3记录下,因为之前没有其他的序号所以成功了,然后返回标志给p1;

问题来了

4.p1找到A2P1提议序号是1A2已经记录下提议序号22>1,所以不成功;

5.p2找到A1P2提议序号是2A1已经记录下提议序号11>2,所以成功;,然后返回标志给p2;

6.p2找到A3P2提议序号是2A3已经记录下提议序号11>2,所以成功;,然后返回标志给p2;

 

第二个框代表第二阶段--确认提议(投票)

7.p1找到A1P1确认序号是1A1已经记录下提议序号21<2,所以不确认,然后p1继续提议序号是3,周而复始...;

8.p2找到A2P2确认序号是2A2已经记录下提议序号22=2,所以确认成功;,然后返回投票标志给p2;

9.p2找到A3P2确认序号是2A3已经记录下提议序号22=2,所以确认成功;,然后返回投票标志给p2;

10.p2找到A1P2确认序号是2A1已经记录下提议序号32<3,所以不确认,;然后p2继续提议序号是4,周而复始...;
问题来了

11.p1找到A2P1确认序号是1A1已经记录下确认序号21<2,所以不确认,然后返回确认序号2;

12.p1找到A3P1确认序号是1A3已经记录下确认序号21<2,所以不确认,然后返回确认序号2;

13.p1p2都得到确认也就是投票结果是2

14.所有的Learner最终学习的目标是2

 

Paxos过程结束了,这样,一致性得到了保证,算法运行到最后所有的proposer都投"2"所有的acceptor都接受这个议题,也就是说在最初的第二阶段,议题是先入为主的,谁先占了先机,后面的proposer在第一阶段就会学习到这个议题而修改自己本身的议题,才能让一致性得到保证,这就是paxos算法的一个过程。该算法就是为了追求结果的一致性。

文章3,来自:http://www.cnblogs.com/cchust/p/5617989.html

 

 Paxos算法是莱斯利·兰伯特(Leslie Lamport)1990年提出的一种基于消息传递的一致性算法。Paxos算法解决的问题是一个分布式系统如何就某个值(决议)达成一致。在工程实践意义上来说,就是可以通过Paxos实现多副本一致性,分布式锁,名字管理,序列号分配等。比如,在一个分布式数据库系统中,如果各节点的初始状态一致,每个节点执行相同的操作序列,那么他们最后能得到一个一致的状态。为保证每个节点执行相同的命令序列,需要在每一条指令上执行一个"一致性算法"以保证每个节点看到的指令一致。本文首先会讲原始的Paxos算法(Basic Paxos),主要描述二阶段提交过程,然后会着重讲Paxos算法的变种(Multi Paxos),它是对Basic Paxos的优化,而且更适合工程实践,最后我会通过Q&A的方式,给出我在学习Paxos算法中的疑问,以及我对这些疑问的理解。

概念与术语 
Proposer
:提议发起者,处理客户端请求,将客户端的请求发送到集群中,以便决定这个值是否可以被批准。
Acceptor
:提议批准者,负责处理接收到的提议,他们的回复就是一次投票,会存储一些状态来决定是否接收一个值。
replica
:节点或者副本,分布式系统中的一个server,一般是一台单独的物理机或者虚拟机,同时承担paxos中的提议者和接收者角色。
ProposalId
:每个提议都有一个编号,编号高的提议优先级高。
Paxos Instance
Paxos中用来在多个节点之间对同一个值达成一致的过程,比如同一个日志序列号:logIndex,不同的logIndex属于不同的Paxos Instance
acceptedProposal
:在一个Paxos Instance内,已经接收过的提议
acceptedValue
:在一个Paxos Instance内,已经接收过的提议对应的值。
minProposal
:在一个Paxos Instance内,当前接收的最小提议值,会不断更新

Basic-Paxos算法
     
基于Paxos协议构建的系统,只需要系统中超过半数的节点在线且相互通信正常即可正常对外提供服务。它的核心实现Paxos Instance主要包括两个阶段:准备阶段(prepare phase)和提议阶段(accept phase)。如下图所示:


1.
获取一个ProposalId,为了保证ProposalId递增,可以采用时间戳+serverId方式生成;
2.
提议者向所有节点广播prepare(n)请求;
3.
接收者比较nminProposal,如果n>minProposal,表示有更新的提议,minProposal=n;否则将(acceptedProposal,acceptedValue)返回;
4.
提议者接收到过半数请求后,如果发现有acceptedValue返回,表示有更新的提议,保存acceptedValue到本地,然后跳转1,生成一个更高的提议;
5.
到这里表示在当前paxos instance内,没有优先级更高的提议,可以进入第二阶段,广播accept(n,value)到所有节点;
6.
接收者比较nminProposal,如果n>=minProposal,acceptedProposal=minProposal=nacceptedValue=value,本地持久化后,返回;
否则,返回minProposal
7.
提议者接收到过半数请求后,如果发现有返回值>n,表示有更新的提议,跳转1;否则value达成一致。
从上述流程可知,并发情况下,可能会出现第4步或者第7步频繁重试的情况,导致性能低下,更严重者可能导致永远都无法达成一致的情况,就是所谓的"活锁",如下图所示:

 

1.S1作为提议者,发起prepare(3.1),并在S1,S2S3达成多数派;
2.
随后S5作为提议者 ,发起了prepare(3.5),并在S3,S4S5达成多数派;
3.S1
发起accept(3.1,value1),由于S3上提议 3.5>3.1,导致accept请求无法达成多数派,S1尝试重新生成提议
4.S1
发起prepare(4.1),并在S1S2S3达成多数派
5.S5
发起accpet(3.5,value5),由于S3上提议4.1>3.5,导致accept请求无法达成多数派,S5尝试重新生成提议
6.S5
发起prepare(5.5),并在S3,S4S5达成多数派,导致后续的S1发起的accept(4.1,value1)失败

......

prepare阶段的作用
Basic-Paxos的描述可知,需要通过两阶段来最终确定一个值,由于轮回多,导致性能低下,至少两次网络RTT。那么prepare阶段能否省去?如下图所示:


1.S1
首先发起accept(1,red),并在S1,S2S3达成多数派,redS1S2S3上持久化
2.
随后S5发起accept(5,blue),对于S3而言,由于接收到更新的提议,会将acceptedValue值改为blue
3.
那么S3S4S5达成多数派,blueS3S4S5持久化
4.
最后的结果是,S1S2的值是red,而S3S4S5的值是blue,没有达成一致。

所以两阶段必不可少,Prepare阶段的作用是阻塞旧的提议,并且返回已经接收到的acceptedProposal。同时也可以看到的是,假设只有S1提议,则不会出现问题,这就是我们下面要讲的Multi-Paxos

Multi-paxos算法
     Paxos
是对一个值达成一致,Multi-Paxos是连续多个paxos instance来对多个值达成一致,这里最核心的原因是multi-paxos协议中有一个LeaderLeader是系统中唯一的Proposal,在lease租约周期内所有提案都有相同的ProposalId,可以跳过prepare阶段,议案只有accept过程,一个ProposalId可以对应多个Value,所以称为Multi-Paxos

选举
     
首先我们需要有一个leader,其实选主的实质也是一次Paxos算法的过程,只不过这次Paxos确定的"谁是leader"这个值。由于任何一个节点都可以发起提议,在并发情况下,可能会出现多主的情况,比如AB先后当选为leader。为了避免频繁选主,当选leader的节点要马上树立自己的leader权威(让其它节点知道它是leader),写一条特殊日志(start-working日志)确认其身份。根据多数派原则,只有一个leaderstartworking日志可以达成多数派。leader确认身份后,可以通过了lease机制(租约)维持自己的leader身份,使得其它proposal不再发起提案,这样就进入了leader任期,由于没有并发冲突,因此可以跳过prepare阶段,直接进入accept阶段。通过分析可知,选出leader后,leader任期内的所有日志都只需要一个网络RTT(Round Trip Time)即可达成一致。

新主恢复流程
     
由于Paxos中并没有限制,任何节点都可以参与选主并最终成为leader,这就无法保证新选出的leader包含了所有日志,可能存在空洞,因此在真正提供服务前,还存在一个获取所有已提交日志的恢复过程。新主向所有成员查询最大logId的请求,收到多数派响应后,选择最大的logId作为日志恢复结束点,这里多数派的意义在于恢复结束点包含了所有达成一致的日志,当然也可能包含了没有达成多数派的日志。拿到logId后,从头开始对每个logId逐条进行paxos协议,因为在新主获得所有日志之前,系统是无法提供服务的。为了优化,引入了confirm机制,就是将已经达成一致的logId告诉其它acceptoracceptor写一条confirm日志到日志文件中。那么新主在重启后,扫描本地日志,对于已经拥有confirm日志的log,就不会重新发起paxos了。同样的,在响应客户端请求时,对于没有confirm日志的log,需要重新发起一轮paxos。由于没有严格要求confirm日志的位置,可以批量发送。为了确保重启时,不需要对太多已提价的log进行paxos,需要将confirm日志与最新提交的logId保持一定的距离。

性能优化
      Basic-Paxos
一次日志确认,需要至少2次磁盘写操作(prepare,promise)2次网络RTT(prepare,promise)Multi-Paxos利用一阶段提交(省去Prepare阶段),将一次日志确认缩短为一个RTT和一次磁盘写;通过confirm机制,可以缩短新主的恢复时间。为了提高性能,我们还可以实现一批日志作为一个组提交,要么成功一批,要么都不成功,这点类似于group-commit,通过RT换取吞吐量。

安全性(异常处理)
1.Leader
异常
Leader
在任期内,需要定期给各个节点发送心跳,已告知它还活着(正常工作),如果一个节点在超时时间内仍然没有收到心跳,它会尝试发起选主流程。Leader异常了,则所有的节点先后都会出现超时,进入选主流程,选出新的主,然后新主进入恢复流程,最后再对外提供服务。我们通常所说的异常包括以下三类:
(1).
进程crash(OS crash)
Leader
进程crashOs crash类似,只要重启时间大于心跳超时时间都会导致节点认为leader挂了,触发重新选主流程。
(2).
节点网络异常(节点所在网络分区)
Leader
网络异常同样会导致其它节点收不到心跳,但有可能leader是活着的,只不过发生了网络抖动,因此心跳超时不能设置的太短,否则容易因为网络抖动造成频繁选主。另外一种情况是,节点所在的IDC发生了分区,则同一个IDC的节点相互还可以通信,如果IDC中节点能构成多数派,则正常对外服务,如果不能,比如总共4个节点,两个IDC,发生分区后会发现任何一个IDC都无法达成多数派,导致无法选出主的问题。因此一般Paxos节点数都是奇数个,而且在部署节点时,IDC节点的分布也要考虑。
(3).
磁盘故障
前面两种异常,磁盘都是OK的,即已接收到的日志以及对应confirm日志都在。如果磁盘故障了,节点再加入就类似于一个新节点,上面没有任何日志和Proposal信息。这种情况会导致一个问题就是,这个节点可能会promise一个比已经promise过的最大proposalID更小的proposal,这就违背了Paxos原则。因此重启后,节点不能参与Paxos Instance,它需要先追上Leader,当观察到一次完整的paxos instance时该节点结束不能promise/ack状态。
2.Follower
异常(宕机,磁盘损坏等)
对于Follower异常,则处理要简单的多,因为follower本身不对外提供服务(日志可能不全),对于leader而言,只要能达成多数派,就可以对外提供服务。follower重启后,没有promise能力,直到追上leader为止。

Q&A
1.Paxos
协议数据同步方式相对于基于传统1N备的同步方式有啥区别?
     
一般情况下,传统数据库的高可用都是基于主备来实现,112个副本,主库crash后,通过HA工具来进行切换,提升备库为主库。在强一致场景下,复制可以开启强同步,OracleMysql都是类似的复制模式。但是如果备库网络抖动,或者crash,都会导致日志同步失败,服务不可用。为此,可以引入1N备的多副本形式,我们对比都是3副本的情况,一个是基于传统的12备,另一种基于paxos12备。传统的1主两备,进行日志同步时,只要有一个副本接收到日志并就持久化成功,就可以返回,在一定程度上解决了网络抖动和备库crash问题。但如果主库出问题后,还是要借助于HA工具来进行切换,那么HA切换工具的可用性如何来保证又成为一个问题。基于Paxos的多副本同步其实是在1N备的基础上引入了一致性协议,这样整个系统的可用性完全有3个副本控制,不需要额外的HA工具。而实际上,很多系统为了保证多节点HA工具获取主备信息的一致性,采用了zookeeper等第三方接口来实现分布式锁,其实本质也是基于Paxos来实现的。

      我这里以MySQL的主备复制一套体系为例来具体说明传统的主备保持强一致性的一些问题。整个系统中主要包含以下几种角色:MasterSlaveZookeeper-Service(zk)HA-Console(HA)Zookeeper-Agent(Agent)
Master,Slave:
分别表示主节点和备节点,主节点提供读写服务,备节点可以提供读服务,或者完全用于容灾。
Zookeeper-Service(zk):
分布式一致性服务,负责管理Master/Slave节点的存活信息和切换信息。zk基于zab协议,zab协议是一种一致性协议,与paxosraft协议类似,它主要有两种模式,包括恢复模式(选主)和广播模式(同步)。一般zk包含N个节点(zk-node),只要有超过半数的zk-node存活且相互连通,则zk可以对外提供一致性服务。
HA-Console:
切换工具,负责具体的切换流程
Zookeeper-Agent(Agent):Master/Slave
实例上的监听进程,与监听的实例保持心跳,维护Master/Slave的状态,每个实例有一个对应的Agent。大概工作流程如下:
(1).Master/Slave
正常启动并搭建好了复制关系,对应的Agent会调用zk接口去注册alive节点信息,假设分别为AB
(2).
如果此时Master Crash,则实例对应的Agent发现心跳失败,如果重试几次后仍然失败,则将调用zk接口注销掉A节点信息。
(3).HA
工具通过zk接口比较两次的节点信息,发现少了A节点,表示A可能不存在了,需要切换,尝试连接A,如果仍然不通,注册Adead节点,并开始切换流程。
(4).HA
工具读取配置信息,找到对应的Slave节点B(更改读写比配置信息,设置B提供写),打开写。
(5).
应用程序通过拉取最新的配置信息,得知新主B,新的写入会写入B
前面几部基本介绍了MySQL借助zk实现高可用的流程,由于zk-node可以多地部署,HA无状态,因此可以很容易实现同城或者是异地的高可用系统,并且动态可扩展,一个HA节点可以同时管理多个Master/Slave的切换。那么能保证一致性吗?前面提到的Agent除了做监听,还有一个作用是尽可能保持主备一致,并且不丢数据。
(6).
假设此时A节点重启,Agent检测到,通过zk接口发现A节点在dead目录下,表示被切换过,需要kill上面的所有连接,并回滚crashAB多的binlog,为了尽可能的少丢数据,然后再开启binlog后,将这部分数据重做。这里要注意rollbackreplay都在old-Master上面进行,rollback时需要关闭binlog,而replay需要开启binlog,保证这部分数据能流向new-Master
(7).
从第6步来看,可以一定程度上保证主备一致性,但是进行rollbackreplay时,实际上是往new-Slave上写数据,这一定程度上造成了双写,如果此时new—Master也在写同一条记录,可能会导致写覆盖等问题。
(8).
如果开启半同步呢?old-Master crash时,仍然可能比old-Slave多一个groupbinlog,所以仍然需要借助于rollbackreplay,依然避免不了双写,所以也不能做到严格意义上的强一致。

2.分布式事务与Paxos协议的关系?
     
在数据库领域,提到分布式系统,就会提到分布式事务。Paxos协议与分布式事务并不是同一层面的东西。分布式事务的作用是保证跨节点事务的原子性,涉及事务的节点要么都提交(执行成功),要么都不提交(回滚)。分布式事务的一致性通常通过2PC来保证(Two-Phase Commit, 2PC),这里面涉及到一个协调者和若干个参与者。第一阶段,协调者询问参与者事务是否可以执行,参与者回复同意(本地执行成功),回复取消(本地执行失败)。第二阶段,协调者根据第一阶段的投票结果进行决策,当且仅当所有的参与者同意提交事务时才能提交,否则回滚。2PC的最大问题是,协调者是单点(需要有一个备用节点),另外协议是阻塞协议,任何一个参与者故障,都需要等待(可以通过加入超时机制)Paxos协议用于解决多个副本之间的一致性问题。比如日志同步,保证各个节点的日志一致性,或者选主(主故障情况下),保证投票达成一致,选主的唯一性。简而言之,2PC用于保证多个数据分片上事务的原子性,Paxos协议用于保证同一个数据分片在多个副本的一致性,所以两者可以是互补的关系,绝不是替代关系。对于2PC协调者单点问题,可以利用Paxos协议解决,当协调者出问题时,选一个新的协调者继续提供服务。工程实践中,Google SpannerGoogle Chubby就是利用Paxos来实现多副本日志同步。

3.如何将Paxos应用于传统的数据库复制协议中?
   
复制协议相当于是对Paxos的定制应用,通过对一系列日志进行投票确认达成多数派,就相当于日志已经在多数派持久化成功。副本通过应用已经持久化的日志,实现与Master节点同步。由于数据库ACID特性,本质是由一个一致的状态到另外一个一致的状态,每次事务操作都是对应数据库状态的变更,并生成一条日志。由于client操作有先后顺序,因此需要保证日志的先后的顺序,在任何副本中,不仅仅要保证所有日志都持久化了,而且要保证顺序。对于每条日志,通过一个logID标示,logID严格递增(标示顺序),由leader对每个日志进行投票达成多数派,如果中途发生了leader切换,对于新leaderlogID"空洞",需要重新投票,确认日志的有效性。

4.Multi-Paxos的非leader节点可以提供服务吗?
     Multi-Paxos
协议中只有leader确保包含了所有已经已经持久化的日志,当然本地已经持久化的日志不一定达成了多数派,因此对于没有confirm的日志,需要再进行一次投票,然后将最新的结果返回给client。而非leader节点不一定有所有最新的数据,需要通过leader确认,所以一般工程实现中,所有的读写服务都由leader提供。

5.客户端请求过程中失败了,如何处理?
     client
leader发起一次请求,leader在返回前crash了。对于client而言,这次操作可能成功也可能失败。因此client需要检查操作的结果,确定是否要重新操作。如果leader在本地持久化后,并没有达成多数派时就crash,新leader首先会从各个副本获取最大的logID作为恢复结束点,对于它本地没有confirm的日志进行Paxos确认,如果此时达成多数派,则应用成功,如果没有则不应用。client进行检查时,会知道它的操作是否成功。当然具体工程实践中,这里面涉及到client超时时间,以及选主的时间和日志恢复时间。

 

 

posted on 2017-08-24 11:32  张小贱1987  阅读(329)  评论(0编辑  收藏  举报

导航