一致性协议Paxos详解（一）：Basic Paxos协议详解

前言
Paxos是什么
Paxos算法原理与推导
Basic Paxos
- Proposal Numbers
- prepare阶段
- - prepare阶段的意义
- Accept阶段
- paxos算法的关键特性
- - safety
  - liveness
- notes
- - Basic Paxos 只负责达成一个决议
  - 薛定谔的提案
- 与2pc的关系
参考链接

前言

有关一致性协议的资料网上有很多，当然错误也有很多。笔者在学习的过程中走了不少弯路。现在回过头来看，最好的学习资料就是Leslie Lamport和Diego Ongaro的数篇论文、Ongaro在youtube上发的三个视频讲解，以及何登成的ppt。

本系列文章是只是笔者在学习一致性协议过程中的摘抄和总结，有疏漏之处敬请谅解，欢迎讨论。

Paxos是什么

Paxos算法是基于消息传递且具有高度容错特性的一致性算法，是目前公认的解决分布式一致性问题最有效的算法之一。
Paxos的目标：保证最终有一个value会被选定，当value被选定后，进程最终也能获取到被选定的value。

分布式新系统的共识（consensus）方案需要保证一些基本的的特性：

safety：多个副本之间对某个决议能够达成一个共识，且不能被篡改，
liveness：多个副本之间对某个决议能够在有限的时间内形成，

Paxos算法原理与推导

参考文章：分布式系列文章——Paxos算法原理与推导

Basic Paxos

basic paxos做了件什么事情：

一个或多个Servers可以发起提案（Proposers）
系统必须针对所有提案中的某一个提案，达成一致
- 何谓达成一致？系统中的多数派同时认可该提案
最多只能针对一个确定的提案达成一致
1. 也就是说针对一个提案，先propose、promise，再发送accept请求（commit请求）、再被多数acceptor acccept之后就完事了。
2. 如果想commit value以外的信息，可以在某proposal被accept成功之后，成功propose成功的proposer向所有的acceptor追加commit信息。

basic paxos 算法分为两个阶段，Prepare 和 Accept 阶段

Proposal Numbers

一个 Proposal 是由 Proposal number 和 Proposal value 组成的，首先来看 Proposal number，既然针对一个 Proposal，那么每个 Proposal 都必须有一个唯一的 ID，也就是 Proposal Number，其有几个基本特性（注意后文不区分 Proposal number 和 Proposal Id）：

全局唯一，无论是相同的 Proposer 的不同 Proposal 还是，还是不同的 Proposer 的相同或者不同 Proposal
单调递增，越大优先级越高

prepare阶段

Proposer发送propose
1. Proposer 生成全局唯一且递增的Proposal ID（最简单的方法：round number + serverID），向集群的所有机器发送Propose，这里无需携带提案内容，只携带Proposal ID即可
Acceptor应答Propose
- Acceptor 收到Propose后，将会持久化proposal ID，并做出两个承诺，一个应答
- 两个承诺
  1. 不再应答Proposal ID 小于等于（注意：这里是<= ）当前请求的Proposal
  2. 不再应答Proposal ID 小于（注意：这里是< ）当前请求的Accept请求
- 一个应答
  1. 返回已经Accept 过的提案中Proposal ID 最大的那个提案的Value和accepted Proposal ID，没有则返回空值
    1. 这应该也是为什么，在多个proposor的共识方案中，必须要有prepare阶段，因为如果没有，所有的acceptor都不知道哪个值是已经形成决议的。
proposer收到应答之后
- proposal至少要收到一半以上acceptor的response
- acceptor的response中只要存在一个acceptedValue，需要将自己提议的value换成收到的acceptedValue中，acceptedProposal中最大的那个
  - 无论response中的acceptedValue是否真的被系统chosen了。这点保证了无论如何，basic paxos系统是安全的。最终都能达成一致。

名词解释：如果一个proposal被大部分acceptor accept了，那么认为proposal中的value被chosen了。

prepare阶段的意义

找到是否已经有value已经形成决议了（find out about any chosen values）
让acceptor拒绝早于当前proposal并且还没有accpect的proposal

Accept阶段

Proposer 发送Accept
- 提案生成规则：Proposer 收集到多数派的Propose应答后，从应答中选择存在提案Value的并且同时也是Proposal ID最大的提案的Value，作为本次要发起Accept 的提案。如果所有应答的提案Value均为空值，则可以自己随意决定提案Value。然后携带上当前Proposal ID，向集群的所有机器发送Accept请求
应答Accept
- Acceptor 收到Accpet请求后，检查不违背自己之前作出的“两个承诺”情况下，持久化当前Proposal ID 和提案Value。最后Proposer 收集到多数派的Accept应答后，形成决议
  - 持久化之后当前决议就已经形成，保证后续不会丢失
  - 如果已经有决议决定了某个value，那么其他没有参与到这次决议的proposer会在后续的proposal中学习到这个value（也就是前文讲的回复Proposal ID最大的提案的Value，作为本次要发起Accept 的提案，这个学习过程在propose阶段就可以完成）
