分布式系统理论进阶 - Paxos

引言

《分布式系统理论基础 - 一致性、2PC和3PC》一文介绍了一致性、达成一致性须要面临的各类问题以及2PC、3PC模型，Paxos协议在节点宕机恢复、消息无序或丢失、网络分化的场景下能保证决议的一致性，是被讨论最普遍的一致性协议。

 

Paxos协议同时又以其“艰深晦涩”著称，下面结合 Paxos Made Simple、The Part-Time Parliament 两篇论文，尝试经过Paxos推演、学习和了解Paxos协议。

 

Basic Paxos

何为一致性问题？简单而言，一致性问题是在节点宕机、消息无序等场景可能出现的状况下，相互独立的节点之间如何达成决议的问题，做为解决一致性问题的协议，Paxos的核心是节点间如何肯定并只肯定一个值(value)。

 

也许你会疑惑只肯定一个值能起什么做用，在Paxos协议里肯定并只肯定一个值是肯定多值的基础，如何肯定多值将在第二部分Multi Paxos中介绍，这部分咱们聚焦在“Paxos如何肯定并只肯定一个值”这一问题上。

 

和2PC相似，Paxos先把节点分红两类，发起提议(proposal)的一方为proposer，参与决议的一方为acceptor。假如只有一个proposer发起提议，而且节点不宕机、消息不丢包，那么acceptor作到如下这点就能够肯定一个值：

P1. 一个acceptor接受它收到的第一项提议

 

固然上面要求的前提条件有些严苛，节点不能宕机、消息不能丢包，还只能由一个proposer发起提议。咱们尝试放宽条件，假设多个proposer能够同时发起提议，又怎样才能作到肯定并只肯定一个值呢？

 

首先proposer和acceptor须要知足如下两个条件：

1. proposer发起的每项提议分别用一个ID标识，提议的组成所以变为(ID, value)

2. acceptor能够接受(accept)不止一项提议，当多数(quorum) acceptor接受一项提议时该提议被肯定(chosen)

