Redis怎样查询集群的整体健康状态_使用cluster info指令查看槽位覆盖率与节点状态

cluster_state: ok仅表示元数据一致且无不可达节点，不保证所有16384个槽位都被覆盖；若cluster_slots_ok < 16384，即使state为ok，部分请求仍会返回CLUSTERDOWN错误。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 < 16384，说明有槽未被正确服务，此时即使 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 数）。 通义听悟 阿里云通义听悟是聚焦音视频内容的工作学习AI助手，依托大模型，帮助用户记录、整理和分析音视频内容，体验用大模型做音视频笔记、整理会议记录。