首页/数据/Redis 进阶速查/cluster-require-full-coverage 取舍

cluster-require-full-coverage 取舍

该配置决定槽覆盖不全时集群是否对外可用:yes(默认)要求全部槽在线,no 则允许在部分槽失效时继续服务可用槽。

Redis 进阶速查数据更新于 2026-10-13

cluster-require-full-coverage 是什么

这个参数决定槽覆盖不全时集群是否对外服务:默认 yes 要求 16384 个槽全部有归属节点,否则集群进入不可用状态并返回集群下线错误;改成 no 后已覆盖的槽继续服务,命中缺失槽的请求单独报错。它本质上是把影响面从「整体不可用」换成「部分键不可用」。

基本信息

参数名cluster-require-full-coverage
默认值yes,要求全部槽在线
设为 no部分槽失效时继续服务已覆盖的槽
配套参数cluster-allow-reads-when-down 决定下线时是否允许读
观测方式CLUSTER INFO 的集群状态与槽分配数量

两种选择的对照

配置槽缺失时的行为代价
yes(默认)集群状态变为下线,请求可能整体被拒绝单点故障容易放大成全集群不可用
no仅缺失槽范围不可用,其余照常服务应用必须处理部分键报错,路由与重试更复杂
恢复期节点回补或手工指派槽期间的一致性与数据校验要单独评估

查看与调整

查看与调整
redis-cli CONFIG GET cluster-require-full-coverage
redis-cli -c CLUSTER INFO | grep -E 'cluster_state|cluster_slots_assigned|cluster_known_nodes'
redis-cli -c CLUSTER NODES | head -5
redis-cli CONFIG SET cluster-require-full-coverage no   # 需全集群节点一致,并写回配置文件
# 改完确认各节点配置一致,并同步更新故障处理手册

典型使用场景

  • 可用性优先的业务:接受部分键不可用以保住整体服务
  • 排障窗口期:故障节点尚未回补时临时放宽,缩短整体不可用时间
  • 集群巡检:把槽覆盖率与集群状态纳入监控
  • 故障域评估:确认单个分片的损失会影响到什么范围
  • 流程配套:把最新行为写进故障处理手册与值班培训
多数场景保持默认更安全:全槽要求能在拓扑不完整时尽早暴露问题,避免部分请求静默出错;确要改 no,必须同时更新故障恢复流程与告警规则。
设为 no 后应用会随机命中缺失槽并报错,错误更分散、更难发现;没有配套监控与重试设计就改这个参数,问题会从「明显不可用」变成「偶发报错」。

易错点

  • 改 no 后业务随机命中失效槽,报错更隐蔽也更分散
  • 故障恢复流程未配套更新,团队对集群行为的认知不一致
  • 只改了部分节点,各节点配置不一致导致行为难以预测
  • 把允许下线读写与槽覆盖要求混为一谈,读写可用性预期错位
  • 缺少槽覆盖率告警,槽缺失时只能靠业务报错发现

数据来源与参考

  • Redis 官方文档:集群覆盖配置
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