简介
Paxos算法简单来说就是一个在异步分布式系统里用以保证一致性的投票算法，严格来说，Paxos并不是一个算法，而是一个经过严谨逻辑推导出的投票方式。该算法由莱斯利·兰伯特于1990年提出，只由一些必须要被满足的基本条件推导得出，因此Paxos是在所有分布式算法中最简单，同时也是最稳定的算法。
Paxos应用于“基于消息传递且要求具有高度容错特性”的场景，在“共享内存”的分布式场景中并不适用，另外，虽然有许多基于Paxos的一致性算法，但都没有paxos稳定。
谷歌在其分布式锁服务（Chubby lock）中应用了Paxos算法。Yahoo!开源的ZooKeeper是一个开源的类Paxos实现，而hadoop也支持ZooKeeper协议。
这个世界上只有一种一致性算法，那就是Paxos，其它的算法都是残次品 – Mike Burrows
算法假设
1.不存在拜占庭将军问题（一条消息可能被传递两次，但在传递中不会出错） 2.只要等待足够的时间，消息就会被传到(信息必定到达） 3.每个节点对于信息，接收到信息即以为赞同，同时只有接受和忽略，没有反对。（只可根据赞成数来确定结果） 4.信息不一定会被成功传递，也无法确定传递时间。（包容传递失败，并确定在此条件下也能保持一致性） ##算法定义 在一个分布式系统中，每个节点会有最少1种，最多3种身份，分别是proposers（提案者）、acceptors（批准者）、learners（接受者），他们在节点中相互传递信息被称为value（决议）。 1.决议只能被提案者提出，同时随决议附有一个编号，编号是递增且唯一的； 2.任何两个提案编号之间构成偏序（意味着提案者的编号大小是有意义的；同一次提案，提案者的权限是有等级分别的）； 3.在一次算法执行中，每个批准者一次只批准一条决议，并且只与最新的决议形成交互（意味着可能存在信息队列）； 4.收到超过半数的表态，即视为通过决议，并向所有人广播； 5.接受者只能获得最终被批准的决议。 需要注意的是，节点可以同时拥有三种身份，当节点既是提案者，又是批准者时，他必定会为自己提出的决议投出一票。
实例
东方网准备开一场主题为“智橙生活未来发展方向”的会议，与会人员分别是董事长何XX、副董事长徐XX、纪委书记金X、副总裁高X、技术总监老王。与会人员都可以提案和赞同，一人一票。其他未与会人员例如开发、产品、数据分析师等，只能接受讨论结果（定义5）。
第一天：董事长提案智橙生活应该主打“上海市民离不开的产品”，其他4人纷纷表示“赞同”，董事长收到其他4人的表态，开心的表示全票通过，向所有人广播“产品基调定好，新的提案不得再讨论本问题”，全场统一。
第二天：董事长提案智橙生活应该添加“为民办事”功能，老王不能装作听不见，只好表示“赞同”（假设3），副总裁和纪委书记睡着了，无法表态，董事长等了半天只等到了两个表态，表示少两人老子照样干，加上自己一票通过了决议（定义4），向所有人广播“功能确定，新的提案不得再讨论本问题”，全场统一。
第三天：副总裁和纪委书记睡醒了，发现了董事长的提案，但同时（或更早）收到了提案结果的广播，于是他们不必再对此提案表态，全场统一。
第四天：轮到老王提案，他提出了“打磨产品，塑造核心功能点”的主旨，这时其他4位领导都睡着了，老王未获得任何表态。决议失败，不能向任何人广播。只能重新提案，全场统一。
第五天：4位领导终于都醒了，这时董事长提出了“尽可能多的造功能，我们要做一款万能APP”的主旨，老王再次提出昨天的提案，其他三位领导先听见了董事长的训示，纷纷表态支持，这时才反应过来老王有一份同样的提案，这时有两种情况：
老王职级低：其他领导表态后收到了老王的提案并发现是相同的提案（定义3），但老王的职级比他们的低，因此会忽略老王的提案，全场统一。
老王职级高：其他领导表态后收到了老王的提案并发现是相同的提案（定义3），他们会向老王回复之前已经通过了的提案及其内容并忽略投票，这样老王会知道自己的提案无望，全场统一。
第六天：董事长和老王同时说出对一件事的提案，并且获得邻座（近邻节点）的迅速反馈，此时老王邻座的副总裁和纪委书记先向老王表态“赞同”，当董事长的提案到来时，他们会再次表示“赞同”。而副董事长先向董事长的提案表示“赞同”后，收到了老王的提案，此时他将向老王表示“已有大人物关注此事，你不要插手”（定义2）。当信息传递结束，高权限必定获得更高的“赞同”，提案通过，全场统一。
第七天：老王总结出了深刻的人生哲理：在异步的任何情况下，即使某一节点出于某些原因无法接受信息，也绝不影响该节点以及总体对于一致性的检测，并且为了保证异步一致，权限相对较低的节点在提案和投票中处于较不利的位置。