(注: 注意以上“接受”和“肯定”的区别）

 

咱们约定后面发起的提议的ID比前面提议的ID大，并假设能够有多项提议被肯定，为作到肯定并只肯定一个值acceptor要作到如下这点：

P2. 若是一项值为v的提议被肯定，那么后续只肯定值为v的提议

(注: 乍看这个条件不太好理解，谨记目标是“肯定并只肯定一个值”)

 

因为一项提议被肯定(chosen)前必须先被多数派acceptor接受(accepted)，为实现P2，实质上acceptor须要作到：

P2a. 若是一项值为v的提议被肯定，那么acceptor后续只接受值为v的提议

知足P2a则P2成立 (P2a => P2)。

 

目前在多个proposer能够同时发起提议的状况下，知足P一、P2a即能作到肯定并只肯定一个值。若是再加上节点宕机恢复、消息丢包的考量呢？

 

假设acceptor c 宕机一段时间后恢复，c 宕机期间其余acceptor已经肯定了一项值为v的决议但c 由于宕机并不知晓；c 恢复后若是有proposer立刻发起一项值不是v的提议，因为条件P1，c 会接受该提议，这与P2a矛盾。为了不这样的状况出现，进一步地咱们对proposer做约束：

P2b. 若是一项值为v的提议被肯定，那么proposer后续只发起值为v的提议

知足P2b则P2a成立 (P2b => P2a => P2)。

 

P2b约束的是提议被肯定(chosen)后proposer的行为，咱们更关心提议被肯定前proposer应该怎么作：

P2c. 对于提议(n,v)，acceptor的多数派S中，若是存在acceptor最近一次(即ID值最大)接受的提议的值为v'，那么要求v = v'；不然v可为任意值

知足P2c则P2b成立 (P2c => P2b => P2a => P2)。

 

条件P2c是Basic Paxos的核心，光看P2c的描述可能会以为一头雾水，咱们经过 The Part-Time Parliament 中的例子加深理解：

 

假设有A~E 5个acceptor，- 表示acceptor因宕机等缘由缺席当次决议，x 表示acceptor不接受提议，o 表示接受提议；多数派acceptor接受提议后提议被肯定，以上表格对应的决议过程以下：

1. ID为2的提议最先提出，根据P2c其提议值可为任意值，这里假设为a
2. acceptor A/B/C/E 在以前的决议中没有接受(accept)任何提议，于是ID为5的提议的值也能够为任意值，这里假设为b
3. acceptor B/D/E，其中D曾接受ID为2的提议，根据P2c，该轮ID为14的提议的值必须与ID为2的提议的值相同，为a
4. acceptor A/C/D，其中D曾接受ID为2的提议、C曾接受ID为5的提议，相比之下ID 5较ID 2大，根据P2c，该轮ID为27的提议的值必须与ID为5的提议的值相同，为b；该轮决议被多数派acceptor接受，所以该轮决议得以肯定
5. acceptor B/C/D，3个acceptor以前都接受过提议，相比之下C、D曾接受的ID 27的ID号最大，该轮ID为29的提议的值必须与ID为27的提议的值相同，为b

 

以上提到的各项约束条件能够概括为3点，若是proposer/acceptor知足下面3点，那么在少数节点宕机、网络分化隔离的状况下，在“肯定并只肯定一个值”这件事情上能够保证一致性(consistency)：

• B1(ß): ß中每一轮决议都有惟一的ID标识
• B2(ß): 若是决议B被acceptor多数派接受，则肯定决议B
• B3(ß): 对于ß中的任意提议B(n,v)，acceptor的多数派中若是存在acceptor最近一次(即ID值最大)接受的提议的值为v'，那么要求v = v'；不然v可为任意值

(注: 希腊字母ß表示多轮决议的集合，字母B表示一轮决议)

 

另外为保证P2c，咱们对acceptor做两个要求：

1. 记录曾接受的ID最大的提议，因proposer须要问询该信息以决定提议值

2. 在回应提议ID为n的proposer本身曾接受过ID最大的提议时，acceptor同时保证(promise)再也不接受ID小于n的提议

 

至此，proposer/acceptor完成一轮决议可概括为prepare和accept两个阶段。prepare阶段proposer发起提议问询提议值、acceptor回应问询并进行promise；accept阶段完成决议，图示以下：

 

还有一个问题须要考量，假如proposer A发起ID为n的提议，在提议未完成前proposer B又发起ID为n+1的提议，在n+1提议未完成前proposer C又发起ID为n+2的提议…… 如此acceptor不能完成决议、造成活锁(livelock)，虽然这不影响一致性，但咱们通常不想让这样的状况发生。解决的方法是从proposer中选出一个leader，提议统一由leader发起。

 

最后咱们再引入一个新的角色：learner，learner依附于acceptor，用于习得已肯定的决议。以上决议过程都只要求acceptor多数派参与，而咱们但愿尽可能全部acceptor的状态一致。若是部分acceptor因宕机等缘由未知晓已肯定决议，宕机恢复后可经本机learner采用pull的方式从其余acceptor习得。

 

Multi Paxos

经过以上步骤分布式系统已经能肯定一个值，“只肯定一个值有什么用？这可解决不了我面临的问题。” 你心中可能有这样的疑问。

 

其实不断地进行“肯定一个值”的过程、再为每一个过程编上序号，就能获得具备全序关系(total order)的系列值，进而能应用在数据库副本存储等不少场景。咱们把单次“肯定一个值”的过程称为实例(instance)，它由proposer/acceptor/learner组成，下图说明了A/B/C三机上的实例：

不一样序号的实例之间互相不影响，A/B/C三机输入相同、过程实质等同于执行相同序列的状态机(state machine)指令 ，于是将获得一致的结果。

 

proposer leader在Multi Paxos中还有助于提高性能，常态下统一由leader发起提议，可节省prepare步骤(leader不用问询acceptor曾接受过的ID最大的提议、只有leader提议也不须要acceptor进行promise)直至发生leader宕机、从新选主。

 

小结

以上介绍了Paxos的推演过程、如何在Basic Paxos的基础上经过状态机构建Multi Paxos。Paxos协议比较“艰深晦涩”，但多读几遍论文通常能理解其内涵，更难的是如何将Paxos真正应用到工程实践。

 

微信后台开发同窗实现并开源了一套基于Paxos协议的多机状态拷贝类库PhxPaxos，PhxPaxos用于将单机服务扩展到多机，其通过线上系统验证并在一致性保证、性能等方面做了不少考量。

 

--

本文提到的一些概念包括一致性(consistency)、一致性系统模型(system model)、多数派(quorum)、全序关系(total order)等，在如下文章中有介绍 :)

《分布式系统理论基础 - 一致性、2PC和3PC》

《分布式系统理论基础 - 选举、多数派和租约》

《分布式系统理论基础 - 时间、时钟和事件顺序》

《分布式系统理论基础 - CAP》

--