Raft集群如何实现动态成员变更？你知道吗？

成员变更

Raft 之所以受欢迎的一个重要因素是，它是面向生产而设计的，切实地解决了行业内 的痛点。Raft 并非只关注其算法的协商过程，对于成员变更也给出了规范的实现方法，而 这正是应用于生产所必需的。成员变更这一规范后来也被应用于其他共识算法中。

Raft 的 Leader 选举和事务协商都源于多数派思想，而多数派是相对于一个固定集合来说的，只有在固定集合中，多数派的数量才是恒定的。但是在实际场景中，我们会遇到很多情况需要变更集群成员。例如，替换掉那些发生故障的成员，或者增加成员数量，允许更多的成员发生故障。

集群成员的变更，自然导致多数派的数量也会随之变化。如果处理不当，可能会导致 两个“多数派”(变更前的多数派和变更后的多数派)之间不存在相交的成员，这样就会产生两个 Leader 在各自认为的“多数派”中工作的现象。因为这两个“多数派”不存在相交的成员，所以有可能在一个日志索引上会提交两个不同的日志项，从而影响 Raft 的安全性。

例如，存在一个由三个成员组成的集群，集群成员为 Cold={A, B, C}，现在需要上线 两个新成员，变更后的集群成员 Cnew={A, B, C, D, E}。在变更过程中，由于不能保证 Cnew 在五个成员中同时生效，便会出现如下图所示的场景。在 T1 时刻，成员 C、D、E 拥有 Cnew 的配置，成员 A、B 继续使用 Cold 的配置，此时可以形成两个多数派 Qold 和 Qnew 满足:

Qold ={A,B}:Qold ∈Cold

Qnew ={C,D,E}:Qnew ∈Cnew

两个多数派自然也可以选举出两个 Leader，这两个 Leader 都自认为能正常工作且都能正常完成事务协商。

通过引入一个物理配置来管理所有的成员信息，这是我们最容易想到的方案。为了让所有成员在同一时刻都能获取更新后的集群配置，可以选择集群停机后再更新配置。不否认这种做法是易于理解且有用的，但有很大的局限性。先不说集群停机时服务将不可用这个问题，将所有成员优雅关机就是一个大工程。

显然，通过关机并更新集群配置来完成成员变更是不能接受的，但问题还得解决。我们知道，在分布式环境中，让所有成员都认可某个配置，其本质就是共识问题。因此，解决该问题的方案只能是共识算法，因此可以考虑在 Raft 的基础上增加额外的机制进行变更成员，但是 Raft 的运行又依赖于固定的集合，而变更成员就是为了获得一个暂时固定的集 合，这就变成一个“先有鸡还是先有蛋”的问题。因此，不可能通过一次变更就能以原子方式更新所有成员的配置，在变更过程中，应该需要一个中间集合来接替“多数派”的工作。

联合共识

为了规范 Raft 成员变更的方案，Diego Ongaro 博士在论文中提出了联合共识 (Joint-Consensus)的概念。联合共识是指引入一个临时的“多数派”来保证算法的安全性，其被认为是基于多数派思想实现的共识算法的成员变更通用协议，被应用于某些 Paxos 的 实现中。

因为“鸡”和“蛋”之间的循环，一次性自动变更所有成员配置是不可能的，需要通过两个阶段来完成。通过两个阶段切换成员配置有很多方法。例如，可以在第一阶段禁用旧的成员配置，这样便不会再接收客户端请求，接着在第二阶段启用新的成员配置，除此之外，还可以使用前面介绍的停机更新成员配置的方法。这些方法简单、有效且都能保证算法的安全性，但 Raft 还是做出了其他选择。

对于共识算法，除了在变更过程中保证算法 的安全性之外，还希望其能实现以下基本要求:

• 任何时候(包括成员变更时)，集群都能提供完整的服务。

• 无论何种情况宕机重启后，集群都能正常选举 Leader 并正常运行。

