31 | 分布式共识（上）：想用好分布式框架，先学会Paxos算法吧

周志明

你好，我是周志明。从这节课起，我会用两讲带你学习分布式共识算法。
可靠与可用、共识与一致在正式开始探讨分布式环境面临的各种技术问题和解决方案之前，我们先把目光从工业界转到学术界，学习两三种具有代表性的分布式共识算法，为后续分布式环境中操作共享数据打好理论基础。
我们先从一个最简单、最常见的场景开始：如果你有一份很重要的数据，要确保它长期存储在电脑上不会丢失，你会怎么做？
这不是什么脑筋急转弯的古怪问题，答案就是去买几块磁盘，把数据在不同磁盘上多备份几个副本。
假设一块磁盘每年损坏的概率是 5%，那把文件复制到另一块磁盘上备份后，数据丢失的概率就变成了 0.25%（两块磁盘同时损坏才会导致数据丢失）。以此类推，使用三块磁盘存储数据丢失的概率就是 0.00125%，使用四块则是 0.0000625%。换句话说，使用四块磁盘来保存同一份数据，就已经保证了这份数据在一年内有超过 99.9999% 的概率是安全可靠的。
那对应到软件系统里，保障系统可靠性的方法，与拿几个磁盘备份并没有什么本质区别。
单个节点的系统宕机导致无法访问数据的原因可能有很多，比如程序运行出错、硬件损坏、网络分区、电源故障，等等，一年中出现系统宕机的概率也许比 5% 还要大。这就决定了软件系统也必须有多台机器能够拥有一致的数据副本，才有可能对外提供可靠的服务。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

Paxos算法是解决分布式系统中共识问题的重要算法。文章通过幽默的方式介绍了Paxos算法的发展历程，并以实际案例和图示详细解释了算法的工作流程。该算法通过处理不可靠的节点通讯和并发操作的共享数据问题，确保系统能够达成一致意见。在一个例子中，作者讨论了正常通讯的场景，以及可能发生的四种情况。文章指出，尽管Paxos算法以复杂著称，但基于Basic Paxos的理解对于大多数技术人员来说并不困难。然而，Basic Paxos算法存在一些缺陷，不适合直接用于实践。因此，实际的应用更多基于Multi Paxos和Fast Paxos算法。总的来说，文章生动地展现了Paxos算法的发展历程和技术特点，为读者提供了对分布式共识算法的初步认识。

该试读文章来自《周志明的软件架构课》，如需阅读全部文章，
请先领取课程

免费领取

登录后留言

全部留言(23)

最新
精选

刘智恒
读完文章以后对Basic Paxos有一个疑惑：是不是在这个共识算法中，一旦一个值被确定就无法更改了？如果希望更改这个值应该怎么办呢？关于文中的这句话：“在分布式环境下，如果说各个节点“就某个值（提案）达成一致”，代表的意思就是“不存在某个时刻有一个值为 A，另一个时刻这个值又为 B 的情景”。”表达的意思是这个值只能被设定一次并且不可更改吗？
作者回复: 在文中提到过：“这里的“设置值”不要类比成程序中变量赋值操作，应该类比成日志记录操作” （大多数）数据库是基于日志来运作的，日志就是典型的不会变更的追加写入形式，但这并不影响数据表中的数据可以INSERT、UPDATE、DELETE呀。
2021-01-29
6
21
青鸟飞鱼
老师你好，一直有个疑惑，希望可以解答。 1.主从复制（全同步复制，半同步复制，异步复制）和共识算法，为什么推荐的都是共识算法，我想到的是主从复制没有选主机制。是否正确呢？ 2.分布式事务（2PC，3PC，TCC等），抛开数据一致性问题外，网络通信是另一个问题，那为什么共识算法也是多次通信，却受大家喜爱呢？
作者回复: 全同步保证所有节点一致，但完全牺牲了可用性。异步复制性能好，但必须以忍受一致性风险为代价。现在所说的共识算法是保证集群整体上对同一个值只有一种状态。它们各有用处，根据使用场景而定，并没有“都推荐共识算法”或者“受大家喜爱”的说法，共识算法被讨论得更多，这我觉得是潮流、热点等方面的因素。另外，这和是否有有选主也没有太多关系，basic paxos不也没有选主吗。
2021-01-27
2
8
robert_z_zhang
老师好，有个疑问，根据本文的例子，我的理解是两个并发操作，分别将值改为X和Y的并发操作，是保证操作的顺序性，但是例子中共识处理之后，只对一个操作达成了共识，另一个赋值操作被放弃
作者回复: 是的，让集群中的节点对值是X还是Y达成一致的共识，是X，就不会是Y；是Y，就不会是X。
2021-03-25

