讲一个关于paxos的故事...

先讲一个故事。

从前，在国王Leslie Lamport的统治下，有个黑暗的希腊城邦叫paxos。城邦里有3类人，

• 决策者
• 提议者
• 群众

虽然这是一个黑暗的城邦可是很民主，按照议会民主制的政治模式制订法律，群众有什么建议和意见均可以写提案交给提议者，提议者会把提案交给决策者来决策，决策者有奇数个，为何要奇数个？很简单由于决策的方式很无脑，少数服从多数。最后决策者把刚出炉的决策昭告天下，群众得知决策结果。

等一下，那哪里黑暗呢？问题就出在“提议者会把提案交给决策者来决策”，那么多提案决策者先决策谁的？谁给的钱多就决策谁的。

那这样会有几个问题，决策者那么多，怎么保证最后决策的是同一个提案，以及怎么保证拿到全部提议者中最高的报价。

聪明又贪婪的决策者想到了一个办法：分两阶段报价

第一阶段

1. 决策者接受全部比他当前持有报价高的报价，且不会通知以前报价的人
2. 提议者给全部决策者报价，如有人比本身报价高就加价，有半数以上决策者接受本身报价就中止报价。

第一阶段结束的状态

每一个提议者都以为有半数以上的大佬接受了本身的提案，很开心。而决策者集团此刻的状态是一致的，半数以上赞成的提案只有一个，这个就是报价最高的（由于高的老是能够覆盖低的），具体是谁提的who care，一致就行。

第二阶段

提议者去找收过本身钱的大佬签合同，这里有3种状况：

1. 大佬都收了别人更高的价，回去拿钱继续贿赂，回到第一阶段从新升级;
2. 大佬收到的最高报价是本身的，美滋滋，半数以上成功签合同，提案成功;
3. 提议者回去拿钱回来继续贿赂的时候发现合同已经被签了且半数以上都签了这个提案，不干了，赶快把本身的提案换成已经签了的提案，再去提给全部大佬，看看能不能分一杯羹碰见还没签的大佬。

第二阶段结束的状态

全部提议者手头的提案都是同样的，由于有“赶快把本身的提案换成已经签了的提案”这一步;决策者集团全部成员最终接受的提案是同样的。

好的目的已经达到了，把这个提案昭告天下，让全部群众知道这件事。

故事说完了，用正确的姿式再简单介绍下paxos

分布式系统中的节点通讯存在两种模型：共享内存（Shared memory）和消息传递（Messages passing）。

paxos做为基于消息传递通讯模型的分布式系统，不可避免的会发生如下错误：进程可能会慢、被杀死或者重启，消息可能会延迟、丢失、重复，在基础 Paxos 场景中，先不考虑可能出现消息篡改即拜占庭错误的状况。

Paxos算法解决的问题是在一个可能发生上述异常的分布式系统中如何就某个值达成一致，保证不论发生以上任何异常，都不会破坏决议的一致性。一个典型的场景是，在一个分布式数据库系统中，若是各节点的初始状态一致，每一个节点都执行相同的操做序列，那么他们最后能获得一个一致的状态。

为保证每一个节点执行相同的命令序列，须要在每一条指令上执行一个“一致性算法”以保证每一个节点看到的指令一致。一个通用的一致性算法能够应用在许多场景中，是分布式计算中的重要问题。

Paxos用于解决分布式系统中一致性问题，在一个Paxos过程只批准一个value，只有被prepare的value且被多数Acceptor接受才能被批准，被批准的value才能被learner。在paxos算法中，分为4种角色：

• Acceptor：决策者
• Proposer ：提议者
• Client：产生议题者（群众）
• Learner：最终决策学习者（群众）

阶段一：

1. Proposer向半数以上的Acceptor发送Prepare请求并附上编号N。
2. 若Acceptor收到一个编号为N的Prepare请求，且N大于该Acceptor已经响应过的全部Prepare请求的编号，那么它就会将它已经接受过的编号最大的提案（若是有的话）做为响应反馈给Proposer，同时该Acceptor承诺再也不接受任何编号小于N的提案。
3. Proposer若没有获得半数以上Acceptor的响应，则编号+1继续发起请求。

阶段二：

1. 若是Proposer收到半数以上Acceptor对其发出的编号为N的Prepare请求的响应，那么它就会发送一个[N,提案]Accept请求给半数以上的Acceptor。
2. 若是Acceptor收到一个针对编号为N的提案的Accept请求，只要该Acceptor没有对编号大于N的Prepare请求作出过响应，它就接受该提案

看故事的时候不知道你们有没有疑问，我是有的。

决策者Acceptor为何要多个？

若只有一个acceptor多个proposer，acceptor能够选任意一个提案，很美好，可是有单点问题。

为何要用“半数以上经过”这个办法来决策？

一个集合不可能同时存在两个半数以上的子集，过半的思想保证提交的value在同一时刻在分布式系统中是惟一的一致的。这种提交方式无论proposer接受到的消息是接受了谁的提议过半，只保证是有提议过半了的。而后再在第二阶段肯定这个过半了的提议，让全部节点知道这件事。所以算法若是能保证value被半数acceptor接受，则意味这此时被认定的value是惟一的。

为何acceptor要接受多个提案？

若是acceptor只可以接受一个提案，则可能发生全部proposer提出的提案都没法达到多数，决策者接收一个就结束了，状态没法一致。

当Proposer有不少个的时候，会有什么问题？

很难有一个proposer收到半数以上的回复，进而不断地执行第一阶段的协议，决策收敛速度慢，好久都不能作出一个决策。

提案为何要带上编号（即故事中用来贿赂的钱）？

带上编号是为了决策者能够在自身接受到的提案的对比中作出最终的惟一决策。

试想若是按照提案到达时间对比提案，且不说这样就变成了只接收一个第一到达的提案，还可能由于网络缘由每一个决策者接受到的提案的前后顺序不同，凉凉。

接着上面的问题，那若是把全部决策者收到的提案聚集起来选出个时间最先的呢？

把提案聚集，这时候确定须要一个master来作判断，你们有没发现这个master好像就变成了propser，它拿到最先的提案，交给决策者...
其实，这就演变成了paxos的变种协议。

后记

为了不竞争，加快收敛的速度，有人在算法中加入leader来代替propser，且leader在集群中只有一位，也就是说只有leader有权提议。这时leader会有单点问题，因而又加入了leader选举机制保证健壮性，到目前为止paxos演变的愈来愈像我下一篇要讲的zab协议了。

为了能讲得更通俗，不少地方讲得不够严谨，见谅，有问题能够提出交流。

其实这篇和zookeeper的关系不太大算是讲zab以前作的一个铺垫吧。