分布式系统-4-Raft

上节知识准备：主从复制
论文：Raft-extended

前面聊到主从复制提高可用性，但是简单的主从复制需要解决的 “裂脑问题”：由于各种原因导致集群分成几个小集群，每个小集群都以为别的机器无法服务了，各自为主，无法提供正常的服务。解决办法也很简单，就是在一个主从集合中保证同时只有一个 Master 响应客户端的请求。面我们来聊聊一致性算法：Raft。

在 90 年代出现 Paxos 一致性算法后，所有的一致性算法的发展和实践都是以此为基础，事实上 Paxos 相当难理解，它本质上时提出了一系列思路，需要工程师根据自己需求进行取舍来实现合适的一致性模型。而 Raft 的首要设计目标是保证一致性逻辑正确性的基础上，尽可能容易理解。

首先我们得明白作为一个复制状态机集群保障一致性的算法，需要解决什么问题：

1. 没有 Master 时需要选举出下一个 Master，且要保证同时只有一个 Master
2. 机器重连后的 log（状态机命令序列） 同步

在 Raft 中，一个集群的每个机器可能是 Leader，Follower 和 Candidate 三种之一的角色。Leader 负责跟客户端交互，Follower 负责接收 Leader 操作备份命令，而 Candidate 在集群中没有 Leader 时，准备竞选的角色。

每台机在不同的条件下在三种角色中切换来保证系统的一致性，那具体的是如何解决上面说的三个问题的？

问题一方案：

1. 集群的数量(sum) 必须是大于 1 的奇数。

2. 每个机器都启动一个定时器，当一定时间内没有收到来自 Leader 的消息，则视为 Leader 已不可用，从 Follower 转换成 Candidate，准备选举 Leader。

3. 选举过程中，每个机器只可选一个 Candidate，而且必须得到大于 sum/2 个投票才可当选为 Leader。

4. 当同时有两个 Candidate 竞选 Leader 时，有可能每个 Candidate 都拿不到多数选票，因为选举也有 timeout，而且是一定范围的随机，所以只要出现多个 Candidate，就简单的重置定时器而已。性能不一定最高，但简单且健壮。

问题二方案：

1. 对于一个集群来说，每次从无 Leader 到进行选举是一个阶段(Term)，所以在旧阶段失联的机器重连后，判断当前集群所在的阶段，若已落后，则无条件用 Leader 的 log 覆盖自己的，成为一个 Follower。

2. 所以在 Raft 中，只有 Leader 向 Follower 发送 log，这简化了复制过程，但在某些条件下，系统的复制性能会下降。

3. 对于每个客户端请求，只有在超过半数机器复制成功(log 写入成功)时，才能向客户端响应成功。

4. 同样在选举时，log 数量多的 Candidate 拥有更高的权重。

论文中详细讨论了 Raft 的 log 复制机制，如何保证各种条件下系统的安全性，动态更换一个集群的机器配置，log 压缩以及性能评估。

我们还准备一个循序渐进，文档丰富，环境友好的用 Raft 算法实现分布式 KV 数据库实验项目，实验二 Raft算法实现。