Zookeeper_Paxos算法

Paxos算法

算法简介

Paxos算法是莱斯利-兰伯特在1990年提出的一种基于消息传递的、具有容错性的一致性算法，Google Chubb(分布式锁服务)的作者Mike Burrwos说过，世上只有一种一致性算法，那就是Paxos算法，其他一致性算法都是Paxos的不完整版，Paxos算法是一种公认的晦涩难懂的算法，并且工程实现上也具有很大的难度，出名的实现比如Google Chubby/ZAB/微信的PhxPaxos等

Paxos算法要解决的问题就是在分布式系统中如何就某一个协议达成一致

拜占庭将军问题

这个问题是由Paxos的作者提出的点对点通信中的基本问题，该问题说的就是"在存在消息丢失的不可靠信道上试图通过信息传递的方式达到一致性是不可能的"

Paxos算法的前提就是不存在拜占庭将军问题，即信道是安全、可靠的，集群节点间传递的消息是不会被篡改的，在工程实践中，大多数系统都是部署在一个局域网内，因此被篡改的情况很少，另一方面，由于硬件和网络原因造成的消息不完整问题，现在已经不再是问题，只需要一套简单的校验算法即可，因此，在实现工程中各个服务间消息传递过程可以认为不存在拜占庭将军问题

一般情况下，分布式系统中各个节点间采用两种通讯模型："共享内存"，"消息传递"，而Paxos是基于消息传递通讯模型的

算法描述

三个角色

在Paxos算法中有三个角色，分别具有三种不同的行为，更多时候，一个进程可能同时充当着多种角色

Proposer：提案(Proposal)的提议者；
Acceptor：提案的(accept)表决者，即是否承认、接受该提案，超过半数接受，该提案被认定为"选定"；
Learners：提案的学习者，当提案被选定后，其会同步并执行提案，说白一点，他就是那个没有接受提案，但提案最后通过被迫接受的那个；

一个提案的表决者会存在多个，但在一个集群中，提议者是可能存在多个的，不同的提议者给提出不同的提案，而一致性算法则可以保证以下几点

没有提案被提出则不会有提案被选定
每个提案者在提出提案时都会为该提案指定一个具有全局唯一性的、递增的提案编号N,在整个集群中时唯一的
每个表决者在表决某提案后，会将该提案的编号N记录在本地，这样每个表决者中保存的以及被表决的提案中会存在一个编号最大的提案，其编号架设为maxN,每个表决者仅会表决接受编号大于自己本地maxN的提案
在众多提案中，最终只有一个提案被选定
一旦一个提案被选定，则其他服务器会主动同步该提案到本地

算法过程描述

Paxos算法的执行过程划分为两个阶段："准备阶段"，"接受阶段"

一、准备（prepare）阶段

提议者准备提交一个编号为N的提案，其首先向所有的表决者发起 prepare(N)请求,用于试探集群是否支持该编号的提议
每个表决者Acceptor中都保存着自己曾经accept(表决，接受)过的提议中的最大编号maxN,当一个表决者接收到其他主机发送来的prepare(N)请求时，其会比较N与maxN的值，若N的值小于等于maxN,则说明该提议已经过时，当前表决者采用不回应或者回应Error的方式来拒绝该prepare请求，若N大于maxN.则说明该提议是可以接受的，当前表决者会将其曾经接受的编号最大的提案Proposal(mid,manN,value)反馈给提议者，以向提议者展示自己支持的提案意愿，其中第一个参数mid表示该决策者Acceptor的标识id,第二个参数表示期曾接受提案的最大编号maxN,第三个参数表示该提案的真正内容value,当然，若当前表决者还未曾表决、接受过任何提议，则会将Proposal(mid,null,null)反馈给提议者

二、表决（accept）阶段

当提议者发出prepare(N)请求后，若收到超过半数的表决者的接受(Acceptor)的反馈，那么该提议者就会将其真正的提案Proposal（N，value）发送给所有的表决者
当表决者（accpetor）接受接受到提议者发送的Proposal（N,value）提案后，会再次拿出自己曾经接受(accept)过的提议的最大编号maxN,以及曾经反馈过的prepare的最大编号，让N与它们进行比较，若N大于这两个编号，则当前表决者接受(accept)这个提案，并反馈给提议者，若N不大于这两个编号，则表决者采取不回应或者回应Error的方式来拒绝该提议
当提议者没有接收到大于等于半数以上的表决者接受(accrpt)反馈的话，则会重新进入到prepare阶段，递增提案号，重新提出prepare请求，若提议者接受到的接受的反馈数量超过了半数，则其他的未向提议者发送accept反馈的表决者将成为学习者(learner)learner,祝融同步提议者的该提案

算法举列

假设我们有三台主机，他们要从中间选取一个Leader，这三台主机在不同的时间分别充当提案的提议者Proposer、表决者Acceptor、以及学习者Learnor三种不同的角色

这里首先我们介绍一下高举列的前提：

每个tiyizheProposer都想提议自己当Leader,假设三个Proposer-1、Proposer-2、Proposer-3提议的提案初始编号分别为20、10、30，每个提议者都要将提案发送给所有的表决者Acceptor,为了便于理解，因为我们只有三个主机，假设我们就发送给两个表决者即可(已经超过半数)，

Proposer-1 发送给Acceptor-1和Acceptor-2、

Proposer-2 发送给Accrptor-2 和Acceptor-3、

Proposer-3 发送给Acceptor-2 和Acceptor-3

于是就有下面这一幕出现了：

历经下面两个阶段，选出Leader:（这里我们以金龟婿上门提亲为列）

