Paxos算法（二）—Multi Paxos

Basic Paxos算法通过多轮的prepare和accept请求确定一个值，这个值确定之后就不能再修改，这样一个过程为一次Paxos实例。然而实际的工程实现中，确定一个值的用处不大，比如KV存储系统，要求这个值可以多次set，那么如何将Paxos算法应用起来呢，换一种思路，比如leveldb的数据文件sstable中，记录的不是值，而是一次次操作日志，这样系统重启之后，只要回放这些操作日志就能重建整个系统，并且这些操作日志一旦确定，就不能修改。Paxos算法就用来在分布式系统中对某个操作日志达成共识，一次Paxos实例确定一条日志，多次Paxos实例就可以确定一系列日志，这就是Multi-Paxos。

Multi-Paxos

基本算法如下：
假设系统中有ABC三个副本，只要这些
节点的操作日志严格一致，日志应用到状态机中，就能得到严格一致的输出，就可以认为这三副本一致。按照Basic Paxos算法，这3个节点既可以为Proposer，也可以为Acceptor，每个节点磁盘上都存储着一组日志，日志项可以不连续，也可以有空洞，同时3个节点可以同时提议一个client请求。
当client请求到来时，假设由A处理这个请求，A会在自己的日志项中选择第一个没有被确定的日志项，如果有这个日志项，只要A不是这个日志项的Proposer，A都不能够确定这个日志项被确定，那么就以这个日志项去发起一个Basic Paxos实例，直到A的日志项中没有不被确定的，就选择一个新的日志项，用最大的序列号去发起一次Basic Paxos，这次Basic Paxos可能有两种结果，如果成功确定一个日志项，等到A本地所有的日志项都应用到状态机后，给client回复；如果失败，说明这个日志项在其他节点中已经被确定，那么A负责按照其他节点中确定的值去修复这个日志项。

优化

然而这样直接实现的Multi-Paxos性能很差，确定一个值至少需要两次rpc。下面看看相关的优化方式：

Leader

Multi-Paxos在高并发下，每一个Proposer在接收到client请求时都会试图发起一次提案，冲突很大，即便没有冲突，也需要两轮rpc才能确定一个值。所以考虑选择一个节点作为Leader，有Leader负责处理用户请求，发起提案，Lamport在Paxos的论文中也有提及：
1、Leader间隔一段时间T给其他Proposer发送心跳。
2、如果Proposer超过2T时间没有收到Leader的心跳，可以自己成功Leader，接受client请求。
3、非Leader节点收到client请求时，redirect到Leader节点
这里并没有详细讲解Leader被选出的过程，包括chubby的论文中，网上有资料说可以通过一次Paxos算法选出Leader。这里并不需要刻意的选取Leader，只要非Leader节点超过2T时间内没有收到心跳，自己就可以成功Leader，接着根据自己的日志项按照上述的Multi-Paxos逐一向集群中提交提案。为了防止在这个过程中再次出现冲突，如果某个节点收到了其他节点的accept请求，那么久拒绝client服务一段时间，给与其他节点足够的时间来形成Leader的续约。
通过Leader和租约解决了多个Proposer并发提交提案带来的冲突问题。

省掉phase1

通过Leader及续约机制，基本解决了大部分的冲突问题，也就是说Basic Paxos算法中的第一次prepare phase基本不会失败冲突，那么可以考虑省掉这一步，实际上心跳请求充当了prepare的作用，对节点中当前以及以后的日志项全部执行了prepare请求，后续client请求可以直接执行accept请求。

为了保证读写的强一致，Multi-Paxos要求读写都在Leader节点上进行，与Raft相似，这样也会形成单点问题。