分布式共识（Raft）问题研究

背景

随着云计算的发展，分布式系统已是几乎全部中大型系统的架构选择。在分布式系统中，原先单机系统中简单的问题变得复杂。如锁的实现由单进程多线程内部的锁变为分布式锁，分布式数据库中如何保证集群数据一致性，或者更准确的说，集群如何达成共识。

对于分布式系统，必须有一个指挥官对系统进行集中控制，指挥系统各部件协同工做，否则你们各干各的，最终确定是乱套了。而这个指挥官若是是单机部署的，又会出现单点问题，因此指挥官也必须集群部署，并且要从集群中选出一个大将军做为系统的指挥官，当这个大将军挂掉的时候，系统能选择新的大将军接管系统。

本文要探讨的分布式共识问题，主要是探讨大将军如何选择，以及它如何指挥系统协同工做。这个大将军，在分布式系统中，称做分布式应用程序协调服务，业界比较流行的有Zookeeper和ETCD等。

拜占庭将军问题

说到分布式一致性问题，不得不提的是拜占庭将军问题。拜占庭将军问题（Byzantine failures），是由莱斯利·兰伯特提出的点对点通讯中的基本问题。含义是在存在消息丢失的不可靠信道上试图经过消息传递的方式达到一致性是不可能的。
因为拜占庭问题须要考虑在有叛徒和敌方间谍的状况，问题比较复杂，根据信息系统通讯的现状，主要是主机挂掉或网络中断的状况，而不考虑恶意伪造消息，所以对一致性的研究通常假设信道是可靠的，或不存在本问题。

推选大将军

分布式系统的第一步，是要选出大将军做为系统指挥官，基于简化的拜占庭将军模型（即没有叛徒和间谍，但通讯兵可能被暗杀），首先咱们先来看下将军们如何选举出大将军。

假设有A、B、C三个指挥官，他们知足如下条件：

1. 指挥官个数大于等于3，且为奇数个。
2. 每一个指挥官都有一个随机计时器叫选举计时器 election timeout ，时间一到，这位将军就发起一轮推举大将军的活动，自荐为大将军候选人，并派出通信兵，询问其余指挥官是否赞成推举本身为大将军，同时重置选举计时器等待你们的回复。
3. 其余指挥官收到推举大将军的信息后，若是他没有推举过大将军，就赞成此请，由通信兵回复，并重置本身的选举计时器。
4. 每一个指挥官每轮只能赞成一次。
5. 若是候选人收到大多数（超过半数）指挥官赞成，则此指挥官成为大将军。
6. 成为大将军后，大将军经过心跳计时器 heatbeat timeout 向个指挥官下达做战命令。
7. 若是某位指挥官的选举计时器结束时，推举尚未成功，则本轮推举失败，取消全部指挥官候选人资格，重复执行上述第一步，直到推举成功为止。
8. 选举成功后，每位指挥官维护一个心跳计时器，若是计时结束时，尚未收到大将军的命令，则认为大将军阵亡，从新启动推举活动。

这就是Raft共识算法选主 Leader Election 的过程。从拜占庭将军的故事映射到分布式系统上，每一个将军至关于一个分布式网络节点，每一个节点有三种状态：Follower（指挥官），Candidate（候选人），Leader（大将军），状态之间是互相转换的。

注：

1. 选举计数器的时长设置，每一个指挥官不同，通常为150ms-300ms，这样能够避免你们的计时器一块儿结束。

大将军发布命令

大将军发布命令后，须要等大多数（超过一半）的指挥官回复收到命令，命令才算发布成功。对应到Raft共识算法，这就是复制日志 Log Replication 。

1. 大将军发布命令，这是命令为未确认 Uncommitted 状态。
2. 通讯兵把命令发送各指挥官。
3. 指挥官收到命令后，保存命令，状态也是未确认，并回复。
4. 当大将军收到多数指挥官回复时，任务命令发送成功，把命令状态修改成已确认 Committed。
5. 大将军再次向各指挥官发送确认消息。
6. 各指挥官把消息状态改完已确认。

以上主要以通俗的方式描述了下Raft共识算法的大体流程，详细的流程及异常处理，网络有不少的文章，这里再也不重复。

参考资料：
共识算法：Raft
Understandable Distributed Consensus
The Raft Consensus Algorithm