MultiPaxos思想

兰伯特Lamport提到的 Multi-Paxos 是一种思想，不是算法。

而 Multi-Paxos 算法是一个统称，它是指基于 Multi-Paxos 思想，通过多个 Basic Paxos 实例实现一系列值的共识的算法（比如 Chubby 的 Multi-Paxos 实现、Raft 算法等）

两个问题：

1. 如果多个提议者同时提交提案，可能出现因为提案编号冲突，也可能出现没有提议者能够收到大多数响应，最终主备失败重新协商。
2. 准备阶段和接受阶段两轮的往返消息多，性能和延迟问题。
   1. 兰伯特提到：“当领导者处于稳定状态时，省掉准备阶段，直接进入接受阶段”这个优化机制

• 引入Leader

  • 作为唯一Proposer，
  • 避免多个节点作为Propos同时提案，使得没有提议者能够获得大多数响应，导致准备阶段失败，重新协商的情况
  • 在论文中，兰伯特没有说如何选举领导者，需要我们在实现 Multi-Paxos 算法的时候自己实现。
  • 可以通过BasicPaxos算法进行选主。

• 省略准备阶段

  • 当Leader稳定时，可以省略准备阶段，直接进入接受阶段
  • 稳定的意思是。领导者节点上，序列中的命令是最新的，不需要通过准备阶段来发现之前被大多数节点通过的提案。。当领导者处于稳定状态时，因为只有一个领导者即是单机，单机自然是时间有序的，不需要逻辑时间，直接使用单机物理时间，所以可以忽略时间概念(一般单机上是不会感知时间的，都是按照操作的先后顺序)。
  • 不存在提案冲突：重复执行 Basic Paxos 相比，Multi-Paxos 引入领导者节点之后，因为只有领导者节点一个提议者，只有它说了算，所以就不存在提案冲突，可以直接进入接受阶段。

• 选主

• 主节点续租Lease

• 成员变更

• 一致性

  • 同步写，强一致性

• BasicPaxos算法经过证明

• MultiPaxos思想的工程实现需要证明是最大的挑战

• Raft算法也是经过证明的

怎么确定acceptor总数，涉及代码实现和成员变更；扩容涉及到成员变更。
首先，使用什么数据结构来保存acceptor总数，这属于编程实现，不属于算法了，绝大多数算法都不会约定的这么细的。

其实，学习Multi-Paxos的最好的方式，是先理解Raft，再回过头来，学习Multi-Paxos。如果在学习Multi-Paxos中遇到不理解的，可以在学习完Raft后，再回头来研究学习。