Multi Paxos是什么
- Basic Paxos 只能对一个值形成决议,决议的形成至少需要两次网络来回,在高并发情况下可能需要更多的网络来回,极端情况下甚至可能形成活锁
- 实际应用中我们常常需要连续确定多个值,而且希望能有更高的效率。
补充
- 分布式一致性协议,来源于我们对系统可用性,容错性的追求。 为了避免单机失效导致整个系统不可用的问题, 我们会很自然地希望复制数据多结点部署。 但数据一旦出现了多份, 就需要解决一致性的问题。
- 为了解决多份数据的一致性问题, 我们常常将其简化为多份状态机的一致性问题,即复制状态机。 对于客户端发来的一系列指令, 只要我们能确保将指令以唯一确定的顺序发送给所有结点, 那么只要各个状态机的初始状态相同, 执行完所有指令后 (指令对状态机的影响必须是唯一确定的结果), 必然也会到达相同的状态, 实现一致性目标。 在多状态机一致性问题中, 共识算法( Consensus Algorithm) 的作用就是确保多份 log 中包含顺序和内容完全一致的指令。
- Paxos 算法最开始是定义了一种算法, 能够使多个结点针对单个决议/单个数据项 达成共识。 Raft 将该算法称为 single-decree Paxos(单决议 Paxos)。 在实践中, 我们希望达成一致的数据, 显然不会是个单项孤立的数据, 在单决议 Paxos (single-decree Paxos)的算法基础上实现多决议/多数据一致性的算法被称之为multi-Paxos( 多决议 Paxos)。
要点
- 针对每一个要确定的值,运行一次Paxos算法实例(Instance),形成决议。每一个Paxos实例使用唯一的Instance ID标识。第i个实例中的内容就是第i条状态机指令。
- Paxos实例中的每个服务器同时具有所有的角色:proposer、acceptor和learner。
- 在所有服务器中选举一个Leader,由Leader唯一地提交Proposal给Acceptors进行表决。leader会决定客户端发送的指令在序列中出现的位置。
- 这样没有Proposer竞争,解决了活锁问题。在系统中仅有一个Leader进行Value提交的情况下,Prepare阶段就可以跳过,从而将两阶段变为一阶段,提高效率。
总结
- Paxos描述了三个阶段,prepare、accept和learn。
- 在前两个阶段中,proposer和acceptor通过通信来决定一个提案是否通过,提案的内容一般是对分布式系统中的数据进行操作。
- 当一个提案通过时,learner会学习这个提案,表示为分布式系统的learner将提案的内容应用到自己的状态机模型上。
- 论文中没有描述leader具体怎么选举
- leader身兼3个角色,作为proposer唯一提出提案,作为learner将通过提案发送给其他的learner
- 缺少必要具体实现的描述
优点
安全性 safety
- 在集群内结点可能宕机, 通信消息可能丢失,延迟的情况下(消息不会被篡改),客户端发往集群的请求不会返回错误的结果
- 所谓错误的结果是指违反 Linearizability 的结果, Linearability 的定义后续有详细说明
存活性 liveness
- 当集群半数以上结点正常运转且可以相互正常通信的情况下, 整个系统可以正常对外提供服务。
- 注意上述存活性的定义中, 半数以上结点能够相互通信非常重要, 缺失了这一前提后, 再想实现同时满足 livess 和 safety 的系统就是一个不可能达成的目标, 这是被学界大佬证明过的, 类似于 CAP 定理
在正常的情况下,效率不差
缺点
难以理解
- Paxos 原始论文《The part-time parliament》
- 简化论文《Paxos made simple》
- 《How to Build a Highly Available System Using Consensusr》
- 《The ABCD’s of Paxos》
缺失了工程化的细节信息
- Lamport 本人的论文描述主要集中于 single-decree Paxos, 他描述了几种实现 multi-Paxos 的可行方法, 但缺失了细节。
- 有一些论文试图更完整地描述 multi-Paxos 的实现方式, 但是这些论文描述的方案各不相同, 并且与Lamport 本人描述的 multi-Paxos 实现思路也有差异。Google 实现的 Chubby 系统论文中声称基于 Paxos 的算法, Chubbty 也有很多细节信息没有发表在论文里,Chubbty并不开源。
参考
https://www.zhihu.com/collection/149098870