Redis Sentinel 怎样设置下线判定阈值

Redis Sentinel 的下线判定不是“把一个毫秒数调小就会更快切主”。真正需要同时考虑两个参数：down-after-milliseconds 决定单个 Sentinel 观察到实例不可达后等待多久，quorum 决定多少个 Sentinel 对故障达成检测共识。检测共识成立后，是否能执行故障转移还要看 Sentinel 多数派是否可达。

官方地址：https://redis.io/docs/latest/operate/oss_and_stack/management/sentinel/

本文只讨论主观下线、客观下线、时间阈值和仲裁边界，不展开客户端重连实现。下面用一个三 Sentinel 的典型拓扑，把“多久算异常”和“多少节点同意”分开。

先分清两个阈值各自负责什么

Sentinel 会持续观察被监控的 Redis 主节点。某一个 Sentinel 在规定时间内没有收到正常 PING 响应，或者收到错误响应，会先形成自己的主观判断，这就是主观下线（SDOWN）。这里使用的是 down-after-milliseconds，它是时间边界，不是 Sentinel 数量。

其他 Sentinel 也观察到同一个主节点异常后，多个节点才能形成客观下线（ODOWN）共识。这里使用的是 sentinel monitor 最后的 quorum 参数。它回答的是“至少多少个 Sentinel 认为主节点不可达”，而不是“客户端等待多久”。

三节点部署时 quorum 应该怎样取

一个可作为起点的配置如下。配置文件中的注释只解释参数职责，数值需要结合网络抖动和业务故障窗口调整。

# 监控名、主节点地址、端口、故障检测共识数
sentinel monitor mymaster 127.0.0.1 6379 2

# 单个 Sentinel 等待主节点无响应的时间，单位是毫秒
sentinel down-after-milliseconds mymaster 5000

# 故障转移相关的整体等待窗口，不等同于 down-after-milliseconds
sentinel failover-timeout mymaster 60000

# 故障转移后同时重新同步的副本数量
sentinel parallel-syncs mymaster 1

在三个 Sentinel 的部署里，quorum=2 表示至少两个 Sentinel 对主节点不可达形成检测共识。它并不等于“两个节点就能单独切主”：真正开始故障转移还需要 Sentinel 多数派授权，因此三个 Sentinel 应尽量放在相互独立的故障域中。

如果把 quorum 设置得过低，短暂网络抖动更容易触发错误故障判断；设置得过高，则可能出现主节点已经不可用，但剩余可通信的 Sentinel 数量不足以形成共识。参数选择要先看可用的 Sentinel 总数和网络分区方式，再谈毫秒数。

根据误报与恢复窗口调时间

down-after-milliseconds 越小，故障发现的理论等待时间越短，但对抖动、暂停和瞬时拥塞更敏感；越大，误判机会通常更低，却会拉长真正故障被识别的等待窗口。不要用“越小越高可用”作为唯一依据。

可以按下面的思路做决策：

• 先观察正常网络与 Redis PING 的抖动范围，给短暂尖峰留出余量。
• 再确定业务能接受的故障发现窗口，把它与故障转移和副本同步时间分开评估。
• 最后结合 Sentinel 节点分布选择 quorum，确保发生单个故障域失联时，剩余节点仍有机会达成共识。

这里的时间阈值只负责故障检测，不负责应用连接池的重试、退避或重新发现主节点。客户端策略应该独立设计，否则把两类参数同时调小，可能把一次网络抖动放大成重连风暴。

用 Sentinel 状态字段复查配置含义

调整后可以从 Sentinel 查询被监控主节点的状态字段，确认运行中的配置是否与文件预期一致。下面是只读查询示例：

# 查询当前主节点的状态摘要，重点看阈值、quorum 和 Sentinel 数量
redis-cli -p 26379 SENTINEL MASTER mymaster

# 查询客户端应使用的当前主节点地址；这不是故障阈值配置
redis-cli -p 26379 SENTINEL GET-MASTER-ADDR-BY-NAME mymaster

复查时重点关注 down-after-milliseconds、quorum 和 num-other-sentinels。如果看到的数值与配置文件不同，先确认是否曾通过 SENTINEL SET 运行时修改，或者检查配置文件是否可写、是否被 Sentinel 重写。读到主节点地址只能说明当前服务发现结果，不能代替故障检测结论。

常见误区与结论

最常见的误区有三个：把 quorum 当成客户端重连次数，把 down-after-milliseconds 当成故障转移总耗时，以及只部署两个 Sentinel 却期待在任意网络分区下都能安全切换。正确做法是先用至少三个独立故障域的 Sentinel 建立多数派，再分别配置时间阈值、检测 quorum 和应用侧重连策略。

一句话总结：down-after-milliseconds 决定“单个观察者等多久”，quorum 决定“多少观察者同意异常”，Sentinel 多数派决定“是否有资格推进故障转移”。

相关问题

down-after-milliseconds 越小越好吗？

不是。它需要覆盖正常网络抖动和 Redis 短暂忙碌，否则会增加误判；应以故障发现目标和实测抖动共同决定。

quorum=2 是否代表两个 Sentinel 就能完成切主？

不代表。quorum 用于故障检测共识，实际故障转移还需要 Sentinel 多数派授权，二者是不同条件。