proposer处理应答
- 如果acceptor没有接受自己的请求（response中的minProposal大于自己的proposalId），重新propose
  - 注意，basic paxos系统没有拒绝已经chosen的value再次proposal。只不过如果value已经chosen了，那么proposer在提议的过程中会学习到这个value，然后以更高的proposalId去提议。
- 如果超过半数acceptor接受了，或者超过半数没接受但是minProposal一致，那么表明当前决议的value已经被paxos系统决定（chosen）了。

paxos算法的关键特性

共识算法之 Basic Paxos

safety

quorum 机制：因为两个半数必然有相交，这样就不可能到存在两个value被同时最终接受造成不一致。而且可用性更好，可以容忍半数以下机器失效
后者认同前者：就是一旦一个acceptor接受一个确定性取值之后，后者会认同前者，不会进行破坏（这个取值其实是学习到的，认同前者，就是）。这样实现一种自动的往“某个提议值被多数派接受并生效”这一最终目标靠拢。
- **这实际上也paxos核心解决的问题：**当一个提议被多数派接受后，这个提议对应的值被Chosen（选定），一旦有一个值被Chosen，那么只要按照协议的规则继续交互，后续被Chosen的值都是同一个值，也就是这个Chosen值的共识问题。
- 一个acceptor只要接受了某个proposal，那么他就会认同这个值，并在proposal的response中返回。无论这个值是否真的被chosen了。博士视频中谈到了这里面多种情况，如：一个值被chosen了，一个值没有被chose但是仍然被后面的proposer选中等。

liveness

不会死锁（抢占式）：在 Proposal 和 Accept 有两个阶段都有两个承诺，例如，大的 Proposal Id 会覆盖让前一个 Proposal accept 失败，这样有什么好处呢？这里其实就是为了保证不会出现死锁，如可以让大 Proposal Id 可以抢占前面小的 Proposal id propose 权利，继续进行，因为如果某acceptor在收到大多数的 Propose 回复之后挂了，不支持抢占的模式将会造成死锁
会活锁：两个提案不断的出现 Prepare 阶段抢占。尽管出现的概率很小，但是从理论，确实存在活锁的可能性。最简单的解决方法是：proposer随机超时重试即可。当然，Multi-Paxos有leader，避免活锁。

notes

Basic Paxos 只负责达成一个决议

Basic Paxos只负责达成一个提案，一旦达成之后，其他的proposer就没有办法修改了，也就是说其他 proposer 再怎么重复的提交 propose，都只会学习到已经达成一致的 Value 值，然后重复提交

薛定谔的提案

“这里提一个名词：‘最大 Commit 原则’，这个阳振坤博士给我讲授 Paxos 时提出的名词，我觉得它是 Paxos 协议的最重要隐含规则之一，一条超时未形成多数派应答的提案，我们即不能认为它已形成决议，也不能认为它未形成决议，跟‘薛定谔的猫’差不多，这条日志是‘又死又活’的，只有当你观察它（执行 Paxos 协议）的时候，你才能得到确定的结果。” —— 李凯

在basic paxos系统中，只有proposer知道真正被chosen的value是什么
如果其他节点想知道chosen value，其必须再次执行proposal过程。

（有点像quorum中的NWR）

与2pc的关系

Paxos和2pc所起的主要作用不一样。Paxos的主要作用是作为共识协议，用于保证多个节点对同一个数据达成共识。
而2pc虽然是阻塞算法，并且还有各种宕机丢数据的问题，但其主要的关注点是在保证某个数据操作的原子性，这个操作要么全部成功，要么全部失败。失败的时候有回滚处理。
所以常见的做法是将Paxos和2pc结合起来，通过类似2pc的手段保证数据操作的原子性，通过类似paxos的共识协议，让数据在不同的副本间达成共识。

下面贴一个有有意思的回答：

就是大家其实都是用2PC的比较多(2PC是Blocking Atomic Commitment)，用Nonblocking-WeakAtomicCommitment的比较少。。。。比如Precolator，MegaStore和Spanner都是2PC。
而2PC的问题是某一个shard挂了，和coordinator挂了，需要block等。
那么只要保证shard和coordinator的high availability就可以防止block等待了。那么怎么保证high availability呢？=> 用replicated state machine。
怎么在异步环境(准确说应该是局部同步,partial synchronization，根据FLP，完全异步的环境consensus都无解)中实现replicated state machine呢？ => 用paxos这种共识算法。（对, 我们又绕回来了～～）

作者：阿莱克西斯
链接：https://www.zhihu.com/question/275845393/answer/397349131

参考链接

共识算法之 Basic Paxos
Paxos理论介绍(1): 朴素Paxos算法理论推导与证明
架构师需要了解的Paxos原理、历程及实战郁白
分布式系列文章——Paxos算法原理与推导