cluster down异常时需先确认是否存在未分配slot或指向fail节点的slot，用cluster slots检查覆盖与重叠，总slot数必须为16384；再验证节点状态、复制链路及客户端映射更新。
Cluster down异常时，先确认是否真有Slot未分配
Redis Cluster报CLUSTERDOWN错误，不等于所有Slot都丢了——可能只是某个Slot没被任何主节点负责，或负责它的节点已下线但未被故障转移。真正要查的，是有没有unassigned Slot，以及有没有Slot指向fail状态的节点。
- 用
redis-cli -c -h <host> -p <port> cluster slots</port></host>看完整分配表；别只信cluster info里的cluster_state:ok，它可能滞后 - 输出里每行开头是Slot范围（如
0 5460），接着是负责该段的主节点ID和地址；如果某段后面跟着-（单个短横），说明这个Slot区间未分配 - 如果看到某段指向一个IP:port，但该节点当前不可达，
cluster nodes里对应ID的状态却是fail，那这个Slot就“逻辑在线、物理离线”，Cluster会拒绝写入
快速检查16384个Slot是否全覆盖且无重叠
人工扫cluster slots输出太容易漏——16384个Slot理论上应被划分为连续、无空隙、无重叠的若干段，总长度必须正好是16384。只要有一段缺失或越界，就会触发CLUSTERDOWN。
- 把
cluster slots输出保存为slots.txt，用一行awk校验：awk '{sum += $2-$1+1} END {print sum}' slots.txt，结果不是16384就一定有问题 - 注意：$1是起始Slot，$2是结束Slot，所以数量是
$2 - $1 + 1，不是$2 - $1 - 重叠不易肉眼发现，可用
sort -n按第一列排序后逐行比对：下一段的起始Slot必须等于上一段结束Slot+1，否则中间有断档
节点在线但Slot未分配？重点查MOVED重定向失败链路
常见假象：所有节点ping通、cluster nodes显示都是connected，但客户端仍报MOVED或CLUSTERDOWN。问题往往出在客户端缓存了过期的Slot映射，或服务端尚未完成配置传播。
- 执行
redis-cli -c -h <any-node> -p <port> cluster reset hard</port></any-node>会清空整个集群的Slot映射，慎用；更安全的是只对目标节点执行cluster forget <node-id></node-id>再重新meet - 检查
cluster nodes输出中每个主节点的flags字段：必须含master且不含noaddr或fail；如果某主节点标着myself,master,fail，说明它自认已下线，但其他节点还没同步到 - 客户端收到
MOVED响应后，必须更新本地Slot映射表；若用Jedis，确认是否启用了setRefreshPeriod；若用redis-py，检查RedisCluster初始化时是否设了skip_full_coverage_check=False（默认为True，会跳过Slot完整性检查）
修复Slot分配前，先确认master-slave关系是否稳定
强行用cluster addslots或cluster reshard补Slot，可能让从节点复制流错乱，尤其当原主节点还在尝试恢复时。
- 运行
cluster nodes，确认每个主节点的从节点列表（第9字段之后）真实存在且状态为slave；若有从节点显示connecting或noaddr，先解决复制链路，再动Slot - 用
info replication连到疑似问题节点，看master_link_status:up和slave_repl_offset是否持续增长；如果master_link_status:down，cluster failover force也没用 - reshard过程中若中断，可能留下
importing/migrating标记；用cluster nodes找带这两个flag的节点，再对其执行cluster setslot <slot> stable</slot>
Slot分配不是数字游戏，而是节点间状态共识的结果。最常被忽略的，是认为“节点进程活着=它能参与集群决策”——其实只要cluster nodes里它的ping-sent时间戳停滞超过cluster-node-timeout（默认15秒），它就被其他节点标记为fail，哪怕进程仍在跑。
