Paxos-大白话理解

Posted 2021-04-17 数据库技术汇

基础Paxos

这次再复习一下分布式系统中的经典问题：Paxos，Paxos是分布式系统领域非常经典的协议，几乎已经成了共识的代名词。首先，我们先来看看分布式系统面临的问题，以及为什么需要一个一致的算法。

问题

在我们的经历中，也就是大概几年以前，一个常见的场景是：单独的一台Server发起客户端请求；另外一台Server按顺序执行请求并更新系统状态。

通常这是没问题的，但是当Server宕机时，服务就变得不可用了。 为了提高可用性和弹性，系统增加了越来越多的Server。 随着Server数目的不断增多，我们需要将整个系统看作一台Server来给用户服务。 这意味着分布式系统的行为应该和单机时代是一样的（从客户的角度来看），就好像只有一台Server存在一样。 

我们举一个简单的例子来理解它的含义。 比方有一个管理银行账户的服务器，有一个100美元的账户。然后客户存入了100美元，银行存款利息累计也在同一个帐户中。 如果这两个操作由两个不同的服务器同时处理，则系统结果（即账户余额）可能因服务器处理的操作顺序而产生差异： 

1. 如果客户存款首先达到200美元，那么5％的利息将按照200美元计算，最后余额为210美元

2. 如果5％的利息首先计算达到105美元，然后再加上100美元的存款，最后的余额是205美元

我们在这里观察到的是，为了确保所有服务器上的结果相同，服务器需要就处理顺序达成一致。 解决这个顺序问题是通过让服务器同意对于每个操作，服务器之间就执行顺序都必须达成一个共识。

Basic Paxos

接下来，我们将重点讨论一个单一共识的达成，也就是经典的Paxos。 然后，我们可以对一个命令序列，每一个命令执行一个Paxos实例，最终达成一系列共识。

名称

Paxos是一个希腊岛屿的名称，Paxos算法受到议会在这个岛上运行方式的启发，即基本的法案需要大部分人投票通过。 该算法依赖于相同的想法，即提出的议案必须被大多数人接受才能被选定。

角色

Paxos有三种角色：

1. 提议者：这些是提出新的提案并期望达成一致的人， 通常是处理客户端请求的服务器

2. 接受者：这些是投票或“接受”提案的人，同时也跟踪决策过程

3. 学习者：这些人是想知道哪个提案最终被选定的人

任何参与者都可以扮演一个或多个角色，工程实践中，通常是服务器扮演所有角色的情况。但是对于深入理解Paxos，建议还是把这些角色独立开来，有助于理解Paxos的本质。

假设

在每一轮中：

1. 一台或多台服务器提议一个值

2. 参与者同意一个单一的值

3. 只能选择一个值

4. 除非已被选中，参与者不会学习到一个值

系统也做了以下假设：

1. 没有拜占庭式的失败：服务器行为正确或完全失败，该算法不支持参与者的恶意行为

2. 系统最终是同步的（大多数消息已成功传递，丢失消息的数量是有限的）

规则

每一轮包括2（或3）个阶段：

1. “准备” 阶段：提议者检查接受者是否将为他的提案投票

2. “接受” 阶段：接受者对提案进行投票并“选择”一个值

3. 也可以包含一个“学习”阶段：学习者被告知该回合的结果（它不会影响选择值的方式，所以现在我们忽略这个阶段）

每个提案都有一个唯一的编号，较高的编号优先于较低的编号。为避免编号冲突，提案编号应包含某种服务器ID（例如<proposal＃>+<server id>）。

算法

提议者

提议者必须维护并持久化一个变量：最大提案编号。 其行为定义如下：

1.选择一个新的提案编号，提案者的最大提案编号

2.使用新的提案编号向所有接受者发送“准备”消息

3.当从大多数接受者那里收到答复时：

如果接收方收到接受的提案编号的答复且其中包含一个已经接受的值，则用接收到编号最大的值替换建议的值

4.用建议编号和值发送“接受”消息

5.当提议者收到多数派接受者的答复时：

1. 如果有拒绝（回复编号高于当前提案编号）,该值不能“选定”，因此提案人更新其最大提案编号，并从步骤1重新开始

2. 如果没有拒绝，则该值被“选定”

接受者

接受者必须维护三个变量：

1. 最小提案编号

2. 接受提案编号

3. 接受的价值

它的行为和提议者行为相对应：

1. 收到“准备”信息

• 如果收到的提案号码大于接受者最小提案值，则更新最小提案

• 然后用包含最高接受建议编号及其关联值（如果有）的消息回复

2.收到“接受”信息时：

• 如果提案编号大于或等于接受方的最小提案值，则更新其最小提案及其接受的提案编号和相关联的值，然后回复确定，最后回复一个包含最小提议值的消息

一个有趣的事实是只有提议者知道已经选定了一个值。接受者只知道它接受的值，但不知道是否多数人已经接受这个值，这就是为什么有一个额外的“学习”阶段，其中选定的值被派遣到“学习者”。

加戏：个人理解其实这个“学习”分为主动和被动两种情况，被动学习是多个接受者都可以把接受某个提案的消息广播给“学习者”，“学习者”自己计数判断一个提案是否已经被选定（超过多数派接受），从“学习者”的角度看，是一个被动的过程；主动学习，一般同在一个节点重启或者加入到已经存在集群的时候，其对齐已经被选定（有的Paxos实例可能已经关闭）实例时，一般都需要首先主动附带自己已知的Paxos实例编号，让其他节点可以批量将多余的决议同步给自己。

现在我们来证明这个算法保证只有一个值可以被选择。有三种情况需要考虑：

情况一：前一个值已经被选定 

从服务器5发起了第二个提案，（左下方的）第二个提案发起时，第一个提案已经被多数人选定，第二个提案在“准备”阶段获知已经被选定的值。然后用已经接受的值取代它的值，最终两个提案都被接受，具有相同的值。

情况二：前一个值已经被接受 

第一个提案已经被第三个服务器接受，第三个服务器不能接受第二个提案的值，第一个提案的值被选中。同样，第二个提议者发现先前的值已经被接受者之一所接受。这就是为什么它需要等待大多数人回应的原因。它保证至少有一个接受者看到任何以前的提案。

情况三：前一个值仅仅被提议

当第二个提案进入时，第一个提案尚未被多数人接受， 第一个提案建议最终被抛弃。这里没有任何值被接受，所以第二个提案会成功，第一个提案将会失败。最初的提议者将不得不再次尝试，结果将是第二个值。 这次只选择第二个值（第一个值被拒绝）。

这些都是可能的情况，所有的结果只是确定一个单一的值。还有另一个值得提及的情况，因为它对应于一个“活锁”，如下图所示。

当提议者不断发送新的提议而不让接受者接受任何提议时，可能会发生这种情况。 在发送新提案之前，可以随机延迟一段时间， 这个随机延迟给接受者一个接受一个值的机会，从而避免活锁的产生。