06 | Paxos算法（二）：Multi-Paxos不是一个算法，而是统称
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
Paxos算法是分布式系统中实现共识的重要算法，而Multi-Paxos思想则通过多个Basic Paxos实例实现一系列值的共识。Chubby系统的Multi-Paxos实现代表了这一思想在生产环境中的真正落地，通过引入领导者节点和优化Basic Paxos执行等方式解决了提案冲突和性能问题。Chubby的设计具有参考价值，能帮助理解Multi-Paxos思想和其他Multi-Paxos算法。文章深入浅出地介绍了Multi-Paxos思想及其在Chubby系统中的实现，对于理解分布式系统中的共识算法具有重要参考价值。Multi-Paxos的最大挑战在于如何证明其正确性，因此在实际使用时，建议优先考虑Raft算法，因为其正确性经过证明。Chubby系统的局限在于只能在主节点上执行读操作，这一设计限制了集群处理读请求的并发能力。文章内容深入浅出，对于理解分布式系统中的共识算法具有重要参考价值。
《分布式协议与算法实战》，新⼈⾸单¥59
全部留言(69)
- 最新
- 精选
HuaMax置顶“当领导者处于稳定状态时，省掉准备阶段，直接进入接受阶段”这个优化机制。 请问，什么样是稳定状态？为什么稳定状态可以省掉准备阶段？作者回复: 如何理解领导者处于稳定状态？ 领导者节点上，序列中的命令是最新的，不再需要通过准备请求来发现之前被大多数节点通过的提案，领导者可以独立指定提案中的值。 我来具体说说，准备阶段的意义，是发现接受者节点上，已经通过的提案的值。如果在所有接受者节点上，都没有已经通过的提案了，这时，领导者就可以自己指定提案的值了，那么，准备阶段就没有意义了，也就是可以省掉了。
2020-02-24740
每天晒白牙置顶只能在主节点进行读操作，效果相当于单机，对吞吐量和性能有所影响 写也是在主节点进行，性能也有问题作者回复: 加一颗星:)
2020-02-241023- Geek_MYMSwenChubby的局限可能在于高读的系统中，如果读请求过大，会导致系统的不可用。另外在系统中如何能够将主节点更替的信息向用户传播也是需要考虑的问题。 还有有一种情况我没有想清楚，请各位指点： 一个分布式系统中有5个节点，3个在一个机房A(机器编号A1，A2，A3)，2个在另一个机房B（机器编号B1，B2）。 1）如果节点A1的机架网络发生故障，导致A1与其他节点通信受阻，那么A1节点将会执行什么操作呢？通讯恢复以后A1节点如何进行数据同步呢？同样在A1无法通讯后出现集群有偶数节点，选举时会出现怎样的情况？ 2）如果主节点为B1，A机房与B机房间通讯产生故障，A机房和B机房的节点将分别执行怎样的操作呢？
作者回复: 加一颗星:) 1. A1节点，可以联系其他节点，联系领导者，获取最新的集群节点状态信息和领导者信息，拒绝写操作的执行。 2. 如果，同步数据，需要在代码实现设计实现，比如，可以请求领导者节点，把新通过的提案，都同步过来，更具体的实现，可以参考Raft的日志复制。 3. 偶数节点不是问题，只要有大多数节点在稳定运行，就可以了。 4. 节点B1，在leader leasing过后，要主动退位，并拒绝执行写操作，A机房的3个节点，将选举出新的领导者。
2020-02-24619 
小石头如果多个提议者同时提交提案，可能出现因为提案冲突，在准备阶段没有提议者接收到大多数准备响应，协商失败，需要重新协商。你想象一下，一个 5 节点的集群，如果 3 个节点作为提议者同时提案，就可能发生因为没有提议者接收大多数响应（比如 1 个提议者接收到 1 个准备响应，另外 2 个提议者分别接收到 2 个准备响应）而准备失败，需要重新协商。 这第一个问题理解不了，按上篇讲的，最大提议号的提议者不是会收到所有的准备响应么？作者回复: 加一颗星:)，这里指的是提案编号相同、选票瓜分的情况。
2020-03-2259- zjm_tmacleader怎么确定acceptor的总数呢？集群是允许扩容的吗
作者回复: 怎么确定acceptor总数，涉及代码实现和成员变更；扩容涉及到成员变更。 首先，使用什么数据结构来保存acceptor总数，这属于编程实现，不属于算法了，绝大多数算法都不会约定的这么细的。 其次，Multi-Paxos，只是一种思想，缺少算法细节和编程所必须的细节，比如，成员变更，在Multi-Paxos中，提了下，可以把服务器配置作为指令，通过状态机提交，等等。但是，如果学习了09讲后，你就会发现，真正实现起来，比这个要复杂很多，比如Raft设计了2种成员变更方法，一种难以实现，一种容易实现，但在16年时，爆出了一个算法bug，虽然很快就修复了，但也反映了成员变更比较复杂，不是三言两语能讲清楚的。 另外，其实，学习Multi-Paxos的最好的方式，是先理解Raft，再回过头来，学习Multi-Paxos。如果在学习Multi-Paxos中遇到不理解的，可以在学习完Raft后，再回头来研究学习。
2020-02-259 
snakorse找到一篇微信后台团队对PhxPasox的讲解，感觉是对multi-paxos非常好的补充，推荐一下https://mp.weixin.qq.com/s?__biz=MzI4NDMyNTU2Mw==&mid=2247483695&idx=1&sn=91ea422913fc62579e020e941d1d059e&chksm=ebfc62fbdc8bebed551c2a041bb37bcaab836c4b2ca8e575d418f1e24459459c1c16faf70d06作者回复: Paxos是共识算法，不是一致性协议，consensus不等于consistency。
2020-03-2156
eason2017集群，分布式的意义是提供更大的吞吐量，和并发，这样的操作无疑是掩耳盗铃作者回复: 有些场景需要的是强一致性、故障容错等，场景决定系统的形态。
2020-04-0125
阿卡牛主节点只一个？那存在单点故障的问题作者回复: 有节点故障容错能力的，当主节点故障时，会选举出新的主节点，保证集群服务的可用。
2020-03-245
陈只能在主节点读取，存在单机性能和容错问题。作者回复: 加一颗星:)，性能瓶颈是痛点，共识算法具有容错能力，领导者模型的共识算法，在故障、选举期间，无法执行写操作。
2020-02-285
约书亚本来想问个问题，看到思考题提到了。 从raft和zab的实现来看，一致性读操作的处理和写操作是类似的，不从本地读，而是也要发请求到所有节点，得到大多数节点的响应才行。我了解到的有的实现是领导者发送一个空操作给所有节点。 这样做的原因不光是考虑吞吐量的问题，而是读本地是满足不了强一致性的，因为自以为的leader未必是真的leader，此时可能另外的节点已经自己组成一个小团队，选出一个新leader，这个变量也可能都更新好几次了。只有和大多数节点交互一次才能知道自己当前还是不是leader。 有个问题，兰伯特提到的 “当领导者处于稳定状态时...”这个稳定状态是什么意思呢？在领导者是谁这个问题上，达成大多数节点的一致?作者回复: 领导者节点上，序列中的命令是最新的，不再需要通过准备请求来发现之前被大多数节点通过的提案，领导者可以独立指定提案中的值。 我来具体说说，准备阶段的意义，是发现接受者节点上，已经通过的提案的值。如果在所有接受者节点上，都没有已经通过的提案了，这时，领导者就可以自己指定提案的值了，那么，准备阶段就没有意义了，也就是可以省掉了。
2020-02-245
