协议由来
是一个叫莱斯利.兰伯特的牛人提出的一种基于消息传递且具有高度容错特性的一致性算法，是目前公认的的解决分布式一致性问题最有效的算法之一。
很多人都会认为zookeeper就是paxos算法的实现，但实际上，zookeeper并没有完全采用Paxos算法，而是采用一种zab（zookeeper atomic broadcast）的协议作为其数据一致性的和核心算法。
算法推导
是分布式一致性算法，用于解决一个分布式系统如何就某个值达成一致的问题。
允许消息重复，丢失、但是不允许被修改
在结点数少于半数失效的情况下仍然能正常的工作，结点失效可以在任何时候发生而不影响算法正常执行
Paxos算法包含三个角色Proposor（提议者），Acceptor（接受者），Learner（领导者）。
实现的时候采用一组固定数目Server，每个Server同时担任上述三个角色，多个Client将自己的请求值Value_i随机发给一个Server处理，然后这一组Server经过协商后得出统一的一个值Chosen_Value，这个值必须被每个Server学习到，同时回复给所有发起请求的Client。
算法详解
阶段1a,prepare(准备)阶段，预定proposal（提议）序号
每个提议者（proposor）拿到某个client的请求value_i后，此阶段还不能发起proposal，只能发送一个proposal序号N，将序号发送给所有的acceptor（接受者），所有的server包括自己
整个系统中所有proposal的序号不能重复且每个proposor自己用到的序号必须递增，通常的做法是，假如k台server协同运行paxos算法，那么server_i(i=0..k-1)用到proposal虚化初始化为i，以后每次要产生新序号时递增k，这样保证所有的server的proposal序号不重复
阶段1b,回应承诺阶段
每个acceptor收到proposal序号后，先检查之前是否Repond序号更高的proposal，若没有，那么就给出response，这个response带有自己的已经accept的序号最高的proposal（若还没accept任何proposal，回复null），同时，promise（承诺）自己不再accept低于接收序号的proposal，否则，拒绝respond。
阶段2a---发起Proposal，请求Accept
Proposal如果得到了来自果树的acceptor的response，那么久有资格向acceptor发起proposal<N,value>。其中n是阶段1a中发起的序号，value是收到的response中序号最大的proposal的value，若收到的response全部是null，那么value自定义，可以直接选一个client请求的value_i
阶段2b--Accept Proposal
检查收到的Proposal的序号是否违反阶段1b的Promise，若不违反，则Accept收到的Proposal。
流程图
举个栗子🌰
有5个家庭成员发起提案去什么旅游，
case 1，
- 议员1说，去日本，这时候 1 发给 2、3、4、5，别人没有提案，这时候方案通过，完美
case 2
议员1 说 日本 发给2、3
同时 议员5 欧洲 发给3、4
这时候 1、2、3 收到1 的议案
3、4、5 收到5的议案
那么具体选择是3决定，
结果：
* 按照时间的先后，假设先收到1的提案 那么3就选择1 通知 4、5，1的议案（去日本）被同意，你们更改就行
* 如果按照家庭成员的话语权（这个不太恰当），假设 5的比1大，则选择5
