写一写关于Paxos和我的理解

这个文章是一年前看Paxos的时候自己的一些笔记和思考。有些翻译自wiki和原论文Paxos Made Simple，也有一部分是参考网上能找到并且觉得很棒的博客。文末都贴出了参考出处。

除了这篇还计划着写几篇，包括Paxos具体实现。
才疏学浅，如果觉得文
章有什么问题欢迎留言讨论。

一 相关概念

1.paxos协议是用来解决什么问题的

paxos协议是用来解决网络中不可靠服务进程之间的共识问题（consensus），解决共识问题的目的在于使整个系统中的进程达成一致（consistent）
（前面说的说的不可靠是指服务中的任何一个进程都有可能失败）

2.关于Consensus（共识）

（参考Consensus wiki）
共识问题需要在多个进程（或代理）之间就单个数据值达成一致。（The consensus problem requires agreement among a number of processes (or agents) for a single data value）
要实现一个具有容错共识协议需要满足下面三个条件：

• 最终 ，每个正常的进程必须确定一个决议。（Termination：Eventually, every correct process decides some value.）
• 如果所有正常的进程提出了同一个决议v,那么任何一个正常的进程都应该对该决议做出决策(Integrity: If all the correct processes proposed the same value v, then any correct process must decide v.)
• 所有正常的进程接受的决议必须是同一个（Agreement：Every correct process must agree on the same value）
  上面的几点都来自wiki, consensus
  但是个人觉得第二点翻译出来怪怪的
  参考了一下下面PPT中的一些，此外还应该参考下属PPT中的

2.paxos协议的一些假定

（参考Paxos wiki）
（也即，我们在考虑paxos协议的时候需要关注的问题，以及可以忽略的一些问题）

服务进程

• 服务进程以任意速度运行。
• 服务进程可能会遇到故障。
• 具有稳定存储的服务进程可能在故障之后重新加入协议（在崩溃恢复故障模型之后）。
• 服务进程不会串通，欺骗或以其他方式试图破坏协议。（也就是说，拜占庭故障不会发生）

网络

• 服务进程可以向任何其他进程发送消息。
• 消息以异步方式发送，可能需要很长时间才能完成。
• 消息可能会丢失，重新排序或重复。
• 消息传递没有损坏（也就是说，不会发生拜占庭式的失败）

服务进程的数量

非故障进程的数量必须严格大于错误进程的数量（Quorums）。对于服务进程数为n=2F+1的系统中，如果错误进程数不超过F，那么就可以继续使用该协议

由于存在上面的条件约束，因此在Paxos实现的时候就需要考虑到多个方面：异步通信，故障恢复。

3.paxos中的角色和概念

• Proposer
• Acceptor
• Learner
  （直接参考下图就行,图片来源在文末PDF连接）
  

在一个服务中，同一个进程在不同时间段可能是上述三个角色中任何一个

Proposal Value：提议的值；
Proposal Number：提议编号，可理解为提议版本号，要求全局不能冲突；

一个提案proposal一般是由（ProposalValue，ProposalNumber)组成

4. paxos的安全性（safety ，或者说一致性consistency）

（参考论文原文）
为了保证一致性（个人还是觉得用一致性这个词比较直观），Paxos定义了三个属性并确保始终保持它们：

• 约束1：只有value被提出后才可能被选定chosen，
• 约束2：只有一个value被选定chosen，并且
• 约束3：process永远不会获知一个value被选择了，除非这个valu确实已经被选定chosen。（进程只会获知到已经确认被选定（Chosen）的值）

二 Basic Paxos

上面的一个大节里面已经描述了在多个网络进程组成的系统中，各进程之间为了达成共识需要满足的条件，进一步描述了paxos协议中为了保证一致性（或安全性）做出了哪些基本要求。此外还提及了整个决策过程中可能遇到的问题。
Paxos协议要解决的问题是什么？
上面的约束中最重要的是约束2，Paxos要达到的目的也就是快速的选定一个value，并且保证这个value被选定之后就不再改变。

1.1 算法的提出

