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