共识算法Paxos

1. 背景

  Paxos算法是Lamport宗师提出的一种基于消息传递的分布式一致性算法，使其获得2013年图灵奖。
  Paxos由Lamport于1998年在《The Part-Time Parliament》论文中首次公开，最初的描述使用希腊的一个小岛Paxos作为比喻，描述了Paxos小岛中通过决议的流程，并以此命名这个算法，但是这个描述理解起来比较有挑战性。后来在2001年，Lamport觉得同行不能理解他的幽默感，于是重新发表了朴实的算法描述版本《Paxos Made Simple》。
  自Paxos问世以来就持续垄断了分布式一致性算法，Paxos这个名词几乎等同于分布式一致性。Google的很多大型分布式系统都采用了Paxos算法来解决分布式一致性问题，如Chubby、Megastore以及Spanner等。开源的ZooKeeper，以及MySQL 5.7推出的用来取代传统的主从复制的MySQL Group Replication等纷纷采用Paxos算法解决分布式一致性问题。

备注：

• Paxos算法国内很多都翻译为一致性算法，从原理看个人认为是共识算法更准确。暂不纠结“一致性算法”、“共识算法”表述，理解意思，后续在研究。
• 《Paxos Made Simple》 译文《共识算法论文——Paxos Made Simple》

2. 学习心得

  第一次学习paxos算法是在《极客时间——分布式协议与算法实战》专栏，反复看了多遍专栏中paxos算法，里面介绍的案例推算过程已经明了。当回过头再看paxos算法的时候，发现很多问题从专栏中介绍的案例中都无法解答，甚至对专栏中介绍的例子需要解决的问题产生了疑问——到底需要解决什么问题。剩下的问题还有：1.怎样容错；2.服务各种故障之后怎样保证算法的正确性等等。
  之后在网上查看了多篇介绍Paxos算法的博客，大多都是通过例子来说明，没有得到我需要的答案。后面找到了Lamport的论文《Paxos Made Simple》然后回过头再看专栏，专栏中的Paxos算法例子需要解决的问题是——在集群中给个各节点创建达成共识的只读变量。容错问题作者在文中有指明但没有展开说明其中关键词是“大多数”。
  专栏中作者是围绕一个案例来介绍，例子不难理解，但不容易理解这样做的深层次的原理。如果之前没有看过这个专栏或者共识算法介绍，直接看Lamport的论文《Paxos Made Simple》，也是很难理解的。比较好的方法是，先看专栏再看论文，看完论文之后再回过来分析专栏中的示例。接下来介绍专栏中作者的例子。

  关于前面学习了多遍专栏，对专栏中示例需要解决的问题产生疑问的思考。1.阅读一遍和阅读多遍，认知上是不一样的；2.有先入为主的因素，纠正先入为主的观念也是这次一个收获。

3 Paxos Made Simple 概念回顾

  在一些经典的算法中，你会看到一些既形象又独有的概念（比如二阶段提交协议中的协调者），Basic Paxos 算法也不例外。在《共识算法论文——Paxos Made Simple》中有介绍兰伯特提出的概念：

• value：提案值，是一个抽象的概念，这里不能把它简单的理解为数值。而应该理解为对某一数据或数据库某一行的某一列的一系列操作。
• number：提案编号，全局唯一，单调递增。
• proposal：集群需要达成共识的提案，拥有 number 和 value。

proposal 中的 value 就是在 Paxos 算法完成之后需要达成共识的值。

Paxos 算法中有三个核心角色：

• Proposer：生成提案编号 n 和 value v，然后向 Acceptors 广播该提案，接收 Acceptors 的回复，如果有超过半数的 Accept