上面paxos的安全性一节中提出的三个属性是最基本的约束了，在复杂的环境中，上述约束说起来简单，但是要做到却很难，所以作者通过不断加强上述3个约束（主要是第二个）获得了 Paxos 算法：
其中约束2是最重要的，在一个异步并发通信的环境中，如何保证约束2呢？
一个acceptor接受多个proposal应该有怎么样的行为？
多个proposer异步发送到多个acceptor上？
（画图说明）
单点问题？
最简单的方法就是用单个acceptor代理。Proposer发送议案（proposal）给这个acceptor，它选择最先收到的议案。尽管简单，但是如果acceptor停机了，那么系统就不能继续运行了，这个方案并不能满足要求。【明显的单点问题】
看来我们需要选择另外的方法，我们用多个acceptor代理，而非一个，proposer向一组acceptor提出议案。一个acceptor可能接受accept该议案，当有足够大的acceptor集合批准了这个议案时，决议【议案是一个{编号，决议}对】就被选择了。那么这个集合多大才足够呢？为了保证只有一个决议被选择，我们可以让这个集合包含多数的代理【后面也会称之为多数派】。因为任意两个多数派至少有一个相同的代理，如果一个acceptor最多只能接受accept一个决议，这就是可行的。
假设没有失败或者消息丢失，即使仅有一个proposer提出了一个决议，我们也希望能选择一个决议。这就导出了下面的需求

如何保证只有一个决议被选择（约束2）呢？
首先，即使仅有一个proposer提出了一个决议，我们也希望能选定一个决议。这就导出了下面的需求：
P1：一个 acceptor 必须接受（accept）第一次收到的提案。
（但是P1 是不完备的。如果恰好一半 acceptor 接受的提案具有 value A，另一半接受的提案具有 value B，那么就无法形成多数派，无法批准任何一个 value。因此还需对P1加强）

如果一个议案{n, v}被大多数（majority）的接受accept，那么决议v就被批准chosen。这种情况下，我们称议案（包括其决议v）被批准了。
我们允许选择多个议案，但是必须保证所有选择的议案包括相同的决议。对议案编号归纳，可以保证
（因为约束2并不要求只选定chosen一个提案proposal，它只是要求只批准一个value，这就暗示可以存在多个提案。只要提案的 value 是一样的，批准多个提案不违背约束2。）

P2：一旦一个具有 value v 的提案被选定（chosen），那么之后选定（chosen）的提案必须具有 value v。
如果 P1 和 P2 都能够保证，那么约束2就能够保证。（不论多少个proposal{value,number}被选定，最终都只是具有相同value的）

选定一个 value 意味着多个 acceptor 接受（accept）了该 value。因此，可以对 P2 进行加强：

P2a：一旦一个具有 value v 的提案被选定（chosen），那么之后任何 acceptor 再次接受（accept）的提案必须具有 value v。
由于通信是异步的，P2a 和 P1 会发生冲突。如果一个 value 被批准后，一个 proposer 和一个 acceptor 从休眠中苏醒，前者提出一个具有新的 value 的提案。根据 P1，后者应当接受，根据 P2a，则不应当接受，这种场景下 P2a 和 P1 有矛盾。于是需要换个思路，转而对 proposer 的行为进行约束：

P2b：一旦一个具有 value v 的提案被选定（chosen），那么以后任何 proposer 提出的提案必须具有 value v。
由于所有提案都是有proposer提出的，只要满足P2b,即proposer提出的提案都具有value v, 那么acceptor接受到的提案也就一定具有value v，因此可以说 P2b 蕴涵了 P2a，这也意味着其包含了p2,它是一个更强的约束。

上述P2b是一个很直观明了的约束条件了，但是根据 P2b 难以提出实现手段。因此需要进一步加强 P2b，找到一个便于实现的约束条件。
如果让你按照上面的约束写这个程序你能写出来吗？或许不能。考虑到具体实现的时候，我们一般步骤是：先提出proposal 再让acceptor去选定。但是上述几条约束p2 p2a p2b都是直接假定了提案已经被选定，因此不便于具体代码实现（他们的出发点都是基于已经存在一个被选定的提案，站在结果上面来做出约束）。我们需要的是一个关于提出proposal的约束条件。
假设一个编号为 m 的 value v 已经被选定（chosen），来看看在什么情况下对任何编号为 n（n>m）的提案都含有 value v。因为 m 已经被选定（chosen），显然存在一个 acceptors 的多数派 C，他们都接受（accept）了v。考虑到任何多数派都和 C 具有至少一个公共成员，可以找到一个蕴涵 P2b 的约束 P2c：

