文章目录

导读
历史
解决的问题
理论分析
- 只有一个Acceptor
- 两个Acceptor
- 结果到原因的推进
- 如何预测未来
- 理论到工程的缺陷
- - 根本问题在哪里
- 算法提出
FAQ

导读

paxos算法为什么是这么设计？Paxos协议为什么是两阶段？为什么第一阶段的时候需要取一个最大编号？本文尝试从一个简单场景一步步构建出理论框架并转化为可工程化的算法

历史

paxos从诞生至今已经近30年，从开始工业化至今也有10来年历史，但至今仍然难以理解。本文尝试从最简单的场景入手，一步步尝试去推导及理解理论约束中的各个细节点，其中不免有理解不对的地方，请大家能够指正。

解决的问题

首先明确解决的问题，paxos的目的是解决一致性问题。举个简单例子：三个人在三个不同的城市，如果手上只有一支笔和一张不可修改的羊皮纸。大家可以互相写信，经过一段时间，大家羊皮纸上的内容必须完全一样。这就是这个协议要解决的一个根本问题。

理论分析

只有一个Acceptor

先看下最简单的场景，如果只有一个Acceptor，要解决一个Acceptor的共识问题很简单，谁先来提交提议，那我就接受谁的就行了。因为没有多个，不会有提议冲突问题。因为，提出一个约束：
P1：一个Acceptor必须接受他收到的第一个提议。
原论文表述：
P1. An acceptor must accept the first proposal that it receives.

通过满足P1即可解决。这个应该不需要证明。如果真要证明，那用反证即可。

两个Acceptor

假如两个Acceptor，分别为A1，A2。只有一个提议者，这个提议者先对A1提了一个提议(1, V1），对A2提了一个提议（2, V2)，假设V1!=V2。那么按照P1的约束，这里A1和A2都会接受提议。那么此时，A1与A2他们的认知，就会不一致，因此P1无法保证两个Acceptor情况下集群的认知会一致。因此，需要对其进行加强约束。这里因为会存在多个编号，这里为了方便，逻辑上假设每个提议者提交的编号都是递增。
因此，对于多个提议被选定这件事情，我们如果一个提议V被chosen，那后续提交的提议被chosen的也只能是V，这样就能保证所有的被chosen的提议就是V了。
P2：一旦一个具有 value v 的提案被批准（chosen），那么之后批准（chosen）的提案必须具有 value v。

原论文表述：
P2. If a proposal with value v is chosen, then every higher-numbered proposal that is chosen has value v

这里请反复读三次。再脑子里面想一下。先读的时候，你会觉得这是废话，但这里其实就是强调一个结果的表达。一个被选定，后续被选定的也是V。口说无凭，我们来一个无聊的证明，P2为什么能保证大家一致。
这里我用一个反证法。

证明：
假设满足P2的情况下，存在一个V1!=V，
那么，V已经被选定，V1的选定，与P2中描述的，V之后被选定的必须也是V相矛盾。
因此假设不成立，假设的反面成立。
即是不存在一个V1!=V，即是所有被选定的都是V。

结果到原因的推进

P2再读几遍，会发现他只是对一个结果的约束，那我们做工程的，无法对结果约束，只能对发生的时候看下能否想办法约束。这里只是要求被选定，正所谓，有果必有因。我只要限制原因，那结果自然能保证。而被选定，则一定是会有被提出。因此，这里换种对原因的表达，我们看看能否往前再推进一下：
P2B：一旦一个具有 value v 的提案被批准（chosen），那么以后任何 proposer 提出的提案必须具有 value v。
原论文表达：
P2b.If a proposal with value v is chosen, then every higher-numbered proposal issued by any proposer has value v.

这里是因果关系，限制了提交的提议，则一定能保证最终的被选定的结果。
因此：P2B如果能满足，则一定能满足P2，
P1 && P2 => 保证一致性。
因此，下一个问题，我们想下如何来满足P2B。

如何预测未来

