前言
我们之前讲述了 Paxos 一致性算法，虽然楼主尝试用最简单的算法来阐述，但仍然还是有点绕。楼主最初怀疑自己太笨，后来才直到，该算法的晦涩难懂不是只有我一个人这么认为，而是国际公认！
所以 Paxos 算法在 1990 就发表出来，但却得不到运用。真正的名声大噪还是在兰伯特使用 “更简单” 的方式重写了一篇论文才开始。
这些和今天说的 Raft 有什么关系呢？
答：Raft 也是一个一致性算法，和 Paxos 目标相同。但他还有另一个名字：易于理解的一致性算法。
也就是说，他的目标就是成为一个易于理解的一致性算法。以替代 Paxos 的晦涩难懂。
那我们就开始讲讲 Raft 算法吧！
1. 什么是 Raft 算法
首先说什么是 Raft 算法：Raft 是一种为了管理复制日志的一致性算法。
什么是一致性呢？
Raft 的论文这么说的：一致性算法允许一组机器像一个整体一样工作，即使其中一些机器出现故障也能够继续工作下去。
这里的一致性针对分布式系统。
什么是管理日志呢？
一致性算法是从复制状态机的背景下提出的，复制状态机通常都是基于复制日志实现的，这个日志可以理解为一个比喻，相当于一个指令。
关于状态机的描述：
多个节点上，从相同的初始状态开始，执行相同的一串命令，产生相同的最终状态。实际上，与其说是一致，其实可以泛化为分布式的两个节点状态存在某种约束。
复制状态机通常都是基于复制日志实现的，保证复制日志相同就是一致性算法的工作了。
典型应用就是一个独立的的复制状态机去管理领导选举和存储配置信息并且在领导人宕机的情况下也要存活下来。比如 Chubby 和 ZooKeeper。
对于 Raft 更重要的应该是 易于理解。从 Raft 的论文题目就可以看出：In Search of an Understandable Consensus Algorithm (Extended Version)。这里的易于理解是相对于 Paxos 的，在他的论文中，和 Paxos 做了大量针对 易于理解 的对比和统计测试。
从楼主阅读论文的过程中来看，Raft 相较于 Paxos 确实更易于理解。为了提升可理解性，Raft 将一致性算法分解成了几个关键模块，例如领导人选举、日志复制和安全性。
而和一致性最相关的就是前面 2 个模块：领导人选举和日志复制。
2. 领导人选举
Raft 通过选举一个高贵的领导人，然后给予他全部的管理复制日志的责任来实现一致性。
而每个 server 都可能会在 3 个身份之间切换：
- 领导者
- 候选者
- 跟随者
而影响他们身份变化的则是 选举。
当所有服务器初始化的时候，都是 跟随者，这个时候需要一个 领导者，所有人都变成 候选者，直到有人成功当选 领导者。
角色轮换如下图：
角色变化图
而领导者也有宕机的时候，宕机后引发新的 选举，所以，整个集群在选举和正常运行之间切换，具体如下图：
image.png
从上图可以看出，选举和正常运行之间切换，但请注意， 上图中的 term 3 有一个地方，后面没有跟着 正常运行 阶段，为什么呢?
答：当一次选举失败（比如正巧每个人都投了自己），就执行一次 加时赛，每个 Server 会在一个随机的时间里重新投票，这样就能保证不冲突了。所以，当 term 3 选举失败，等了几十毫秒，执行 term 4 选举，并成功选举出领导人。
接着，领导者周期性的向所有跟随者发送心跳包来维持自己的权威。如果一个跟随者在一段时间里没有接收到任何消息，也就是选举超时，那么他就会认为系统中没有可用的领导者,并且发起选举以选出新的领导者。
要开始一次选举过程，跟随者先要增加自己的当前任期号并且转换到候选人状态。然后请求其他服务器为自己投票。那么会产生 3 种结果：
a. 自己成功当选
b. 其他的服务器成为领导者
c. 僵住，没有任何一个人成为领导者
注意：
- 每一个 server 最多在一个任期内投出一张选票（有任期号约束），先到先得。
- 要求最多只能有一个人赢得选票。
- 一旦成功，立即成为领导人，然后广播所有服务器停止投票阻止新得领导产生。
僵住怎么办？ Raft 通过使用随机选举超时时间（例如 150 - 300 毫秒）的方法将服务器打散投票。每个候选人在僵住的时候会随机从一个时间开始重新选举。
以上，就是 Raft 所有关于领导选举的策略。
3. 日志复制
一旦一个领导人被选举出来，他就开始为客户端提供服务。
客户端发送日志给领导者，随后领导者将日志复制到其他的服务器。如果跟随者故障，领导者将会尝试重试。直到所有的跟随者都成功存储了所有日志。
下图表示了当一个客户端发送一个日志给领导者，随后领导者复制给跟随者的整个过程。
image.png
4 个步骤：
- 客户端提交
- 复制数据到所有跟随者
- 跟随者回复
确认收到 - 领导者回复客户端和所有跟随者
确认提交。
可以看到，直到第四步骤，整个事务才会达成。中间任何一个步骤发生故障，都不会影响日志一致性。
4. 总结
总结一下本文吧：
Raft 算法如同他的论文名字一样：寻找一种易于理解的一致性算法，这里的 易于理解 是相对于 Paxos 的，的确，Paxos 实在过于复杂了。
而如何实现易于理解？
答：Raft 将一致性算法分成了2部分：领导选举，日志复制。
领导选举基于一个随机的时间来保证不会冲突（如果冲突的话）。
而日志复制则类似于 2PC。
通常 5 个节点，只要不超过 2 个节点死亡都不会影响系统的运行。保证了系统的可用性，通过领导者的日志复制，实现了系统的一致性。
似乎 CAP 定理已经不起作用了，当然这又是一个重大的话题。
最后，以 Raft 论文的结尾结束本位：
算法的设计通常会把正确性，效率或者简洁作为主要的目标。尽管这些都是很有意义的目标，但是我们相信，可理解性也是一样的重要。在开发者把算法应用到实际的系统中之前，这些目标没有一个会被实现，这些都会必然的偏离发表时的形式。除非开发人员对这个算法有着很深的理解并且有着直观的感觉，否则将会对他们而言很难在实现的时候保持原有期望的特性。
