cluster-require-full-coverage 控制redis集群在部分槽不可用时是否拒绝请求：设为yes则任一槽未覆盖即返回clusterdown；设为no则仅影响对应槽的请求，其余正常处理。
cluster-require-full-coverage 是什么，它到底控制什么
这个配置项决定 Redis 集群在部分槽位（slot）不可用时，是否继续响应客户端请求。默认值是 yes，意味着只要 16384 个槽中任意一个没被任何节点负责（比如某个主节点宕机且无从节点顶上），整个集群就拒绝所有写操作，读操作也会被多数命令拒绝（如 GET、SET 返回 CLUSTERDOWN 错误）。
它不控制故障转移，不控制节点下线流程，只是一道“开关”：槽位不全 → 集群是否进入只读/拒绝状态。
为什么设成 no 能让集群“降级可用”
设为 no 后，即使有若干 slot 没有负责节点（例如某主从组全挂、或迁移中断卡住），只要请求的 key 对应的 slot 还在线，该请求就能正常处理；其他 slot 的请求则返回 MOVED 或直接失败——但不会全局性地堵死所有流量。
- 适用于容忍局部不可用、强调服务连续性的场景（如缓存层非强一致性要求）
- 必须配合客户端重试逻辑：收到
ASK或MOVED时主动重定向，否则会反复失败 - 不能解决数据丢失问题——只是让活着的 slot 继续工作
- 注意：
CLUSTER INFO输出中cluster_state:fail仍会存在，但命令执行不再被拦截
改完参数后集群状态没变？检查这三处
常见错觉是改了 cluster-require-full-coverage no 就立刻“恢复”，结果发现还是 CLUSTERDOWN。实际生效需要满足：
- 配置必须在所有节点上设置并执行
CONFIG REWRITE或重启（仅CONFIG SET不持久，且部分旧版本不支持热生效） - 执行
CLUSTER NODES确认所有节点状态为connected，没有fail?或handshake卡住的节点 - 确认不是因为
cluster-allow-reads-when-down（Redis 7.0+ 新增）未开启导致读仍被拒——该参数独立于cluster-require-full-coverage，专门控制只读行为
容易被忽略的副作用：哈希槽迁移期间的行为差异
当正在做 CLUSTER SETSLOT ... MIGRATING 或 IMPORTING 时，cluster-require-full-coverage no 会让迁移过程更“安静”，但也会掩盖问题：
- 迁移中的 slot 如果源节点宕机、目标节点未完成导入，该 slot 就彻底丢失——而
yes模式下集群会立刻报错，推动人工介入 - 客户端可能持续向旧节点发请求，触发大量
ASK重定向，若客户端没正确处理，会造成重复写或丢数据 - 监控工具依赖
cluster_state:ok判断健康，设为no后这个指标失去意义，需改用各 slot 的CLUSTER SLOTS实际分布来校验
真正难的不是改参数，而是判断哪些 slot 能丢、哪些不能丢，以及你的客户端是否真的扛得住部分失败。
