分布式系统---升级Paxos和Raft算法

上一篇博客写到基础的Paxos算法，但是这个基础的算法存在问题，首先就是太耗时间了，每次都需要2个大轮次才可以完成一致共识。一次提案，两阶段提交的RPC调用次数多。

Multi-Paxos算法

在Basic Paxos协议中，每一次执行过程都需要经历Prepare->Promise->Accept->Accepted 这四个步骤，这样就会导致消息太多，从而影响分布式系统的性能。
如果Leader足够稳定的话，Phase 1 里面的Prepare->Promise 完全可以省略掉，从而使用同一个Leader去发送Accept消息。
当然我们还要对请求消息做一些改造，这里我们在请求里面加入了轮数I，I表示的是同一个leader发送Accept请求的次数，每发送一次请求，I+1 。
下面我们用序列图的形式尽可能的去展示Multi-Paxos的魅力。
Multi-Paxos的核心思想就是采用先选举，后复制的思想，就是先选出一个Leader，然后一致复制的工作交给这个Leader去完成，充当协调者的角色。

上面我们讲到在Multi-Paxos中，如果Leader足够稳定的话，在接下来的执行中，phase 1 的请求其实是可以被省略的，那么接下来我们看一下被省略的整个流程。
这里round number需要+1,表示已经进入下一轮了。

对于更加简便的模型，无非就是C/S模型了，它们的关系如下，选一个server来当Leader。

Raft算法

接下来介绍一下核心算法Raft，这个算法的角色定义为三个：Leader, Follwer, Candidate，并分成三个子问题：Leader Election, Log Replication, Safety，这里的安全其实就是理解上的恢复，数据恢复就是安全。

阶段一：领导人选举

这时大家都是Follwer，需要选举一个Leader，timeout谁先到，就发请求给其他节点，这里可以看到S4先到，他自己先给自己投一票，发请求给其他四个节点，收到回复后，大家就知道这个集群谁是Leader了，之后每隔一定时间发送心跳包给Follwer，时刻保证老大的地位。发心跳包的时间肯定是小于各个节点timeout时间的。

阶段二：日志复制

在完成了选举之后，接下来来演示一下日志的复制，这里我们进行一个request，注意只能通过leader来进行传输。S3在收到一个请求之后，会将消息放在本地，并未提交。如下图所示：

S3会向各个follwer发送一个心跳包，而此时消息是和心跳包一起传送的，收到之后也是放在本地，没有提交。

S3在收到各个节点的返回之后，这时消息就可以提交了。边框变成实线。

S3在提交之后，又发了确认请求，各个follwer收到之后，会对已经来过的消息进行提交，这样，就完成了一次完整的日志复制。

特殊情况：发生分区

在实际运行过程中，可能会发生集群分区，如下图所示，本来node B是leader，但是上半部分没有leader，所以上半部分出现选举，node C为leader。

有日志复制时，下半部分无法提交，因为不满足多数派的思想。
上半部分可以提交成功。


这里开始恢复，node C成为全局leader，重新把下半部分同步。

关于这个算法的完整演示，大家可以看这个网站。
好了，关于Paxos和Raft算法就说到这里，后面会进行分布式系统相关知识的分享，欢迎大家关注！