注意到P2B中的描述，从一个提议者的角度，假如说有一个提议被选定了，让他去提出这个提议，那得让他有上帝视角，让他有预测未来的能力。这明显是不可能的。那能有啥办法让他也能提出一样的V？

最直观的做法，就是去询问问一下集群里面的acceptor，再来提交一个提议。这也即是为什么paxos是两阶段提交的根本原因。看下大家有没有选定什么提议了，如果没有谁有选定，那么我就可以放心提出来。如果已经有被选定了，那我乖乖照着V来提议就行了，这样就满足P2B了。
过去问的时候，需要问几个acceptor呢？假如说有3个acceptor，需要问1个，2个，还是3个？如果问1个，可能会遗漏，因为可能其他两个已经选定了这个协议，但问的刚好不知道这个事情。问3个呢？肯定也可以。只是没有必要，因为我要求所有Acceptor都能工作。如果有一个Acceptor开小差或者挂起这个机制就无法工作了。因为2个就够了。这里就是指多数派。即是群集里面的一半以上的数目即可。因为一半以上，一定能问出是否接收有接收过提议。
因此，综上，比较正式的描述，可以换成一个多数派的约束，对提议的提出进行结束。
这里指的一个提议被选定，是从提议者的角度来看，他如果多数派给他反馈说提议选定了，那即是选定。

P2C：如果一个编号为 n 的提案具有 value v，该提案被批准(chosen)，那么存在一个多数派，满足以下两个条件任何一个即可：
A）他们中所有人都没有接受（accept）编号小于 n
的任何提案
B）他们已经接受（accept）的所有编号小于 n 的提案中编号最大的那个提案具有 value v。

原论文表达：
P2c. 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.

这里感觉读的比较绕。可以先简单这样理解：如果想提出来一个提议，要么就是当前Acceptor中的大多数人，都没有选定过提议。这种情况你可以随便提自己的提议。要么如果集群里面的大多数Acceptor已经接受过提议的情况下，你只能选择这些Acceptor中已经选定的编号最大的那个提议，你也提一个相同的提议出来。

理解归理解，但为了严谨，还是得证明，为什么P2C能够推导出来P2B。我们尝试来证明一下。

命题：
在满足P2C的情况下，如果一个提议(m, Va）被提出，则后续的提议，n > m，提议(n, Vb)，满足P2C的情况下，证明：Vb = Va

如果命题得证，就说明P2C能够保证P2B，从而保证一致。这里我们用归纳法来尝试证明。

证明：
当n = m + 1时，因为(m, Va)被提出来，则必然存在一个集合Sm， m是其中编号最大的提议。而当第m+1提议提出来时，他去找的多数派中，必然包含编号为m的这个提议（两个多数派必然有交集），因此，他的提议，必须与Va相同，因此，Vb=Va。

假设n = m + k（k > 1)时，结论成立，即是(m + k, Vb)，有Vb = Va，求证：n = m + k + 1时，提议(m + k + 1, Vc)，有Vc = Va。
同理，由于(m + k + 1, Vc)能够被提出来，则多数派中必然能找到一个(m + k, Vb)这个提议，因此按照P2C的第二条约束，则Vc必须与Vb保持一致，因此，Vc = Vb = Va。

