Paxos是一种分布式系统中的共识算法，包括BasicPaxos和MultiPaxos。BasicPaxos在一轮决策中选择一个值达成共识，涉及选主、资源互斥和日志复制等问题。MultiPaxos用于连续决策多个值，通过选主优化效率。Paxos算法对理解分布式一致性至关重要，实际应用中常见于ZAB和RAFT等协议。
目录
一、Paxos基本介绍
paxos算法是分布式系统中的一个共识算法家族，也是第一个被证明正确性的共识算法。“世界上只有两种分布式共识算法，一种是paxos算法，另外一种是类paxos算法”，现在比较流行的ZAB和RAFT算法也是基于Paxos算法而设计的，所以理解paxos对理解分布式一致性共识有重要意义。
不喜欢看理论的直接跳到流程图，个人表示可以反推理论会更容易理解。
二、Basic Paxos介绍
- 2-1、Basic Paxos是在一轮决策中对一个或者多个被提议(propose)的值，最终选出一个值达成共识。即如果需要对多个值进行一次决策，只选出一个值来，那么这个决策的过程就是共识的过程。
- 2-2、Basic Paxos可以解决的问题
- 选主；
- 资源互斥访问；
- 复制日志的一致性；
- 其他；
- 2-3、 容错模型
- 异步网络，网络是不可靠的，消息可能丢失、重复、延迟、网络分区，但是不包括拜占庭错误，即消息不会被篡改和伪造；
- 只要大多数服务器还运行，决议就能继续进行；
- 2-4、FLP定理
- Agrement：所有server必须对同一个值达成共识；
- Validity：达成共识的值必须是提议的有效值；
- Termination：最终会对一个值达成共识——类状态机（Paxos不一定）
- 2-5、Safety & Liveness（满足的条件）
- Safety（不会有坏事发生）：只有一个值达成共识；一个server不会知道某个值达成共识，除非它真的已经达成共识；
- Liveness（好事一定会发生）：最终一定会达成共识，在多个proposer的情况下不能保证，即basic paxos是不能保证终止的，为了保证终止就需要选出一个leader，每次提议只通过一个leader发起。如果共识达成最终所有服务器都能够知道；
- 2-6、Paxos角色构成
- Proposer（提案人）：处理客户端请求，主动发起提议；
- Acceptor（接受者）：被动接受来自Proposer的提议消息，并返回投票结果，通知learner；
- Learner（学习者）：被动接受来自Acceptor的消息；
- 实际中一个节点会经常扮演这三个角色；
- 2-7、Paxos二阶段协议 （统称协商阶段）
- 第一阶段：Prepare阶段。Proposer向Acceptors发出proposal请求，Acceptors针对收到的proposal的序列号请求进行Promise承诺。
- 第二阶段：Accept阶段。Proposer收到多数Acceptors承诺的Promise后，向Acceptors发出accept请求，Acceptors针对收到的accept请求进行Accepted处理。
第三阶段：Learn阶段。Proposer在收到多数Acceptors的Accept之后，标志着本次Accept成功，决议形成，将形成的决议发送给所有Learners。
备注：多数派，即Proposer收到多少Acceptors的Promise以后才能够发送下一阶段的accept请求。
- 超过集群一半成员组成集合
- [n/2]+1 (n为成员总数，[]向下取整)
- 2-8、协商阶段
- Acceptor：令自己所见过的最大的提案编号为local.n,请求中的提案编号为msg.n。
--收到prepare请求，msg.n > local.n,则通过该请求，否则拒绝该请求，直接抛弃该请求。
--收到accept请求，msg.n >= local.n,则通过该请求，否则拒绝该请求，直接抛弃该请求。
--通过某一prepare请求，会在prepare响应中携带自己所批准过的最大提案编号对应的提案值。
- Proposer
--收到客户端请求，先发起prepare请求。
--收到多数派prepare响应，才可以进入accept阶段。其提案值需要从prepare响应中获取。
--收到多数派accept响应，则改提案达成共识
理论知识比较难以理解，我们通过流程图加以理解：
单个Proposer发起提议的情况：
角色：P1— Proposer | A1/A2—Acceptor | L1—Learner
基本流程：
- 第一步：P1分别向A1和A2发送proposal-1请求；
- 第二步：A1和A2确定提案可行以后，分别向P1返回promise-1请求；
- 第三步：P1收到A1和A2的promise-1请求后，确定提案通过，然后分别向A1和A2发送accept(1,'cat')请求——(假设之前没有收到更大的proposal的序号值)；
- 第四步：A1和A2收到accept(1,'cat')请求以后，A1和A2分别向P1和L1发送accepted(1,'cat')请求。此时流程结束，共识达成。
多个proposer发起提议的情况：
备注：在paxos中，proposal的序列号，要求全局递增且唯一，关于序列号生成办法后续有机会再补充，此处P1节点采用奇数递增，P2节点采用偶数递增来简单处理。
P1—基本流程：
- P1分别向A1和A2发送proposal-1请求。
- A1正常返回promise-1请求，但是A2发现已经接受到P2发过来的proposal-2消息，序列号2>1，所以A2返回no-ack（或者不返回）；所以P1并不满足多数派的需求,第一次共识流程结束—失败。
- P1分别向A1和A2发送proposal-3请求；
- A1返回promise-3；A1上次收到的最大序列号是P1的proposal-1，也就是1，1<3所以通过。
- A2返回promise(3,(2,'value2'))；A2上次收到的最大序列号是P2的proposal-2，也就是2，2<3所以通过。这里的(2,'value2')是P2达成共识用到的accept(2,'value2') 。
- P1收到了多数节点返回的promise，这个时候会向A1和A2发起accept(3,'value2')请求。这里需要注意的是，value2是P2前面已经达成共识的值，P1会在accept流程中使用到这个值，这意味着P1和P2达成共识的值都是value2。
- A1、A2都向P1返回accepted(3,'value2')。
- P1收到A1和A2的返回accepted(3,'value2')，流程结束。
- 此时P1与P2都收到了value2这个值，意味着value2在P1和P2达成共识。
P2—基本流程
- 同：单个Proposer发起提议的情况（第一张流程图）
死锁情况（也叫活锁，因为进入了死循环）
在并发环境下，死锁是必须要考虑的问题，造成死锁的原因是Paxos二阶段协议中，acceptor需要对Proposer发起的proposal请求和accept请求都根据序列号做大小的校验。上图中死锁的基本流如下：
- P1发送proposal，A1和A2返回promise通过；
- 在P1执行accept请求之前，P2也发送了proposal请求，此时序列号为6；
- P1发送accept请求，acceptor发现本次accept的序列号为5，小于本地见过的最大序列号6，accept请求被否定；
- P1重新发起proposal请求；
- P2流程和P1一样，P1和P2都无法达成共识，进入死循环，这就是死锁
三、Multi Paxos介绍
Basic Paxos能够解决的问题是在一轮决策中对一个或者多个被提议(propose)的值，最终选出一个值达成共识，也就是说就某一个值达成共识。而实际生产中，我们需要对连续的值达成共识，所以需要用到Multi Paxos。
- Multi Paxos的由来:The Preliminary Protocol(初级协议)>The Basic Protocol(基本协议)->The Complete Synod Protocol(完整神会协议)->The Multi-Decree Parliament(多法令议会协议)。
- 当需要决定多个值时就需要连续执行多层次Paxos算法，一般执行一次Paxos算法的过程称作A Paxos Run或者A Paxos Instance，连续决定多个值则就需要执行多次Paxos。
- Multi-Paxos是由The Complete Synod Protocol衍生而来，The Complete Synod Protocol通过选主解决了进展性问题（同时也是满足一致性的）。
- 在Paxos算法中，选主只是为了解决进展性问题，但不会影响到一致性，即使出现脑裂的情况下，Paxos算法也是安全的的，只会影响进展性。
- 两阶段协议效率太低，可以有优化空间。在单个Leader的情况下，如果前一次已经accept成功，接下来不再需要prepare阶段，直接进行accept。
- 一般的Multi-Paxos可以简单总结为（选主+两阶段的优化），但是选主不是必须的（舍弃一定的进展性）。
- 多个instance可以并发的进行。
四、总结
Paxos和Multil Paxos属于学术界理论，而我们实际生产应用中主要用到的还是RAFT和ZAB，
扫一扫
7057
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
