cluster_state: ok仅表示元数据一致且无不可达节点，不保证所有16384个槽位都被覆盖；若cluster_slots_ok

cluster info 返回的 cluster_state 为什么有时是 ok 却仍有请求失败？

因为 cluster_state: ok 只表示集群元数据一致、没有不可达节点，不保证所有槽位（slot）都被覆盖。如果某个槽位没被任何主节点负责（比如主节点宕机且无从节点提升），cluster_state 仍可能是 ok，但客户端发往该槽的请求会返回 CLUSTERDOWN 错误。

• cluster_state: ok 是必要条件，不是充分条件；真正关键的是 cluster_slots_assigned 和 cluster_slots_ok 是否相等（都应为 16384）
• 用 redis-cli -c -h node_ip -p port cluster info 查看时，务必核对 cluster_slots_assigned == cluster_slots_ok == 16384
• 若 cluster_slots_ok ，说明有槽未被正确服务，此时即使 <code>cluster_state 是 ok，集群也无法全量处理请求

如何快速确认是否有槽位丢失或未分配？

单靠 cluster info 的数字不够直观，必须配合 cluster nodes 和槽位映射验证。尤其当节点下线后手动执行过 cluster forget 或迁移中断，容易残留“幽灵槽”。

• 运行 redis-cli -c -h ip -p port cluster nodes，检查每行是否含 master 角色标识，且没有 fail? 或 handshake 状态的节点
• 对每个标记为 master 的节点，执行 redis-cli -h ip -p port cluster slots，确认其负责的槽区间连续、无重叠、无空隙
• 注意：cluster slots 返回结果中，每个数组第一、二位是槽范围起点和终点，第三位起才是节点 ID —— 别把 IP 当成节点 ID 去比对

cluster info 中的 cluster_known_nodes 和 cluster_size 区别在哪？

cluster_known_nodes 是集群当前元数据里记录的所有节点数（包括已下线但未被 forget 的）；cluster_size 是实际参与哈希槽分配的主节点数量（即真正提供服务的 master 数）。

• 如果 cluster_known_nodes > cluster_size，大概率存在“僵尸节点”：它们还在其他节点的 nodes.conf 里，但已无法通信
• 这种差异不会导致 cluster_state 变 fail，但会让故障排查变混乱，建议定期清理：redis-cli -h ip -p port cluster forget <node-id></node-id>
• cluster_size 必须 ≥ 1，否则整个集群退化为单点行为，失去分片能力

用脚本批量检查多个 Redis 集群节点状态时要注意什么？

直接循环调用 cluster info 容易漏掉瞬时异常，且不同节点返回结果可能不一致（比如部分节点尚未同步最新拓扑）。不能只取第一个节点的结果做判断。

• 必须对每个节点单独执行 cluster info，收集全部 cluster_state、cluster_slots_ok、cluster_size 字段，再做交集判断
• 若任一节点返回 cluster_state: fail，或任意节点的 cluster_slots_ok != 16384，即判定集群异常
• 避免用 timeout 过短（如 -t 1），某些慢节点在高负载下响应可能超 2 秒，导致误判为离线

事情说清了就结束。最常被忽略的是：别只信 cluster_state: ok，一定要盯死 cluster_slots_ok 是否等于 16384。