综上：对于任意的n > m，如果(n, Vb）满足P2C约束时，我们可以保证Vc = Vb了。

理论到工程的缺陷

看到P2C了，离真正可实施的算法纬度，又更近一部了。这是我们看一个例子：

看下这种CASE，
1）T1时刻，Proposer1去询问，A1，A2会告诉Proposer1，我啥都没有选定。
2）T2时刻，Proposer2去询问，A1，A2会告诉Proposer2，我啥都没有选定。
3）T3时刻，Proposer1按照P2C的约束，他认为没有谁提过提议，他会提交一个自己的提议（1， Va）给A1, A2。
4）T4时刻，A1收到了Proposer1的提议，他会接受他。
5）T5时刻，Proposer2收到了A1，A2的应答，说我们都没有接收过提议，因此Proposer2对A1，A2提交提议（2, Vb）
6）T6时刻，A2收到了Proposer2的（2，Vb）提议，对他来说是第一次收到提议，因此会接受这个协议。

因此，最终结果是A1（1，Va）， A2（2，Vb），A3空，群集产生了认知不一致。大家都是各执一词。

根本问题在哪里

这里看上去比较好的符合了P2C，可还是冲突了，为何？这里看下，从了解多数派中的最大编号，到提出来自己的提议，理论上是要求原子完成。而事实上，这里如果在工程上，是会有时序问题，我去问完回来，我知道是没有谁提过提议，但当我要提交的时候，我怎么能保证一定没有其他人也不提交提议？即是：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8X9RdZjq-1592368924365)(http://km.oa.com/files/photos/pictures/202006/1592040855_28_w530_h440.png)]

即是我的询问到提交，中间有他人提交的话，这时候，不会有一个上帝视角的人出来告诉你，这时候你再提已经不满足P2C了。这时候，对于proposer1，他已经不知道自己干了蠢事。那能怎么解决问题？既然阻止不了他，那就让后面的acceptor去拒绝他就好了。因此有了P1A的出现。如果Proposer1从询问到后面提交的过程中，有其他人介入，那后续所有的Proposer1的提交都拒绝掉。
P1A:当且仅当acceptor没有回应过编号大于n的prepare请求时，acceptor接受（accept）编号为n的提案。

原论文表述：
P1a. An acceptor can accept a proposal numbered n iff it has not responded
to a prepare request having a number greater than n.

算法提出

结合P1a和P2C，其实就已经得到了paxos两阶段的算法表达：
1.prepare阶段：
proposer选择一个提案编号n并将prepare请求发送给acceptors中的一个多数派；
acceptor收到prepare消息后，如果提案的编号大于它已经回复的所有prepare消息(回复消息表示接受accept)，则acceptor将自己上次接受的提案回复给proposer，并承诺不再回复小于n的提案；

2.批准阶段：
当一个proposer收到了多数acceptors对prepare的回复后，就进入批准阶段。它要向回复prepare请求的acceptors发送accept请求，包括编号n和根据P2c决定的value（如果根据P2c没有已经接受的value，那么它可以自由决定value）。
在不违背自己向其他proposer的承诺的前提下，acceptor收到accept请求后即批准这个请求。

原论文表述：
Phase 1. (a) A proposer selects a proposal number n and sends a prepare
request with number n to a majority of acceptors.
(b) If an acceptor receives a prepare request with number n greater
than that of any prepare request to which it has already responded,
then it responds to the request with a promise not to accept any more
proposals numbered less than n and with the highest-numbered proposal (if any) that it has accepted.

Phase 2. (a) If the proposer receives a response to its prepare requests
(numbered n) from a majority of acceptors, then it sends an accept
request to each of those acceptors for a proposal numbered n with a
value v, where v is the value of the highest-numbered proposal among
the responses, or is any value if the responses reported no proposals.
(b) If an acceptor receives an accept request for a proposal numbered
n, it accepts the proposal unless it has already responded to a prepare
request having a number greater than n

FAQ

假如说一个提议被大多数选定，那后续的提议者再提一个同样的提议V的协议有什么意义？
这个有助于整体认识的扩散和收敛
为什么上述表达中，把论文中的P2A去掉了？
因为本作者觉得从P2直接过度到P2B更顺畅，完全不影响对整体的理解，而且更加简洁。直接就是由果寻因的思考。
为什么要P2C中，要求选择一定编号小于n的最大编号，有这个限制？随便找一个是否OK？
不行，因为随便找一个的话，不一定能找到最新版本的提议。有可能只是某个节点接受，但没有达成多数派的提议。
例如：。
T1时刻，proposer1对Acceptor1和Acceptor2进行询问，是否可以提交一个(1, Va)的提议，假设发给Acceptor3的消息丢失。而他们都没有接受过提议，所以返回可以提交。
T2时刻，proopser2对Acceptor2和Acceptor3进行询问，是否可以提交一个（2， Vb）的提议，假设发给Acceptor1的消息丢失。对于Acceptor2和Acceptor3没有接受过提议，所以返回可以提交。
T3时刻， proposer1收到了Acceptor1和Acceptor2的应答，对Acceptor1和Acceptor2执行(1, Va)进行提交。
T4时刻，Acceptor1和Acceptor2收到了proposer1的提议，根据P1A，Acceptor1由于没有接受过编号大于1的请求，Acceptor1会接受这个提议。Acceptor2由于在T3与T4时刻之间，接受过proposer2的询问请求，收到过编号2的提议的prepare，因此，Acceptor2会拒绝编号为1的提议。
从proposer1角度来看，他只收到了一条成功应答，这次(1, Va）并没有成功，虽然写到了其中一个Acceptor1之中。

T5时刻，proposer2收到了Acceptor2和Acceptor3的应答，于是执行(2, Vb)的提交操作。
T6时刻，Acceptor2和Acceptor3接受了(2, Vb)的提交操作，给。
从proposer2角度来看，他收到了两条成功应答，这次(2, Vb）提交成功

此时，三个Acceptor中，分别为（1， Va), (2, Vb), (2, Vb)。
当此时，如果Acceptor2挂起，只存在Acceptor1, Acceptor3的时候，如果此时他来询问，则拿到两个不一样的提议，那此时被集群选定的大多数的提议就是Vb, 而此时只能靠最大编号来区分了。
假如没有最大编号，则可能导致这个后续的prepare操作得到一个错误共识结果。

paxos协议的理解及证明推导相关推荐

大数据基础(4) - Paxos协议
文章目录 1. 整体介绍 2. Paxos 协议产生的背景 3. 副本状态机模型 4. 基本概念 5. Paxos 协议过程 5.1 准备阶段(占坑阶段) 5.2 接受阶段(提交阶段) 5.3 Pax ...
浅谈paxos协议与zookeeper
一.介绍两篇好博客 1.zookeeper全解析–paxos作为灵魂 https://blog.csdn.net/YQlakers/article/details/72630353 2.下面这篇文章介 ...
理解这两点，也就理解了paxos协议的精髓
什么是paxos协议? Paxos用于解决分布式系统中一致性问题.分布式一致性算法(Consensus Algorithm)是一个分布式计算领域的基础性问题,其最基本的功能是为了在多个进程之间对某个( ...
理解分布式一致性:Paxos协议之Generalized Paxos Byzantine Paxos
理解分布式一致性:Paxos协议之Generalized Paxos & Byzantine Paxos Generalized Paxos Byzantine Paxos Byzantine ...
理解分布式一致性:Paxos协议之Cheap Paxos Fast Paxos
理解分布式一致性:Paxos协议之Cheap Paxos & Fast Paxos Cheap Paxos Message flow: Cheap Multi-Paxos Fast Paxos ...
理解分布式一致性:Paxos协议之Multi-Paxos
理解分布式一致性:Paxos协议之Multi-Paxos Multi-Paxos without failures Multi-Paxos when phase 1 can be skipped Mu ...
如何理解分布式paxos协议
前言 google的chubby的作者Mike Burrows说过,世界上只有一种一致性算法,那就是paxos,由此可见paxos协议的影响力.某司相关部门对paxos有一定的研究,并且已经在生产环境 ...
理解分布式一致性:Paxos协议之Basic Paxos
理解分布式一致性:Paxos协议之Basic Paxos 角色 Proposal Number & Agreed Value Basic Paxos Basic Paxos without f ...
paxos协议对比_分布式一致性协议三部曲-深入理解一致性协议Paxos
CAP二阶段提交协议(2PC)协议详情改进缺陷参与者还都处于锁定事务资源的状态中,而无法继续完成事务操.尽管协调者挂掉后可以重新选举一个协调者,但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问 ...

paxos协议的理解及证明推导