概述
有一些分布式经验的同学应该都多少听过一些分布式的概念，没有听过也应该是直接或者间接接触过，例如搭建了一个 MongoDB 的集群，会有不同的配置方式，其中有一种叫做 Replica Set 的方式：
也就是说假设你有三台机器，三台机器共同存储了你的数据，当你的客户端想操作数据的时候，不用每台机器都单独得去写一遍，反之则是写到其中一台叫做 Primary 的机器上，然后再将 Primary 的操作记录（log）分发到其他两台机器（Secondary），然后在 Secondary 上重做操作记录，从而让你的操作在所有的机器上生效。
那么这里就有个很严肃的问题来了，既然有 3 台机器，那么谁来当 Primary？要想实现这一步可能还比较容易，大家猜拳决定呗，每个人随机出一个数字，谁大谁当，好办！那么问题又来了，如果一个人出了一个数之后，发现它是最大的，但是它又马上挂掉了怎么办？还有，如果大家的交流不畅，A 可以和 B 通信，但是 A 和 C 不能通信怎么办，类似的问题还有很多，其他归纳起来就是所谓的 CAP 无法全被满足。
为了提高整体体验，于是就有了各种共识算法，比特币的 POW 其实也是一种，但是，今天要聊的是 Raft 共识算法，Raft 共识算法被越来越多应用接受，用于替代 paxos。
Raft 共识算法
在开始 Raft 算法介绍之前，先来介绍一个简单的场景，类似于 Redis，就是一个 Client 往 Server 中写入一个值：site=https://liqiang.io ，那么在单机部署的情况下应该是这样的：
这个很简单，Client 只要根据调用 Server 是否成功即可判定是否数据写入成功，当然，你得保证你 Server 的实现逻辑是正确的，如果 Server 自身都是错误的，那么就没啥共识可谈了。然后，当负载变大之后，你决定增加 Server 了，问题也就接着来了：
Server 的代码要怎么写？于是乎，Raft 算法就纳入了考虑，在 Raft 算法中，Server 统称为 Node，Node 有三个状态，分别是：
- Leader：全局只有一个
- Follower：就是普通的成员，听从 Leader 吩咐
- Candidate：从 Follower -> Leader 的中间状态，可能成为 Leader，也可能退回 Follower
Raft 共识算法开始的时候，所有的节点都是 Follower，而 Raft 算法的协议就是如果一个 Follower 在一个时间区间内（150ms - 300ms 之间的随机数）没有收到 Leader 的心跳，那么就可以成为 Candidate。那么在这条规则之下,总会有一个 Follower 因为时间随机得短先行行动，成为 Candidate，从而告知其他 Follower：
如果 B 和 C 在接到 A 的通知之前自己的随机时间还没超时，那么都会回应 A：”行吧，就你了”，这样 A 就顺理成章得成为了 Leader。
当然，有时可能有的人反应比较慢，或者说有的人根本就没听到 A 的呼喊，所以 A 是怎么也收不到他们的回应的，然而，没关系，在 Raft 算法中要求，只要超过 1/2 的节点认可，那么就可以了。也就是说 3 节点里面只需要 2 个节点（包括自己）认可，5 个节点里面只要有 3 个节点认可就够了，因为这样可以保证全局只有一个 Leader!
这个过程就是 Leader 选举啦!
那么这里面还有些问题需要解释，第一个就是当 A 准备成为 Candidate 的时候，那么不巧 B 也准备成为 Candidate，那么怎么办，这种场景在 3 节点上没啥好说的，因为谁争取到了 C 的票谁就是 Leader 了，咱们来看个有趣的，就是 4 个节点的时候：
然后更有趣的就是 C 和 D 一个回一个：
因为在 Raft 中还有一个递增的选举编号，表示这是第几轮选举，因为这时大家都是从一致的状态开始选举的，所以轮数（Term）都是一致的，而每个节点每轮只能发表一次，所以 C 和 D 互相回了一个没问题，这种情况下的话，会出现的一个情况就是大家都不是 Leader 状态，其中：
- C 和 D：最后一次是收到 Candidate 的请求，所以重新开启了 Leader 的 Hearbeat 时间倒计时（150ms-300ms）
- A 和 B：则是陷入了等待大多数节点 Candidate 的响应的倒计时中
在这个时候，A、B、C 和 D 四个节点中只要有谁的倒计时先到 0，那么就会成为 Candidate 向其他节点发出下一轮的选举，直到被大多数节点认可成为 Leader。
所以注意到这里节点的状态都是通过倒计时来完成的，因此倒计时在 Raft 中的作用很重要。同时 Leader 和 Follower 之间会有心跳进行通信，一旦没有收到心跳，就会马上造反，出来选举搞事情。因此，节点之间的网络很重要！
复制集
有了 Leader 之后又有什么用呢？还是之前那个例子，当一个 Client 要想往 A、B 和 C 中写入数据的时候，这时可以先找到 Leader，然后先在 Leader 中写入数据（实际还未提交，只是 pending），并且由 Leader 生成一条操作日志：
然后 A 再将这个操作日志伴随心跳传递给 B 和 C，B 和 C 接收到之后，再根据这个操作日志在自己的数据中执行一遍，从而达到和 A 一样的状态，然后告诉 A 他们可以了：
当大多数的节点（超过 1/2）都接受这个操作日志之后，节点 A 就提交，那么写入的数据就持久化保存在 A 中了，然后 A 再告诉 B 和 C 提交了，B 和 C 再提交，这样就将数据持久化到大多数节点中了。
这里需要注意到的一点就是，Leader 节点 A 是在往 Follower 的 HeartBeat 中发送操作日志的，并且要等到大多数的节点都认可之后才告诉 Client OK 的。这也就是说 Client 最多要等待两个 Heartbeat 的周期才能收到 Server 的响应，这点很重要！
如果在使用的过程中，有部分节点失联了怎么办？这个在 Raft 中也挺好处理的，还是坚持大多数的原则，假设有 5 个节点，因为是 A、B、C、D 和 E。A 和 B 和其他小伙伴失联了，但是他们之间是好的，那么有两种情况：
如果 A 和 B 之间有一个原来是 Leader
假设 A 是 Leader，那么 A 就可以接受 Client 的请求，但是因为得不到大多数节点的响应，所以所有的操作都是 未提交 的，因为至多也就 2 票，无法满足大多数。
而 C、D 和 E 在 Leader A 失联之后，因为可以满足大多数的情况，所以假设 C 成为了 Leader，所以也可以接收 Client 的请求，并且因为可以得到大多数人的认可，所以也可以提交数据。
当这样持续一段时间之后，如果 A 和 B 永远不回来了，那么也没他们什么事了，一切都很正常。如果有一天 A 和 B 回来了，那么因为 C、D 和 E 的选举 ID 会比 A 和 B 高，所以 C 就会将 A 和 B 失联期间的所有操作日志都丢给他们，让 A 和 B 重做这些日志，从而恢复到 C、D 和 E 一样的状态。
如果 A 和 B 之间没有任何一个是 Leader
那么 A 和 B 之间就会发生选举，但是怎么也产生不了 Leader，因为永远也不可能得到大多数人的认可，这样下去的话，当有一天 A 和 B 和其他节点又恢复联系之后，这时就有点意思了，这里按理说 A、B 的选举轮数应该会比 C、D 和 E 高很多，毕竟他们没事就在那选举嘛，那么这个时候要不要让他们成为 Leader 呢？
这里有涉及到 Raft 的另外一条 Follower 的应答机制了，Follower 只有在选举轮数比自己存的高，并且目标节点的日志信息不比 Follower 旧的时候才会同意，那么很显然，除非在这期间 C、D 和 E 都没有作过更新，那么才会成立，否则那么还是必能成为 Leader 的。如果 C、D 和 E 都没更新过，那么让 A 和 B 其中一个做 Leader 也没什么问题。