4
永昌
在分布式环境下，如果说各个节点“就某个值（提案）达成一致”，代表的意思就是“不存在某个时刻有一个值为 A，另一个时刻这个值又为 B 的情景”。 --这个说法是否用问题？我理解应该是各个节点在某个时刻，这个值都是相同的，至少在外部的请求看来是相同的
作者回复: 这句话的意思已经包含了“外部的请求看来是相同的”。某个值一旦在集群中达成一致，就意味着在任何时间、访问集群任何节点，都会得到相同的结果。
2021-04-09

3
test
如果在P阶段遇到比自己大的P则需要重新生成新的P，如果在P阶段遇到比自己大的A则接受A的值作为value广播。
2021-01-29

4
鱼
“Prepare 请求中会附带一个全局唯一的数字 n 作为提案 ID”，这个全局ID，实际上就来自于作者之前的论文，Lamport时间戳。
2022-07-26

3
zhanyd
假设提案节点为p1，p2，P1的提案id为1，p2的提案id为2 决策节点为a1，a2，a3，a4，a5 p1想赋值v=1，p2想赋值v=2 p1和p2谁也不服谁，那就让决策节点做决定吧，只有至少争取到3个决策节点的支持，才能获胜。第一回合 p1和p2一起给a1发起了提案。 p1的提案先到了a1这里： p1: a1你好啊，我要改变v的值，你看行不行？ a1: 没问题，你是第一个来改变v的值的人，你自己设个值就行。 p1: 好的，那就把v的值设成1吧。这时p2的提案才到： p2: a1你好啊，我要改变v的值，你看行不行？ a1: 不行啊，我已经接受了p1的提案，把v的值设成1了，你不能改了。第一回合p1获得了a1的支持，把v设成了1 第二回合 p1和p2一起给a2发起了提案。 p1的提案先到了a2这里： p1: a2你好啊，我要改变v的值，你看行不行？ a2: 没问题，你是第一个来改变v的值的人，你自己设个值就行。这时p2的提案赶到： p2: a2你好啊，我要改变v的值，你看行不行？ a2: 刚才p1已经来过了，不过你的提案id比p1的大，你优先级比他高，我就先设你的值吧。这时p1的回复到达： p1: 我来啦，我要把v的值设成1。 a2: 不好意思，刚才p2来了，他的提案id比你的高，我答应设他提供的值了。最后，p2的回复到达： p2: 我要把v的值设成2。第二回合p2获得了a2的支持，把v设成了2 第三回合 p1和p2一起给a3发起了提案。这次终于轮到p2的提案，先到了a3这里： p2: a3你好啊，我要改变v的值，你看行不行？ a3: 没问题，你是第一个来改变v的值的人，你自己设个值就行。这时p1的提案赶到： p2: a2你好啊，我要改变v的值，你看行不行？ a2: 刚才p2已经来过了，你的提案id比p2的小，我不能答应你。这时p2的回复到达： p2: 我来啦，我要把v的值设成2。第三回合p2获得了a3的支持，把v设成了2 第四回合a4把v设成了1，第五回合a5把v设成了2。 a1,a4支持把v设成1，a2,a3,a5支持把v设成2，根据少数服从多数原则，最后决定v的值为2，广播给所有节点知道，大家都统一把v的值设成了2。
2021-01-28
1
3
大俊stan
老师您好，今天正在学习paxos算法，但是对您所说的情况1有点不了解。我是看了分布式协议与算法实战这个专栏再来看您·的这篇文章。s3返回promise为【3.1，X】,S5在准备阶段发出的值是【4.5】 4 > 3因此不会接受promise中的值而是发送【4.5，y】因此在情况一中确实在s5准备阶段之前的共识是X，经过新一轮的提案，最新的值是Y.您看下对不对。
2022-02-08

1
rational
还是有一点不理解，比如将变量设置为X，所有节点达成共识之后，新的请求想将其设置为Y，但是由于promise会返回X，所以新的prepare只能发送X，那岂不是说一旦设定，就无法修改？周老师上面说到了要按照日志的思路来理解这个值，那对于上述这种情形将变量从X变为Y，应该是什么日志呢？对于初始值设定为X，可以是一条这样的日志（1,null,X），从X变成Y，是不是（2,X,Y）这样的日志呢，如果是这样的话，提案者如何根据上次的值为X这个事实，构造出（2,X,Y）这样的日志呢？
2021-07-02
4
1
Vincet
- 最终每次提案会在所有节点都执行一遍 - 执行完准备阶段也必然要执行批准阶段 - 不接受的意思并不是拒绝请求，而只是不改变决策节点的内部状态 - 决策节点最终状态是一致的 - 本质上讲是把分布式的问题分解成为每个决策节点单独运算问题，然后提案节点在进行统筹 - 可以自己写一段演示代码玩玩就很清楚了，只是要知其所以然很难
2021-02-01

1

收起评论