clusterdown错误本质是集群法定多数（quorum）失效，即在线且可通信的主节点数≤总主节点数/2，导致集群自我熔断拒绝服务；需用redis-cli cluster nodes过滤master且非fail/noaddr字段统计真实存活主节点数，而非依赖滞后的cluster_state:ok。

CLUSTERDOWN 错误本质是集群法定多数（quorum）失效

“CLUSTERDOWN The cluster is down”不是某个节点挂了就触发，而是集群判定自己已无法维持基本一致性——核心条件是：在线且可通信的主节点数 ≤ 总主节点数 / 2。比如 6 主集群，只要 ≤ 3 个主节点存活（含心跳可达），整个集群立即拒绝所有写入和部分读取，返回该错误。

注意：cluster-node-timeout 配置值（默认 15000ms）决定了“不可达”的判定窗口；节点状态同步有延迟，cluster nodes 输出里标着 fail 的节点，可能已在其他节点视角下被踢出 quorum。

• 用 redis-cli -c -h <ip> -p <port> cluster nodes</port></ip> 查每个节点的 flags 字段，过滤出含 master 但不含 fail 或 noaddr 的行，统计数量
• 别只看 cluster info 里的 cluster_state:ok ——它可能缓存旧状态，滞后于实际投票结果
• 从客户端视角，Jedis 默认会缓存 slot 映射；若主节点批量失效后未及时刷新，JedisClusterException 可能持续出现，即使后台集群已恢复

如何快速验证是否真因主节点不足导致 CLUSTERDOWN

直接数主节点比查日志更可靠。执行以下命令后人工计数即可定位：

redis-cli -c -h 192.168.1.10 -p 7001 cluster nodes | awk '$3 ~ /master/ && $3 !~ /fail|noaddr/ {count++} END {print "live masters:", count}'

输出如 live masters: 2，而你本应有 5 个主节点，那问题就明确了——集群因未达法定多数而自我熔断。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 如果结果为 0：检查网络连通性，确认客户端能否 telnet 通所有主节点端口
• 如果结果为 1–N（N
• 避免误操作：cluster reset hard 会清空全部 slot 映射，等同于集群逻辑重置，仅限彻底重建时使用

Slot 分配完整 ≠ 集群可用，但 Slot 缺失一定触发 CLUSTERDOWN

即使所有主节点都标记为 connected，只要任意一个 slot 区间未分配（cluster slots 输出中某行结尾是 -），或指向一个 fail 节点，集群就会返回 CLUSTERDOWN。因为 Redis 要求 0–16383 全量 slot 必须有且仅有一个健康主节点负责。

用这行命令快速验算覆盖总数：

redis-cli -c -h 192.168.1.10 -p 7001 cluster slots | awk '{sum += $2-$1+1} END {print sum}'

结果不是 16384，说明 slot 分配存在空洞或越界，必须修复。

• 常见诱因：手动 cluster add-node 后没执行 reshard，或故障转移后 cluster failover 未完成传播
• redis-cli --cluster check 会同时报告 slot 覆盖与节点状态，比单独查 cluster info 更准
• Java 客户端如 Jedis 默认跳过 full coverage 检查（skip_full_coverage_check=True），线上建议设为 False，让异常暴露得更早

客户端收到 CLUSTERDOWN 后该做什么而不是做什么

这不是客户端代码缺陷，而是服务端已主动放弃服务。此时重试、换节点、改配置都不解决问题，必须先恢复集群侧状态。

• 不要反复调用 set 或 get —— 每次都会走完整重定向链路，加重无效请求压力
• 不要仅依赖一个节点执行诊断命令；选多个不同节点分别跑 cluster nodes，对比它们对同一节点的状态标记是否一致
• 检查 redis.conf 中 cluster-require-full-coverage yes（默认开启）：设为 no 可让集群在 slot 缺失时仍接受请求（但数据可能丢失），仅作临时规避
• 真正关键的是：确认故障节点的 nodes.conf 是否残留旧拓扑信息，重启前务必清理，否则新进程会加载错误配置并再次加入失败集群