集群扩容实践：如何实现业务不中断的节点添加

不中断业务的节点添加核心是“异步同步+渐进接管”，即新节点先只读/待命、完成数据对齐后再分担流量，全程不阻塞原有请求路径；需满足健康检查、环境对齐、网络互通、时间同步等前提，并依系统执行对应命令，再经连接层、数据层、服务层三重验证及文档更新、告警调整、压测收尾。

实现不中断业务的节点添加，核心在于“异步同步+渐进接管”——新节点以只读或待命身份加入，完成数据对齐后再分担流量，全程不阻塞原有请求路径。不同系统机制不同，但底层逻辑高度一致。

一、通用前提：健康检查与环境对齐

扩容不是加机器就完事，而是集群状态的一次再确认：

• 先运行集群健康检查命令（如 talosctl cluster check、redis-cli cluster info、zkCli.sh -server host:port ls /zookeeper/config），确保所有节点状态为 healthy 或 connected
• 新节点必须使用与集群完全一致的软件版本、配置模板和安全参数（如 TLS 证书、认证 token、cluster_name）
• 网络层需双向打通：不仅客户端能访问新节点，节点之间也要互通管理端口（如 Cassandra 的 7000、ZooKeeper 的 2888/3888、Pulsar 的 6650）
• 时间同步是隐形关键项——所有节点 NTP 偏差须控制在 100ms 内，否则可能触发脑裂或拒绝加入（OceanBase 要求 ≤2 秒）

二、主流系统添加节点的关键动作

跳过抽象原则，直击操作本质：

• Redis / KeyDB 集群：用 CLUSTER MEET ip port 发起握手，再通过 CLUSTER SETSLOT ... MIGRATING 和 CLUSTER GETKEYSINSLOT 分批迁移哈希槽，期间客户端仍可读写原节点
• Cassandra：启动新节点时自动进入 bootstrap 模式，后台静默拉取数据；无需人工干预槽位，由 nodetool rebuild 或 nodetool refresh 触发局部重平衡
• ZooKeeper：通过 reconfig -add 动态更新配置，新节点下载最新 zoo.cfg.dynamic 后自加入，旧节点平滑感知变更，无需重启
• Twemproxy：仅修改 nutcracker.yml 中 servers 列表，执行 kill -SIGHUP $(pidof nutcracker) 热重载，连接会自然漂移到新后端
• OceanBase：在 sys 租户执行 ALTER SYSTEM ADD SERVER 'ip:port' ZONE 'zone_name'，系统自动分配副本、调度资源池、触发日志同步，全过程无锁表

三、验证是否真正“不中断”

不能只看命令返回 success，要从三个层面交叉确认：

• 连接层：客户端持续 ping 或 set/get 小数据，延迟波动 ≤20%，错误率保持为 0
• 数据层：对比新旧节点的 key 数量（Redis）、token range（Cassandra）、tablet 分布（HBase）、分区水位（Pulsar），确认无丢失、无重复、无倾斜
• 服务层：监控指标如 request rate、5xx error count、replication lag 在整个过程中未出现尖峰或断崖

四、容易被忽略的收尾动作

节点加完≠扩容结束，后续两步决定长期稳定性：

• 更新集群拓扑文档或 CMDB，标注新节点角色、IP、部署时间、负责人
• 调整告警阈值：例如 Prometheus 中的 node_cpu_usage 告警需按节点数同比例放宽，避免误报
• 对新节点执行一次压测（哪怕只是 ab -n 10000 -c 100 http://new-node/health），确认其真实承载能力