P2c：如果一个编号为 n 的提案具有 value v，那么存在一个多数派S，要么S中所有人都没有接受过（accept）编号小于 n 的任何提案，要么S中所有人已经接受过（accept）的所有编号小于 n 的提案中编号最大的那个提案的value都是v。
换句话说就是，如果存在一个编号为 n 的提案具有 value v，那么只能存在以下两种情况：

• 编号小于n的任何提案都没有被S acceptor接受accept， （对应P1）
• 编号小于n的提案中，编号最大的那个提案已经被S acceptor接受的且其值为value v （对应p2b）

这里有点绕，建议参考论文原文来理解

for any v and n, if a proposal with value v and number n is issued,then there is a set S consisting of a majority of acceptors such that either (a) no acceptor in S has accepted any proposal numbered less than n, or (b) v is the value of the highest-numbered proposal among all proposals numbered less than n accepted by the acceptors in S.

满足P2c就能满足P2b,
为了满足P2c（即只出现上述两种情况），那么需要我们在准备提出一个编号为n的提案之前，都要跟acceptor进行通信，来获知大多数acceptor是否通过了一个编号小于n的提案，如果通过了那么这个提案的编号和value是多少。
这就引出了两阶段提交：

• prepare阶段：（首先跟acceptor通信一下，获取一下提案情况。如果没有这个阶段的话，那么如果让proposer随便提出提案的话，那么很可能会违反p2c约束。）
• accept阶段：（根据刚上一得到的情况，来确定自己的行为）

1.2 总结

2.算法的实现

上面一节中一共两个约束，p1和p2,其中对p2做出多次加强得到了p2c，因此算法的实现就是围绕p1和p2c。而且从上面的各点约束来看，每个提案的编号应该是全局唯一且有序的。
上面一节中，P2c对proposer倒是做出了很强的约束了，但是对acceptor的约束只有p1：一个 acceptor 必须接受（accept）第一次收到的提案。
那么对一个accepter提交多个提案，acceptor应该如何应答呢？
假设存在这样一种情况一个proposer1和proposer2都已经跟大多数acceptor通信，并知道他们现在并未接受任何提案，此proposer1提出提案（n,v1), proposer2提出提案（n-1,v2)，且v1!=v2
（n,v1）先到达，被接受了，之后提案n-1到来，acceptor应该如何应答呢？如果acceptor接受了这个提案，那么就违反了p2c中的第二中情况。
因此在prepare过程中，acceptor进行的应答的同时也应包含承诺：不会再接受（accept）编号小于n的提案。这是对P1的加强：
P1a：当且仅当acceptor没有回应过编号大于n的prepare请求时，acceptor接受（accept）编号为n的提案。
那么也就是说，对于编号大于n的提案，在prepare阶段，acceptor仍然可以应答。

承诺：

那么再来考虑上面的情况
假设存在这样一种情况一个proposer1和proposer2都已经跟大多数acceptor通信，并知道他们现在并未接受任何提案，此proposer1提出提案（n,v1), proposer2提出提案（n+1,v2)，且v1!=v2
（n,v1）先到达，被接受了，之后提案n+1到来，acceptor应该如何应答呢？如果acceptor接受了这个提案，那么就违反了p2c中的第二中情况。

参考：
https://en.wikipedia.org/wiki/Paxos_(computer_science)
https://en.wikipedia.org/wiki/Consensus_(computer_science)
Paxos Made Simple 论文原文：https://lamport.azurewebsites.net/pubs/paxos-simple.pdf
挺棒的PPT: https://github.com/hedengcheng/tech/blob/master/distributed/PaxosRaft%20%E5%88%86%E5%B8%83%E5%BC%8F%E4%B8%80%E8%87%B4%E6%80%A7%E7%AE%97%E6%B3%95%E5%8E%9F%E7%90%86%E5%89%96%E6%9E%90%E5%8F%8A%E5%85%B6%E5%9C%A8%E5%AE%9E%E6%88%98%E4%B8%AD%E7%9A%84%E5%BA%94%E7%94%A8.pdf
知乎上的讨论：
https://www.zhihu.com/question/19787937