为了在任何时候都能提供完整的服务，引入了一个中间状态，称为联合共识。处于联合共识的集群允许处理客户端的事务请求，但是需要通过比多数派更加严格的决策。

变更过程

为了方便描述，我们使用 Cold 表示旧的集群配置(旧的成员集合)，Qold 表示旧的成员集合中的多数派，Cnew 表示新的集群配置(新的成员集合)，Qnew 表示新的成员集合中的多数派，Cold,new 表示联合共识时的集群配置(旧的成员集合+新的成员集合)。

成员变更的过程由 Leader 发起，由 Leader 主导成员变更的过程。当 Leader 收到将 Cold 变更至 Cnew 的请求后，分两阶段完成成员变更。

(1)第一阶段，将 Cold,new 的配置发送给 Cold∪Cnew 的成员，获得多数派 Qold∪Qnew 的 支持即执行第二阶段。

(2)第二阶段，将 Cnew 的配置发送给 Cold∪Cnew 的所有成员，但只需要获得 Qnew 的支持则完成成员变更。

在成员变更过程中，一旦完成第一阶段，即处于联合共识的状态，对于任何操作，Cold 和 Cnew 都不能单方面地做出决定，这是为了保证算法的安全性。例如当提交一个日志项时， 需要同时获得 Qold 和 Qnew 的支持;在第二阶段的工作完成后，新的成员配置立即生效，后续的提案只需要获得 Qnew 的支持即可。

为了保证变更过程中的服务可用，在联合共识期间处理事务请求，需要保证:

• 将日志项分别发送至拥有 Cold 和 Cold,new 配置的所有成员

• 当提交一个日志项时，要求得到 Qold 和 Qnew 两个多数派的支持。

• 拥有任意一种配置的成员都可以晋升为 Leader。

协议模拟

有一个 Cold={A, B, C}的集群，需要变更为 Cnew={C, D, E}，如下图所示。

1. 在 T1 时刻，Leader 为成员 A，在收到成员变更的请求后，将 Cold,new 配置发送给 Cold ∪ Cnew 的成员。

2. 在 T2 时刻，Leader A 完成了第一阶段的工作，所有成员都批准了 Cold,new 配置， Leader A 开始处理第二阶段的工作。

3. 在 T3 时刻，Leader A 完成了第二阶段的工作，所有成员都批准了 Cnew 配置。

4. 在 T4 时刻，成员 A、B 发现新配置中不包含自己，因此选择主动下线。在没有 Leader 的情况下会重新选出 Leader。

新书预售享7.5折

尽管联合共识能有效的解决成员变更面临的问题，但是由于在工程实现中仍有难度。值得高兴的是，有一本全面、系统的剖析共识算法的书籍《深入理解分布式共识算法》即将出版。书中不仅详细描述了Raft的协商过程，对成员变更、工程实现都做了详细的解说，包含了：

• 单个成员变更

• 对称网络分区、非对称网络分区

• 线性一致性的实现

• 并行协商的优化

• 安全性证明

• Raft工程实现

• ....

尽管这些内容已经足够吸引人了，但这仅仅是书中的冰山一角，全书涵盖了当前流行的大部分共识算法和分布式事务解决方案，例如：Paxos、ZAB、Raft、Fast Paxos、EPaxos、以及各类Paxos的变种算法。

除了内容全面，本书特色包含了：

1. 多维度阐述：对每一种算法都按照“背景知识 → 运行过程 → 算法模拟 → 证明脉络”的多维度境界，思路清晰，易于理解。

2. 对比总结：针对各种算法总结对比，分析各自的优缺点，并结合当下流行的经典类库和中间件的源码，逐步印证算法的实现过程。

3. 注重实践：精心准备了20多道练习题，可以帮助读者进一步加深对相关算法的理解。

4. 图文并茂：精心绘制120余幅示意图，帮助读者更直观地理解各种算法的运行过程。

5. 视频教学：对重点和难点内容有针对性地录制了教学视频，帮助读者高效、直观地学习

本书赞誉

本书获得了多位Apache和蚂蚁金服的多位专家等人力荐。