Redis 哨兵参数调优实战

哨兵部署好之后，绝大多数团队就再没动过配置。可一旦真出故障，就会发现切换要么迟迟不触发、要么过于激进，要么切换完成后新主被全量同步压垮——这三类问题分别对应 down-after-milliseconds、failover-timeout 和 parallel-syncs 三个参数。本文基于 Redis 7 的 Sentinel，把参数语义放到故障转移时间线里讲清楚。

一、先建立故障转移时间线

一次完整的故障转移按时间展开是：哨兵每秒 PING 主节点，超过 down-after-milliseconds 无有效回复标记主观下线（SDOWN）；达到 quorum 个哨兵都认为下线后升级为客观下线（ODOWN）；发起转移的哨兵需要多数派哨兵授权；授权后筛选从节点、执行 REPLICAOF NO ONE 提升、按 parallel-syncs 把其余从节点逐批重配到新主。三个参数分别卡在时间线的感知端、授权端和收尾端。

把这条时间线量化成秒数，才知道每个参数能压缩多少。以 3 个哨兵、quorum 2、down-after-milliseconds 30000、failover-timeout 180000 为例，一次完整的自动切换大约是：

| 阶段 | 耗时来源 | 典型时长 |

| --- | --- | --- |

| SDOWN 判定 | down-after-milliseconds | 30 秒 |

| ODOWN 达成 | 哨兵间 gossip 传播 | 1 秒内 |

| 授权 | 多数派投票 | 1 秒内 |

| 选从与提升 | 候选筛选、REPLICAOF NO ONE | 1 到 3 秒 |

| 其余从重配 | parallel-syncs 串行 | 与从库数量、同步方式相关 |

可以看到 30 秒里绝大部分花在第一步。这也揭示了调参的最大杠杆位置：把 down-after 从 30 秒降到 8 秒，整条时间线就直接缩短 22 秒，而其他参数优化的空间只有几秒。代价当然是误判风险，这正是下一节要权衡的内容。

二、down-after-milliseconds：感知速度与误判的平衡

这个参数的官方默认值是 30000 毫秒。有效的 PING 回复只有三种：+PONG、-LOADING、-MASTERDOWN，其余回复或无回复都算无效。

它有两层影响。第一层是感知速度：值越大，真故障发现越慢；值越小，网络抖动越容易触发切换。第二层常被忽略——它还参与从节点候选筛选：与主节点断连超过 (down-after-milliseconds × 10) + 主节点已 SDOWN 时长 的从节点，直接失去晋升资格。也就是说 down-after 调得越大，可用候选池反而越小。

取值建议：纯内网、网络质量有压测数据的环境可设 5000 到 10000；存在跨机房链路或宿主争抢的环境保持 15000 到 30000。调小之前先确认两件事：客户端能承受频繁断连重连，且主线程没有会被阻塞数秒的慢命令。

"有效回复只有三种"这条规则需要展开，因为它解释了很多"明明活着却被判下线"的现场。哨兵发送的 PING 收到以下三种回复才算健康：

• +PONG：正常响应；
• -LOADING：节点正在加载数据，还没准备好提供服务；
• -MASTERDOWN：该节点认为自己的主节点已下线。

除此之外的任何回复都算失败，包括 -BUSY（脚本执行超时）、-MISCONF（快照失败停止写入），以及 -NOAUTH（认证失败）。最后这个最隐蔽：如果在哨兵配置变更后忘了给 sentinel auth-pass 补上新密码，所有认证回复都变成 -NOAUTH，3 个哨兵会在 down-after 之后一致判主库下线并触发切换，而主库其实一直正常运行。这类"误判切换"的根因不在 Redis，而在认证配置，排查时要先看哨兵日志里的回复内容。

