PAXOS VS ZAB

paxos协议的核心想法之一就是少数服从多数！其实就是制定一套固定的策略，在各类状况下都可以选出一个决议。

咱们假定有A,B,C,D,E五台机器。kv系统须要put一个数据[key=Whisper -> val=3306]到咱们这5台机器上，要保证只要反馈为真，任意两台机器挂掉都不会丢失数据，而且能够保证高可用。怎么作：

1. 首先,客户端随机选择一个节点，进行写入提交，这里咱们随机选择了C这个节点，这时候C节点就是此次提议的发起人【也叫proposer，在老的2pc协议里也叫作coodinator】，当C收到这个提议的时候，C首先要作的事情是根据当前节点的最新全局global id，作一次自增操做，咱们假定，在当时全局id,Global ID是0,因此，这个议案就被对应了一个编号，1--->[key=Whisper -> val=3306]。 而后，他会尝试将这个信息发送给其他的A,B,D,E这几台机器。
2. 若是A,B,D,E这几台机器的globalID 小于C给出的决议的GID(1--->[key=Whisper -> val=3306])，那么就告诉C，这个决议被批准了。而若是A,B,D,E这几台机器的GlobalID 大于或等于C给出决议的GID.那么就告知C 这个决议不可以被批准。
3. 咱们假定A,B两台机器当时的Max(GID)是0 ，而D,E的Max(GID)是1.那么，A,B两台机器会反馈给C说协议被接受，这时候咱们算算，C的议案有几票了？A+B+!C!，必定要算本身哦:) 。因此，这个议案有三票，5台机器的半数是3.超过法定人数，因而决议就被赞成了。

这时候还有一个问题是须要被考虑的，若是在C已经得知决议已经达到法定人数，在告知全部人接受以前，C挂了，应该怎么办呢？ 我之因此没有将这个放到开始的描述里，主要缘由是以为这是个独立因素，不该该影响议案被接受时候的清晰度。 为了解决这个问题，须要要求全部的accepter在接受某我的提出的议案以后，额外的记录一个信息：当前accepter接受了哪一个提议者的议案。

为何要记录这个？很简单，咱们看一下上面出现这个状况时候的判断标准。 A 机器:角色-accepter 。 批准的议案 1--->[key=Whisper-> val=3306] 。提议人：C B 机器:角色-accepter 。 批准的议案 1--->[key=Whisper-> val=3306] 。提议人：C C机器:角色-proposer 。 挂了。。不知道他的状况。 D 机器:角色-accepter 。 批准的议案 1--->[key=taobao->val=1234] 。提议人：本身 E 机器:角色-proposer。 “提议的”议案 1--->[key=taobao->val=1234] 。提议人：D。

由于有了提议人这个记录，因此在超时后很容易能够判断，议案1--->[key=Whisper -> val=3306] 是取得了多数派的议案，由于虽然D,E两台机器也是能够达成一致的议案的。但由于有我的自己是提议者，因此能够算出这个议案是少数派。 在这以后，提议者还须要作一件事，就是告知D,E，被决定的决议已是什么了。便可。

那么Paxos有没有什么值得改进的地方？有的，很简单，你会发现，若是在一个决议提议的过程当中，其余决议会被否决，否决自己意味着更多的网络io，意味着更多的冲突，这些冲突都是须要额外的开销的，代价很大很大。

其实，这也是在咱们的现实生活中常常可以发现的，若是每一个议案都要通过议会的讨论和表决，那么这个国家的决策无疑是低效的，怎么解决这个问题呢？弄个总统就好了。zab协议就是本着这个思路来改进paxos协议的。

zab协议把整个过程分为两个部分，第一个部分叫选总统，第二个部分叫进行决议。 选总统的过程比较特殊，这种模式，相对的给人感受思路来源于lamport的面包房算法，这个咱们后面讲。，选择的主要依据是： 1.若是有gid最大的机器，那么他是主机。 2.若是好几台主机的gid相同，那么按照序号选择最小的那个。

因此，在开始的时候，给A,B,C,D,E进行编号，0,1,2,3,4。 第一轮的时候，由于你们的Max(gid)都是0，因此天然而然按照第二个规则，选择A做为主机。
     而后，全部人都知道A是主机之后，不管谁收到的请求，都直接转发给A,由A机器去作后续的分发，这个分发的过程，咱们叫进行决议。

    **具体过程是，A会将决议precommit给B,C,D,E。而后等待，当B,C,D,E里面的任意两个返回收到后，就能够进行doCommit().不然进行doAbort().**