paxos协议的核心想法之一就是少数服从多数！其实就是制定一套固定的策略，在各种情况下都能够选出一个决议。
我们假定有A,B,C,D,E五台机器。kv系统需要put一个数据[key=Whisper -> val=3306]到我们这5台机器上，要保证只要反馈为真，任意两台机器挂掉都不会丢失数据，并且可以保证高可用。怎么做：
- 首先,客户端随机选择一个节点，进行写入提交，这里我们随机选择了C这个节点，这时候C节点就是这次提议的发起人【也叫proposer，在老的2pc协议里也叫做coodinator】，当C收到这个提议的时候，C首先要做的事情是根据当前节点的最新全局global id，做一次自增操作，我们假定，在当时全局id,Global ID是0,所以，这个议案就被对应了一个编号，1--->[key=Whisper -> val=3306]。 然后，他会尝试将这个信息发送给其余的A,B,D,E这几台机器。
- 如果A,B,D,E这几台机器的globalID 小于C给出的决议的GID(1--->[key=Whisper -> val=3306])，那么就告诉C，这个决议被批准了。而如果A,B,D,E这几台机器的GlobalID 大于或等于C给出决议的GID.那么就告知C 这个决议不能够被批准。
- 我们假定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().**