另一个高频原因是主库正在执行 BGSAVE 或 BGREWRITEAOF，fork 停顿加上磁盘写满导致命令处理延迟超过 down-after。此时哨兵看到的是"无回复"而非"错误回复"，同样判 SDOWN。所以 down-after 的下限应当大于"最坏情况下 fork 停顿 + 磁盘抖动"的时间，这也是为什么大数据量实例不建议把 down-after 压到 5 秒以下。

三、parallel-syncs：转移后的平滑度

转移完成的那一瞬间，其余从节点都会收到重配命令指向新主。如果它们同时发起全量同步，新主要承受 N 份 RDB 生成压力和网络流量，刚上任就可能被压垮。parallel-syncs 控制同时重配同步的从节点数量，默认 1，即串行恢复。

取值原则看两点：数据量大、磁盘慢、同步大概率走全量时保持 1，宁可读能力恢复慢一点；数据量小、从节点都能走部分重同步（repl backlog 足够大）时可以设 2 到 5，加快读扩展恢复。注意在转移期间读流量如果由从节点承担，串行恢复意味着这段时间读能力是缺失的，容量规划要把这个窗口算进去。

四、failover-timeout 与 quorum 的配合

failover-timeout 默认 180000 毫秒，它规定了一次转移尝试的超时上限，也规定了重试节奏：一个哨兵如果为同一次故障投过票或尝试过转移，要再次对同一主节点发起尝试，需要等待约两倍 failover-timeout 的时间。值调小可以更快发起二次尝试，但也更容易在真实故障未定型时反复切换。

quorum 则要区分两个门槛：它只决定 ODOWN 的判定人数；真正执行转移还需要多数派哨兵授权。以 5 个哨兵、quorum 2 为例——2 个哨兵同意即可标记客观下线，但执行转移仍需至少 3 个哨兵授权。quorum 设得比多数派低，故障判定更灵敏；设得比多数派高，则要求更多哨兵在线才肯切换。

运行时调整与巡检命令：

redis-cli -p 26379 SENTINEL SET mymaster down-after-milliseconds 8000
redis-cli -p 26379 SENTINEL CKQUORUM mymaster   # 检查当前能否凑齐判定与授权人数

注意：哨兵会在运行中把状态与配置回写 sentinel.conf，直接手改正在运行的配置文件会被覆盖，调整一律走 SENTINEL SET。另外当系统时钟跳变或进程卡顿被检测到时，哨兵会进入 TILT 自保模式，期间不执行任何转移动作。

常见坑 / 最佳实践

1. 不要用 1 秒的 down-after 追求快速切换。 每次切换都伴随客户端断连和复制丢失窗口，抖动驱动的频繁切换比故障本身更影响可用性。
2. 三个哨兵必须在三个独立故障域。 与 Redis 同机的哨兵在宿主宕机时会一起消失，多数派凑不齐，转移永远无法授权。
3. parallel-syncs 与磁盘能力联动评估。 从节点恢复期间读能力缺失，串行全量同步在大数据量下窗口很长，压测数据要覆盖这个场景。
4. 调整参数走 SENTINEL SET 并确认回写。 只改文件不生效，只 SET 不落盘则重启丢失，两步都要做。
5. 订阅 +switch-master 事件并巡检 CKQUORUM。 客户端必须能收到主地址变更，否则切换完成后连接的还是旧主；CKQUORUM 接入日常巡检可提前发现哨兵失联。

小结

• 三个参数分别卡在时间线的感知端（down-after）、重试端（failover-timeout）与收尾端（parallel-syncs）。
• down-after 同时影响感知速度和从节点候选池大小，内网 5 到 10 秒、链路不稳 15 到 30 秒。
• parallel-syncs 默认 1 保护新主，能否调大取决于全量同步能否被部分重同步替代。
• failover-timeout 约束单次转移上限与约两倍间隔的重试节奏；quorum 只管 ODOWN，授权仍靠多数派。
• 配置变更用 SENTINEL SET，哨兵会回写配置文件；TILT 模式与时钟稳定性有关，宿主机要配 NTP。