不中断业务的节点添加核心是“异步同步+渐进接管”，即新节点先只读/待命、完成数据对齐后再分担流量，全程不阻塞原有请求路径；需满足健康检查、环境对齐、网络互通、时间同步等前提，并依系统执行对应命令，再经连接层、数据层、服务层三重验证及文档更新、告警调整、压测收尾。
实现不中断业务的节点添加，核心在于“异步同步+渐进接管”——新节点以只读或待命身份加入，完成数据对齐后再分担流量，全程不阻塞原有请求路径。不同系统机制不同，但底层逻辑高度一致。
一、通用前提：健康检查与环境对齐
扩容不是加机器就完事，而是集群状态的一次再确认：
- 先运行集群健康检查命令（如 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），确认其真实承载能力