假设 Acceptor-1：哥哥、Acceptor-2：爸爸、Acceptor-3：爷爷

图中，金龟婿1第一个对女朋友家的三个具有决定权的人物的发起了请求：Proposer-1

由于之前没人来上门提亲，也不清楚行情，哥哥和爸爸直接就响应了，收下了金龟婿的10W礼金，并做了礼物响应
(Acceptor-1和Acceptor-2分别返回(server1-id,null,null)，(server2-id,null,null)，并将提议编号20记录)

可能是女孩太漂亮，紧接着第二个追求者也上门提亲了：Proposer-2

这次哥哥出门约妹去了，金龟婿分别拜访了爸爸和爷爷，好家伙，爷爷也是不知道行情怎么样，10W就把孙女给卖了，好在爸爸在之前已经有了这方面的经验，心里想到，老子手里捏着一个20W的礼金，会卵你这个10W的，选择了不予理会，金龟婿2吃了爸爸的闭门羹，只收到了爷爷一个人的响应，闷闷不乐的离开了女方家
Proposer-2发来提案，Acceptor-2查询发现本地提案号大于请求的提案号不做响应，但是由于Acceptor3没有接受过任何提案，所以直接接受了请求，并返回(server3-id,nill,null)，然后将提案号记录在了本地，Proposer2只收到了一个反馈，没有超过半数

可能是从众，也可能是那个女孩是真的乖巧，第三个金龟婿如约而至的上门提亲：Proposer-3

哥哥由于比较年轻，约的妹儿有点多，还是没在家，这次还是爸爸和爷爷分别接待的，第三个金龟婿人虽然丑了点，但是口气就不得了了啊，张口就承诺了30W礼金,爸爸听的眼睛都瞪大了，渐渐的发现面前的这个面目全非的男人的面容也变的俊俏了起来，想把之前收下的20W礼金退了的想法开始在脑海中浮现，加之酒一喝菜一吃，牙齿一咬，便一口答应把之前的礼金都退了，和面前这个俊俏的男人结为亲家，爷爷那边，如法炮制般的手段便得到了爷爷的响应，金龟婿3收到了两个响应，兴高采烈的踏出女方家门
Proposer3发来提案，由于受理的两个决策者发现本地的提案号均小于请求的提案号，故而接受了请求，并用请求的提案号覆盖了本地的提案号，并分别返回了（(server2-id,null,null)，(server3-id,null,null)）

第二个金龟婿回家后思前想后，后来一打听，才知道，原来是自己的礼金给少了，不受未来岳父的待见，还听说已经答应请求的爷爷也反水了，想退回他的礼金，心有不甘的他给自己老汉儿打了一个长长的电话，电话里，道尽了一个单身男人的空虚寂寞与无奈，电话那头的老汉儿铿锵的告诉他，喜欢就去追，钱不是问题！在礼金还没退回的时候，金龟婿2再次登门拜访，不过这次他可是有备而来，风雨欲来花满楼，欲知后事如何，请听下回分解：

金龟婿2心有不甘的再次踏进了女方的家门，手里有了老汉儿的支持，彷佛脚步都轻快了起来，在进门的那那一刹那，说时迟那时快，一柄飞刀擦肩而过，稳稳的栽到背后那个三尺后的木门上，周身汗毛不寒而栗，刀尾那因快速震动而发出的嗡嗡声，似乎在告诉他和死亡近在咫尺，察觉到自己有些失了金龟婿的的颜面，清清嗓子，阳气不足的的憋了几个字：”谁啊，谁他妈找死“，只见屋里出来一个魁梧大汉，眉眼间透露出丝丝杀气，金龟婿2定睛一看，这不是附近山头的的匪寇邹桥吗，后面跟着的那个女的不就是号称小李飞刀的汤小妹吗，这兄妹儿二人今天来此地做甚？连忙皮笑肉不笑的迎了上去，一番交谈后才了解到，原来这兄妹二人听说这家闺女长得甚是闭月羞花，想抢回去给自己的三弟桃桃做压寨夫人，邹桥也不是一个不识大体的人，见走近的这个人是附近巨贾胡明松的儿子，大汉心里似乎也了忌惮几分，随口一说，要么给40W赎金，要么把人拉走，本想这用此等数目的钱吓退这个富二代，可话音没落，40就40,你明天去我家取便是了，料想这个邹桥也没那个胆子，金龟婿2貌似也有点有恃无恐了起来，最后，金龟婿以40W的礼金，重重的抨击了未来岳父大人和岳父大人的爸爸的心脏，抱得美人归！
Proposer2由于没有获得超过半数的反馈，于是对自身的提案号进行递增，再次对ACceptor-2/-3发起请求，直到提案号大于Acceptor-2/-3的提案号，收到超过半数的反馈(两个)，两个表决者接受了请求，并用请求的提案号覆盖了本地的提案号，并分别返回了（(server2-id,null,null)，(server3-id,null,null)）

由于Acceptor-2/-3已经通过了Proposer-2的提案，并超过了半数，server2立马成为了Leader，选举状态结束，server2会发布广播给所有的Learner，通知他们来同步数据，同步完成后集群进入服务状态

个人理解：(可能不正确)

当所有发起自己当Leader的提案的提案者都获得超过半数以上的反馈，如若没有没得超过半数的反馈，则提案号自增无限发起提案请求，直到全部都得到超过半数以上的反馈，此时谁的提案号最大，谁当选为Leader，并结束Leader选举，然后Leader广播给所有的learner,通知他们来同步数据，同步完成后集群进入到服务状态