Raft 集群成员变更为什么需要联合共识？

简化版

若成员列表从旧配置直接切到新配置，不同节点切换时刻不同，旧、新多数派可能不相交并分别选主或提交。联合共识用 C_old,new 过渡：选举和提交同时取得旧配置多数与新配置多数，再提交最终 C_new。这样变更前后的决议链保持交集，成员变更本身也能安全复制和恢复。

详细版

Leader 先把联合配置作为日志条目复制；该配置生效后，所有决议满足双多数。联合配置条目提交后，再写只包含新成员的 C_new 配置。节点收到 C_new 条目后按新配置计算多数派，该条目最终由新配置多数提交。新节点应先作为 learner 追平，移除 Leader 可先转移领导权。

某些 Raft 实现采用“一次只改变一个 voter”的简化协议，而非完整联合共识。使用者必须遵守具体库的成员变更规则，不能把两种证明混用，也不能同时提交多个配置变更。失去旧 quorum 时不能依靠联合共识自行恢复，需灾难恢复流程。

完整版教学

一、直接切换的反例

旧配置 {A,B,C}，新配置 {C,D,E}。旧多数 {A,B} 与新多数 {D,E} 没有交集。若部分节点先使用新配置，两边可能各自决定冲突日志。

C_old majority: A+B
C_new majority: D+E
no intersection -> unsafe direct transition

问题不在成员数，而在两个决议集合是否相交。

二、联合配置是什么

C_old,new 同时列出旧与新成员。提交和选举必须分别获得 old majority 与 new majority。

阶段	配置	决议条件
变更前	C_old	旧多数
过渡	C_old,new	旧多数且新多数
变更后	C_new	新多数

双多数把两种配置安全连接起来。

三、完整变更流程

记忆钩子：联合配置不是“把两组节点合起来取一个大多数”，而是同一条决议必须同时拿到旧配置多数和新配置多数；这两个门槛把迁移前后的合法决议链连在一起。

Leader 校验没有其他变更在途。先加入新节点为 learner 并追平。复制 C_old,new 条目，按双多数提交。再复制 C_new 条目；节点收到该条目后按 C_new 计算配置，最终由新配置多数提交。已提交的 C_old,new 与 Leader 完备性共同保证过渡安全。完成后移除旧节点的投票和访问资格。

四、为何配置也是日志条目

成员配置决定后续哪些响应可算 quorum。把它写入日志后，节点能按相同顺序恢复配置阶段。 Leader 崩溃时，新 Leader 从已提交/未提交日志判断继续还是回滚流程。若只在运维数据库记录，协议节点可能对有效成员产生分歧。

五、新节点追平

新节点为空时立即授予投票权，会让双多数难以满足。先传快照与尾部日志，matchIndex 接近 Leader 后提升。追平阈值还要看 bytes 与时间，不只看 entry 数。新节点所在故障域也要规划，否则扩容数量增加却没有增加容灾能力。

六、单节点变更替代方案

一些实现证明一次只增加或删除一个节点可保持所需交集，并简化状态机。它要求严格串行，不能并发或批量改多个 voter。是否支持 learner、自动提升、remove-self 等行为取决于实现。面试回答应说明联合共识是经典方案，而不是声称所有 Raft 库 API 完全相同。

七、故障与运维

变更期间 Leader 故障，新 Leader 必须遵循日志中的当前配置。控制器用 changeId、base config version 和幂等状态机恢复。监控联合阶段持续时间、双侧 quorum、成员 matchIndex 和配置版本。长期卡在 joint 状态会降低可用性，必须告警但不能强行跳到新配置。

八、常见误区与追问

误区：新旧集群节点数一样就安全。 多数派集合仍可能不相交。
误区：联合配置只要求总节点过半。 必须旧多数与新多数分别满足。
误区：新节点可立即投票。 应先以 learner 追平。
误区：卡住时直接写 C_new 即可。 跳过过渡条件会破坏安全证明。
追问：成员变更为何进入日志？ 让所有节点按同一顺序确定 quorum 规则。
追问：所有 Raft 都用联合共识吗？ 否，有的采用受约束的单节点变更。
追问：旧 quorum 已永久丢失怎么办？ 进入受控灾难恢复，不能正常提交成员变更。

九、加强记忆

直接切换会产生不相交多数派。
joint 阶段要求 old 与 new 双多数。
配置变更必须作为共识日志恢复。
新 voter 先追平，变更严格串行。
具体实现可用联合共识或单节点协议，但绝不能绕开其安全约束。

简化版

详细版