6.3.3 成员变更问题
生产环境中，有很多集群节点变更的情况，譬如服务器故障需要移除副本、集群扩容增加副本等等。如果 Leader 选举过程中，集群成员变更了怎么办？
先假设有这么个 configuration（配置） 来管理所有的成员信息。
配置
配置是成员变更中的一个重要概念，用于说明集群由哪些节点组成，如图 6-21，由 Server 1、Server 2、Server 3 组成的集群配置就是 [Server1、Server2、Server3] 集合。
你可能会想到把“配置”当成 Raft 中的“特殊日志”。由此，成员动态变更的问题不就变成了配置日志一致性问题么？。
但成员变更有个特殊性，如果处理方式不当，可能会导致两个多数派（变更前的多数派 Cold（旧配置）和变更的多数派 Cnew（新配置））之间不存在相交的成员，这样就产生两个 Leader 在各自认为的“多数派”中工作的问题。
如图 6-21 所示，3 个节点被同时添加到集群，同时添加多个节点可能会造成 Server1 和 Server2 构成 Cold 的多数派，Server3、Server4 和 Server5 构成 Cnew 的多数派。
这两个多数派不存在相交的成员，所以有可能在一个日志索引上会提交两个不同的日志项，从而导致协议冲突，影响 Raft 的安全性。
图 6-21 成员变更的某一时刻 Cold 和 Cnew 中同时存在两个不相交的多数派
Diego Ongaro 在论文中提出了一种两阶段的成员变更方法：Joint Consensus（联合共识），但这种方式实现起来很复杂。其他研究人员就提出一种更简单的方案 —— 单成员变更（Single Server Changes）。
单成员变更的思路是既然同时提交多个会存在问题，那每次就提交一个成员变更，这样 Cold 的多数派和 Cnew 的多数派始终会有一个节点重叠，这样就不存在不相交的问题了，如果要添加多个成员，那就执行多次单成员变更。
使用单节点变更方式很容易枚举出所有情况，如图 6-22 所示，穷举集群奇/偶数节点下添加和删除一个节点的情况，如果每次只增加和删除一个节点，那么 Cold 的多数派和 Cnew 的多数派之间一定存在交集，也就说是在同一个 term 中，Cold 和 Cnew 中交集的那一个节点只会进行一次投票，要么投票给 Cold，要么投票给 Cnew，这样就避免了同一 term 下出现两个 Leader。
图 6-22 穷举集群添加节点的情况
目前绝大多数的 Raft 算法，例如 Etcd、Hashicrop Raft 都是使用单节点变更方法。联合共识的方案由于其复杂性和落地难度笔者就不再过多介绍，有兴趣的读者可阅读 Raft 论文。
