成员变更是一致性系统实现绕不开的难题，对于提升运维能力以及服务可用性都有很大的帮助。 本文从Raft成员变更理论出发，介绍了Raft成员变更和单步成员变更的问题，其中包括Raft著名的Bug。 对于Raft成员变更的工程实现上需要考虑的问题，本文给出了一些工程实践经验。分布式系统运行过程中节点经常会出现故障，需要支持节点的动态增加和删除。成员变更是在集群运行过程中改变运行一致性协议的节点，如增加、减少节点、节点替换等。成员变更过程不能影响系统的可用性。成员变更也是一个一致性问题，即所有节点对新成员达成一致。但是成员变更又有其特殊性，因为在成员变更的过程中，参与投票的成员会发生变化。如果将成员变更当成一般的一致性问题，直接向Leader节点发送成员变更请求，Leader同步成员变更日志，达成多数派之后提交，各节点提交成员变更日志后从旧成员配置（Cold）切换到新成员配置（Cnew）。因为各个节点提交成员变更日志的时刻可能不同，造成各个节点从旧成员配置（Cold）切换到新成员配置（Cnew）的时刻不同。可能在某一时刻出现Cold和Cnew中同时存在两个不相交的多数派，进而可能选出两个Leader，形成不同的决议，破坏安全性。
图1 成员变更的某一时刻Cold和Cnew中同时存在两个不相交的多数派如图1是3个节点的集群扩展到5个节点的集群，直接扩展可能会造成Server1和Server2构成老成员配置的多数派，Server3、Server4和Server5构成新成员配置的多数派，两者不相交从而可能导致决议冲突。由于成员变更的这一特殊性，成员变更不能当成一般的一致性问题去解决。为了解决这个问题，Raft提出了两阶段的成员变更方法Joint Consensus。Joint Consensus成员变更让集群先从旧成员配置 切换到一个过渡成员配置，称为联合一致成员配置（Joint Consensus），联合一致成员配置是旧成员配置 和新成员配置 的组合 ，一旦联合一致成员配置 提交，再切换到新成员配置 。
Leader收到成员变更请求后，先向 和 同步一条 日志，此后所有日志都需要 和 两个多数派的确认。 日志在 和 都达成多数派之后才能提交，此后Leader再向 和 同步一条只包含 的日志，此后日志只需要 的多数派确认。 日志只需要在 达成多数派即可提交，此时成员变更完成，不在 中的成员自动下线。成员变更过程中如果发生Failover，老Leader宕机， 中任意一个节点都可能成为新Leader，如果新Leader上没有 日志，则继续使用 ，Follower上如果有 日志会被新Leader截断，回退到 ，成员变更失败；如果新Leader上有 日志，则继续将未完成的成员变更流程走完。Joint Consensus成员变更比较通用且容易理解，但是实现比较复杂，之所以分为两个阶段，是因为对 与 的关系没有做任何假设，为了避免 和 各自形成不相交的多数派而选出两个Leader，才引入了两阶段方案。如果增强成员变更的限制，假设 与 任意的多数派交集不为空， 与 就无法各自形成多数派，则成员变更就可以简化为一阶段。 实现单步的成员变更，关键在于限制 与 ，使之任意的多数派交集不为空。方法就是每次成员变更只允许增加或删除一个成员。
增加或删除一个成员时的情形，如图3所示，可以从数学上严格证明，只要每次只允许增加或删除一个成员， 与 不可能形成两个不相交的多数派。因此只要每次只增加或删除一个成员，从 可直接切换到 ，无需过渡成员配置，实现单步成员变更。单步成员变更一次只能变更一个成员，如果需要变更多个成员，可以通过执行多次单步成员变更来实现。单步成员变更理论虽然简单，但却埋了很多坑，实际用起来并不是那么简单。Raft单步成员变更的问题，最著名的莫过于Raft著名的正确性问题，另外单步成员变更还有潜在的可用性问题。Raft单步变更过程中如果发生Leader切换会出现正确性问题，可能导致已经提交的日志又被覆盖。Raft作者（Diego Ongaro）早在2015年就发现了这个问题，并且在Raft-dev详细的说明了这个问题[1]。下面是一个Raft单步变更出问题的例子, 初始成员配置是 这4节点，节点 和 要加入集群, 如果中间出现Leader切换, 就会丢失已提交的日志：
：节点 的成员配置为 ；
：节点 在 选出 为Leader， 和 为Follower；
：节点 同步成员变更日志 ，只同步到 和 ，未成功提交；
：节点 宕机；
：节点 在 被选为Leader， 和 为Follower；
：节点 同步成员变更日志 ，同步到 、 、 ，成功提交；
：节点 同步普通日志 ，同步到 、 、 ，成功提交；
：节点 宕机；
：节点 在 重新选为Leader， 和 为Follower;
：节点 同步本地的日志 给所有人，造成已提交的 和 丢失。
为什么会出现这样的问题呢？根本原因是上一任Leader的成员变更日志还没有同步到多数派就宕机了，新Leader一上任就进行成员变更，使用新的成员配置提交日志，之前上一任Leader重新上任之后可能形成另外一个多数派集合，产生脑裂，将已提交的日志覆盖，造成数据丢失。Raft作者在发现这个问题之后，也给出了修复方法。修复方法很简单, 跟Raft的日志Commit条件类似：新任Leader必须在当前 提交一条日志之后，才允许同步成员变更日志。也即Leader在当前 还未提交日志之前，不允许同步成员变更日志。按照这个修复方法，最简单的实现就是Leader上任后先提交一条no-op日志，然后再同步成员变更日志。这条no-op日志可以保证跟上一任Leader未提交的成员变更日志至少有一个节点交集，这样可以发现上一任Leader的日志是旧的，从而阻止上一任Leader重新选为Leader，进而阻止了脑裂的产生。对应上面这个例子，就是 当选Leader后必须先提交一条no-op日志，然后才能开始同步 和 ，以便能发现 的日志是旧的，从而阻止 当选Leader。另一种方法是使用Joint Consensus成员变更，没有这样的正确性问题。单步成员变更每次只能增加或者减少一个成员，在做成员替换的时候需要分两次变更，第一次变更先将新成员加入进来，第二次变更再将老成员删除，中间如果如果网络分区，有可能会导致服务不可用。考虑 、 、 三个成员部署在三个机房，现在因为 发生故障要将 替换为同机房的 。按照单步成员变更， 要先变为 ，再变为 。中间经历的4节点 的状态, 有可能在出现二分的网络分区( )时导致整个集群不可用。因为 与 位于同一机房，这种二分网络分区的情况在实际情况中还是不容忽视的。怎么解决这个问题呢？一种方法是做成员替换的时候，先删除老成员，再加入新成员，即 先变为 ，再变为 ，这样可以避免 的状态。另一种方法是使用Joint Consensus成员变更， 先变为 ，再变为 ，也不会经历 的状态。Raft成员变更的理论虽简单，但实际工程实现上还是有很多地方要考虑。因为Raft单步成员变更有正确性问题及可用性问题，工程上建议尽量使用Joint Consensus成员变更，这里主要讨论一些Joint Consensus成员变更工程实现上必须考虑的问题。因为Raft需要严格保证顺序，而新成员上还没有任何数据，因此新成员加入集群后需要先同步数据才能正常工作。工程实现时就有两种选择，一种是让新成员先加入再同步数据，另一种是先给新成员同步数据，同步完成后再加入。这两种方式各有利弊。
| 优点 | 缺点 |
| 新成员先加入再同步数据 | 简单并且快速，能加入还不存在的成员 | 可能降低服务的可用性 |
| 新成员先同步数据再加入 | 不会影响服务可用性 | 复杂并且较慢，不能加入还不存在的成员 |
表1 新成员先加入再同步数据和先同步数据再加入的优缺点
新成员先加入再同步数据，成员变更可以立即完成，并且因为只要大多数成员同意即可加入，甚至可以加入还不存在的成员，加入后再慢慢同步数据。但在数据同步完成之前新成员无法服务，但新成员的加入可能让多数派集合增大，而新成员暂时又无法服务，此时如果有成员发生Failover，很可能导致无法满足多数成员存活的条件，让服务不可用。因此新成员先加入再同步数据，简化了成员变更，但可能降低服务的可用性。新成员先同步数据再加入，成员变更需要后台异步进行，先将新成员作为Learner角色加入，只能同步数据，不具有投票权，不会增加多数派集合，等数据同步完成后再让新成员正式加入，正式加入后可立即开始工作，不影响服务可用性。因此新成员先同步数据再加入，不影响服务的可用性，但成员变更流程复杂，并且因为要先给新成员同步数据，不能加入还不存在的成员。成员变更日志本身是为了改变成员配置，处在成员配置变更的临界点上，因此成员变更日志使用什么配置就很关键。
| 成员变更日志 | 使用的成员配置 |
| 日志 | 配置 |
| 日志 | 配置 |
表2 Joint Consensus成员变更日志使用的成员配置对于Joint Consensus成员变更，成员变更日志使用什么配置是确定的。 日志使用联合一致成员配置 ，需要老成员配置 和新成员配置 两个多数派确认才能提交， 日志使用新成员配置 ，只需要新成员配置 的多数派确认即可提交，但 日志也会同步给老成员配置 ，主要是为了让 中不在 中的成员自动退出。成员变更通过成员变更日志来完成，让各成员对成员配置达成一致，但成员变更日志与普通日志不同，并不一定要等到提交后Apply生效。
| Leader | Follower |
| Joint Consensus成员变更 | 开始同步成员变更日志之前 | 成员变更日志持久化完成后 |
对于Joint Consensus成员变更，成员变更日志什么时候生效是确定的。在Leader上开始同步成员变更日志之前就需要生效，在Follower上成员变更日志持久化完成后就需要生效。成员变更日志还未提交就先生效了，因此在Leader切换后可能会回滚。考虑这样一种情况，成员变更减少了成员数量，进而减小了多数派集合，而更小的多数派更容易达成，造成成员变更之后的日志比之前的日志先达成多数派。按照Raft论文中的commitIndex的推进算法：If there exists an N such that N > commitIndex, a majority of matchIndex[i] ≥ N, and log[N].term == currentTerm:
set commitIndex = N
一条日志达成多数派就往前推进commitIndex至该日志，如果该日志之前有日志按照老成员配置还未达成多数派，也一并提交了。这种情况是否会出问题呢？实际上并不会，因为成员变更之后，已经有日志使用新成员配置提交了，不在新成员配置中的节点不可能再当选Leader了，进而不会覆盖之前的日志，因此就算之前的日志按照老成员配置未达成多数派也可以安全的提交。hashicorp raft的实现还是严格按序提交的，即只有前面的日志都达成多数派之后才能提交。Raft只能在大多数成员存活的情况下才能正常工作，实际可能会遇到只有少数成员存活的情况，这个时候要怎么恢复服务呢。因为只有少数成员存活，已经不能达成多数派，不能写入数据，也不能做正常的成员变更。需要提供一个强制更改成员配置的接口，通过它设置每个成员的成员配置列表，便于从大多数成员故障中恢复。比如只剩一个成员S1存活的时候，强制更改成员配置设置成员列表为{S1}，这样形成一个只有S1的成员列表，让S1继续提供读写服务，后续再调度其他节点通过成员变更加入。通过强制修改成员列表，可以实现最大可用模式。单步成员变更虽然不推荐在工程中使用，这里还是总结一下单步成员变更的一些工程实践，供研究讨论。对于单步成员变更，成员变更日志是使用新成员配置 还是老成员配置 呢？实际上单步成员变更日志无论使用新成员配置 还是老成员配置 都不会破坏 与 的多数派至少有一个节点相交，因此单步成员变更日志既可以使用新成员配置 也可以使用老成员配置 ，两种方式各有利弊。
| 优点 | 缺点 |
| 单步成员变更日志使用老成员配置 | 可避免单步成员变更的正确性问题，增加成员时可能只需要更小的多数派集合 | 减少成员时可能需要更大的多数派集合 |
| 单步成员变更日志使用新成员配置 | 需要处理单步成员变更的正确性问题，减少成员时可能只需要更小的多数派集合 | 增加成员时可能需要更大的多数派集合 |
表4 单步成员变更日志使用老成员配置和使用新成员配置的优缺点单步成员变更日志使用老成员配置 ，可以避免单步成员变更的正确性问题，因此可以省略掉Leader上任后的no-op日志，同时在增加成员时可能只需要更小的多数派集合，但在减少成员时可能需要更大的多数派集合。单步成员变更日志使用新成员配置 ，需要Leader上任后先提交一条no-op日志，以避免单步成员变更的正确性问题，同时在减少成员时可能只需要更小的多数派集合，但在增加成员时可能需要更大的多数派集合。单步成员变更日志不管使用新成员配置还是老成员配置，最好都同步给新老成员配置中的所有成员，这样在增加成员时可以让新成员迟早收到通知，在减少成员时也可以让被删除的成员收到通知而自动退出。Raft论文中单步成员变更日志使用新成员配置 ，etcd中单步成员变更日志使用老成员配置 。
| Leader | Follower |
| 单步成员变更，使用新成员配置 | 开始同步成员变更日志之前 | 成员变更日志持久化完成后 |
| 单步成员变更，使用老成员配置 | 理论上只需要在下一次成员变更开始之前生效，实际一般在成员变更日志提交后就生效 |
对于单步成员变更，如果成员变更日志使用新成员配置，则与Joint Consensus成员变更一样，Leader上开始同步成员变更日志之前就需要生效，在Follower上成员变更日志持久化完成后就需要生效。如果成员变更日志使用老成员配置，理论上只需要在下一次成员变更开始之前生效即可，但实际为了让新加入的节点尽快开始服务，一般在成员变更日志提交后就生效。Raft论文中单步成员变更日志使用新成员配置 ，本地持久化完成就生效；etcd中单步成员变更日志使用老成员配置 ，提交后再生效。Raft提供了Joint Consensus成员变更和单步成员变更，极大的推动了成员变更在工程中的应用。本文总结了一些Raft单步成员变更的问题，以及成员变更的工程实践。Joint Consensus通用并且不容易踩坑，一阶段成员变更坑比较多。工程上建议尽量使用Joint Consensus成员变更。阿里云存储-基础系统&协同服务团队，负责自研的飞天分布式协同基础服务-女娲，产品支持着阿里云的计算、存储、网络等几乎所有云产品，支持从单地域到全球化各个规模下的数据协同。阿里云存储是目前国内规模最大的云存储服务商，拥有全球云计算厂商中最完整的存储产品线，包括块存储、对象存储、文件存储等存储系列。团队致力于分布式系统中最核心的分布式一致性技术的研发，在这里，你会获得实现超大规模分布式系统核心技术的经验，在个人专业上成长的同时在中国云计算的发展史上留下自己的印记。负责基于Paxos、Raft等分布式一致性算法打造分布式协调、分布式存储、分布式锁、消息队列等基础服务。
负责支持着阿里云的计算、存储、网络等几乎所有云产品。
探索EPaxos等无主的分布式一致性算法的应用与落地，致力于打造分布式一致性技术中台。
负责支持从单地域到全球化各个规模下的数据协同。
本科及以上学历，硕士博士优先，计算机相关专业为佳，毕业时间在2021年11月和2022年10月之间。
良好的计算机专业基础，熟练掌握数据结构、算法、操作系统等知识。
优秀的编程能力，熟练使用C++/Java编程开发技能。
对技术有激情，喜欢钻研，具备独立工作能力和解决问题的能力，善于沟通，乐于合作，勤于总结。
加分项：
2022年毕业的应届生、实习生、社招全部都要，感兴趣的童鞋可联系xiangguang.yxg@alibaba-inc.com相关链接
[1]https://groups.google.com/g/raft-dev/c/t4xj6dJTP6E
电子书免费下载
《Apache RocketMQ 从入门到实战》
《RocketMQ 技术内幕》作者推出，由浅入深地介绍了RocketMQ的架构与实现，并总结了多年线上超大规模集群开发运维经验。通过本书，不仅能够掌握分布式消息平台的设计原理，对线上疑难问题排查分析、性能调优与架构设计也大有帮助。
点击“阅读原文”，立即下载吧~