安全重启Redis集群的正确做法是逐个节点操作，优先处理从节点，严格等待redis-cli --cluster check返回OK后再进行下一轮，避免脑裂、槽位丢失和连接雪崩。
怎么避免集群重启时“全挂掉”
Redis集群不是单机，6个节点一起硬重启，大概率触发脑裂、槽位丢失、客户端连接雪崩。真正安全的做法是：每次只动1个节点，等它完全回归集群（cluster_state=ok且cluster_known_nodes数稳定），再动下一个。
关键不是“快”，而是让redis-cli --cluster check能持续返回OK，而不是CLUSTERDOWN或FAIL状态。
- 别用
kill -9直接干掉所有进程——这会跳过持久化和握手流程，节点重启后可能被其他节点标记为fail - 别在高峰期执行——哪怕你分批操作，每轮重启仍会造成局部槽位不可用（通常几秒），客户端若没做重试/重定向兜底，会直接报错
MOVED或ASK - 别跳过
cluster-node-timeout检查——默认15秒，如果你的网络延迟高或磁盘慢，这个值太小会导致节点刚起来就被误判下线
分批重启的实操节奏怎么卡
不是按顺序编号重启（比如7001→7002→7003），而是优先处理从节点（replica），最后动主节点（master）。因为从节点宕机不影响写入，但主节点宕机等于整个分片不可写。
每轮操作严格遵循：停 → 等确认退出 → 启 → 等ping通 → 等cluster nodes显示connected且角色正确 → 等--cluster check通过 → 再进下一轮。
- 停节点：
redis-cli -p 7002 shutdown save（强制RDB落盘，不丢数据） - 确认退出：
! pgrep -f "redis-server.*7002"或redis-cli -p 7002 ping返回Could not connect - 启节点：
redis-server /opt/redis/cluster/7002/redis.conf（确保配置里cluster-enabled yes且cluster-config-file路径可写） - 等就绪：
while ! redis-cli -p 7002 cluster info 2>/dev/null | grep -q "cluster_state:ok"; do sleep 1; done
为什么--cluster check比ping更关键
ping只说明进程活着、端口通了；cluster info只说明本节点认为自己状态正常；而redis-cli --cluster check 127.0.0.1:7001是模拟集群仲裁逻辑，会遍历所有节点连通性、槽位分配一致性、主从关系是否匹配——这才是真正的“绿灯”。
常见假绿灯场景：
- 节点起来了，但
nodes.conf里还存着旧的fail标记，导致它拒绝加入集群——删掉该节点下的nodes.conf再重启 - 某从节点启动后一直卡在
noaddr状态——检查它的cluster-announce-ip是否配置成容器内网IP而非宿主机IP -
--cluster check报Slot 1234 is assigned to 2 nodes——说明有节点加载了过期的nodes.conf，必须统一清空所有节点的nodes.conf再逐个拉起
批量脚本里最容易漏掉的等待逻辑
写for循环重启多个端口很轻松，但几乎没人真写对“等待集群收敛”的逻辑。下面这段才是生产可用的最小等待块：
redis-cli -p $port shutdown save while pgrep -f "redis-server.*$port" >/dev/null; do sleep 0.5; done redis-server /opt/redis/cluster/$port/redis.conf # 等到本节点 ready while ! redis-cli -p $port ping 2>/dev/null | grep -q "PONG"; do sleep 0.5; done # 等到集群全局 ok while ! redis-cli --cluster check 127.0.0.1:$port 2>&1 | grep -q "OK"; do sleep 1; done
注意：最后一行不能只检查本节点cluster info，必须调--cluster check，否则你会在第3个节点重启完时才发现第1个节点其实在后台悄悄退群了。
大规模集群重启最麻烦的从来不是命令敲不对，而是把“集群已恢复”这件事，当成一个可以靠时间估算的静态状态——它其实是动态协商结果，必须用集群自己的校验逻辑来确认。
