共识集群扩缩容时如何保证安全？

简化版

共识集群扩缩容不能直接把旧成员列表替换成新列表，否则旧、新配置可能各自形成不相交多数派。安全做法是把成员变更也写入共识日志，并通过联合配置或一次只变更一个成员，保证过渡期间任何成功决议都与前后配置的多数派相交。新节点先追日志，移除节点在配置提交后停止投票和服务线性一致请求。

详细版

成员配置是复制状态机的一部分，只有配置条目提交后才生效。 Raft 的联合共识阶段要求旧配置多数派和新配置多数派同时确认，再提交只含新成员的最终配置。某些实现采用 single-server change，但必须严格串行并遵守实现证明，不能并发增删。

扩容前先让 learner/non-voter 追平，避免新投票者拖慢 quorum。缩容前确认剩余节点仍跨故障域构成多数派，尤其不能在失去 quorum 时强行重配。运维系统监控配置版本、成员角色、matchIndex 和未完成变更，并确保命令幂等。

完整版教学

一、成员列表本身也需要共识

谁能投票决定一条日志是否提交，是协议安全性的核心。如果每台机器在本地随意改成员列表，同一任期可能出现不同 quorum 定义。因此成员变更必须像业务命令一样复制、提交并按顺序应用。

扩缩容不是改配置文件，而是改变“谁有权决定真值”的共识操作。

二、直接切换为什么危险

旧集群为 A、B、C，多数派是 2。新集群为 C、D、E，多数派也是 2。 A+B 和 D+E 完全不相交，可能在网络分区中分别提交冲突日志。

old quorum: {A,B}
new quorum: {D,E}
intersection: empty  -> unsafe

多数派数量相同不代表安全，关键是决议集合必须具有交集。

三、联合共识如何过渡

联合阶段同时包含 C_old 与 C_new。日志提交需要旧配置多数派和新配置多数派都确认。联合配置提交后，再复制只含 C_new 的最终配置。

阶段	有效配置	提交条件
初始	C_old	old majority
联合	C_old,new	old majority 且 new majority
完成	C_new	new majority

这样过渡期间的决议不会绕开旧集群或新集群。

四、扩容节点先做 learner

空节点日志落后很大，直接成为 voter 会增加选举和提交延迟。先以 learner/non-voter 加入，接收快照和日志，matchIndex 接近 Leader 后再提升为 voter。例如 Leader 索引 100 万，新节点只有 0，先安装快照到 95 万再追尾日志。追平阈值应结合日志速率和延迟，而非只看某一瞬间差值。

五、缩容和故障域

从 5 节点缩到 3 节点后，容忍故障数从 2 变为 1。若剩余 3 个节点都在同一机房，协议仍能运行，却失去机房容灾。移除 Leader 时通常先转移领导权，减少不可用窗口。被移除节点在最终配置提交后不得继续参与投票，并应被网络和凭证层隔离。

六、失去多数派时不能随便强改

原配置失去 quorum 时，无法安全提交新的成员配置。强行在少数派上“重建多数派”可能与仍存活的另一分区产生双主。灾难恢复必须确认旧集群不会再恢复写入，使用受控的 force-new-cluster 流程，并接受这是人工安全决策。操作前备份日志、任期和成员元数据。

七、工程控制与观测

成员变更一次只允许一个工作流，使用 changeId 和配置版本保证幂等。监控 current/target membership、角色、任期、commitIndex、matchIndex、snapshot 状态和变更持续时间。控制器重启后从共识日志恢复阶段，不能重复添加或提前删除节点。完成后执行故障演练，确认任意允许数量节点失效仍有 quorum。

八、常见误区与追问

误区：增节点只需更新服务发现。 投票成员必须经共识配置提交。
误区：新旧集群都有多数派就一定安全。 两套多数派可能不相交。
误区：新节点一启动就应拥有投票权。 日志落后会拖慢提交和选举。
误区：失去多数派时删掉故障节点即可恢复。 少数派无法安全批准新配置。
追问：为何联合阶段要双多数？ 保证旧、新决议集合都相交。
追问：可以一次变更多个节点吗？ 联合共识可以表达，但必须遵循实现协议；单节点变更实现则必须串行。
追问：移除 Leader 怎么做？ 先转移领导权，再提交成员变更并隔离旧节点。

九、加强记忆

成员列表属于共识状态。
过渡阶段必须保证新旧 quorum 相交。
扩容先 learner 追平，再授予投票权。
缩容同时评估容错数量和故障域。
没有原 quorum 时不能把强制重配伪装成普通扩缩容。

简化版

详细版