在猪爸爸的努力下，泥坑银行终于能高效正常的运作了，但猪爸爸一直比较担心海盗岛那边的网点，因为他总是担心跨海的通讯会因为极端情况出现问题。果不其然，一个雷雨交加的晚上，海盗岛的发电站被击中，整个岛处于停电状态，海盗岛的网点没法正常工作了。虽然狗爷爷尽了很多努力，让海盗岛重新供电也花了一天时间。
第二天，猪爸爸去见了兔小姐：
Problem
这里， 其实就是一个集群成员变更常见的问题，当我们添加或者删除节点的时候，如何让其他的节点知道成员变更了。最通常的做法，可能就是通过一个全局的协调器，譬如 zookeeper 或者 etcd 这种的，做一个 Two Phase（2 PC） 的变更，但这样其实是有问题的，先不说 2 PC 一些 corner case 需要处理，整个过程还可能会导致暂时的服务不可用，虽然这个时间在多数情况下面可能比较短，所以 Raft 这边采用了另外一种做法，我们继续说明。
Add/Remove one Node
在 Raft 的博士论文里面，当 Leader 收到 Configuration Change 的消息之后，它就将新的配置（后面叫 C-new，旧的叫 C-old） 作为一个特殊的 Raft Entry 发送到其他的 Follower 上面，任何节点只要收到了这个 Entry，就开始直接使用 C-new。当 C-new 这个 Log 被 committed，那么这次 Configuration Change 就结束了。当在 TiKV 以及 etcd 里面，我们并没有使用这种方式，只有当 C-new 这个 Log 被 committed 以及被 applied 之后，节点才知道最新的 Configuration 的情况。这样做的方式是比较简单，但需要注意几点：
- 当 Log 里面有一个 Configuration Change 还没有被 committed，不允许接受新的 Configuration Change 请求，主要是为了防止出现多 Leader 情况。
- 如果只有两个节点，需要移除一个节点，如果 Leader 在发起命令之后，另一个节点挂了，这时候系统没法恢复了。
Snapshot
好了，我们继续回到小镇银行这边，兔小姐跟猪爸爸选好了新的场地 - 森林小径，然后就准备开始海盗岛的网点替换工作了。但这时候，兔小姐突然想到一个严重的问题：
Snapshot 虽然简单，但需要注意，假设 3 个节点，然后新加入了一个节点，如果 Leader 在给新的 Follower 发送 Snapshot 的时候，另一个 Follower 当掉了，这时候整个系统是没法工作了，只有等 Follower 完全收完 Snapshot 之后才能恢复。为了解决这个问题，我们可以引入 Learner 的状态，也就是新加入的 Learner 节点是不能算 Quorum 的，它不能投票。只有 Leader 确认这个 Learner 接受完了 Snapshot，能正常同步 Raft Log 了，才会考虑将其变成正常的可以 Vote 的节点。
Joint Consensus
虽然上面一次进行一个成员变更的方式已经能在生产环境中满足大部分情况，但还有一种 corner case 我们是没有办法解决的。假设现在我们有 3 个 IDC，用 A，B，C 来表示，每个 IDC 里面有两台机器，就是 A1，A2，B1，B2，C1，C2。现在有一个 Raft 副本在 A1，B1，C1 上面，这时候，如果我们发现 A1 压力比较大，要将副本转移到 A2 上面，那么有两种办法：
- 移除 A1，增加 A2
- 增加 A2，移除 A1
但无论是上面哪一种方法，都会有风险，譬如第一种，当 A1 移除之后，如果 B1 或者 C1 当掉，那么整个集群是不可用的。而对于第二种，A2 增加之后，如果这时候整个 IDC A 当掉，那么整个 Raft 集群也是不可用的了。也就是说，我们虽然将数据放在了 3 个 IDC 上面，但在一些情况下面，如果一个 IDC 整个当掉，都可能引起 Raft 集群不可用。
我们可以通过 Learner 的方式缓解这个问题，也就是先增加 A2，但 A2 是 Learner，只有 A2 完全追上了，我们才将 A2 给变成 Voter，然后在移掉 A1。但这个方式只是能减少不可用的概率，并不能完全防止，所以最好的做法就是支持 Joint Consensus 算法。
这个算法其实比较简单，相对于上面的一次成员变更的算法，它只引入了一个过渡状态，叫做 joint consensus。当一个 Leader 收到成员变更的请求的时候，他首先会将 C-old 和 C-new 都放在 joint consensus 里面（我们叫做 C-old-new），作为一个 Raft Log 发送给其他的 Followers。当节点收到 Log，不需要等待 Log 被 committed，就可以使用最新的 C-new 配置了，但这时候，仍然只有 C-old 里面的集群能进行 Vote。如果这时候 Leader 当掉了，新选出来的节点 要不在 C-old 里面，要不在 C-old-new 里面，因为我们前面没约定 C-old-new 这个 Log 必须 committed。但无论是哪一种 Leader，C-new 这边的集群都不可能单边决策的。
当 C-old-new 被 committed 之后，就进行了 joint consensus 状态，在这个状态里面：
- Log 会被复制到所有在两个 configurations 里面的节点上面；
- 在两个 configuration 里面的节点都可能被选为 Leader；
- 但只有 C-old 里面 majority 和 C-new 里面 majority 都同意，才能选出 Leader 和进行 Log 提交。
当进入 joint consensus 之后，Leader 就可以再次提交一个新的 C-new Raft Log，仍然是只要其他节点收到了这个 Log，就可以使用新的 Configuration 了，当 C-new 这个 Log 被 committed 了，那么 C-old 就没用了，不在 C-new 的节点就可以直接关闭。这套流程就能保证在任意时候，C-old 和 C-new 不会出现单边投票的情况。
虽然 joint consensus 很强大，但现在用的最多的仍然是一次成员变更的方法，毕竟很简单，而 joint consensus 我只在 LogCabin 中看到过，所以这里并没有很详细的介绍。一些 corner case 的处理大家可以直接去看论文了。
那没有 joint consensus，一些极端的 corner case 怎么办呢？可能就先忍忍呗，或者使用 5 副本，甚至用 7 副本。
小结
成员变更我认为算是 Raft 里面最难的概念，尤其是在 Raft 的 Paper 里面，重点就提到的是 joint consensus 算法，其实比较让人难以理解。这里其实就体现了一个工程上面的取舍，虽然我知道理论上面 100% 的事情怎么做，但为了更加简单，我可以稍微放低一点要求。
TiKV 和 etcd 现在都是没有用 joint consensus 的，但我们现在在开始添加 Learner，后面如果真的遇到了其他的 corner case，会不会考虑一下，没准也不是不可能的事情。
本次嘉年华上，我们很荣幸邀请到了作者唐刘来到现场为大家分享，本次分享将介绍 TiDB 如何使用 Raft 算法构建分布式可扩展的后端存储系统，以及 TiDB 在可靠性、可用性、性能等方面对 Raft 做的工程优化。
原文发布时间为：2017-11-16
本文作者：唐刘