quorum应设为哨兵节点总数一半向上取整，3节点时为2、5节点时为3，避免偶数导致投票僵局；down-after-milliseconds与failover-timeout需满足后者≥3倍前者，且所有sentinel节点配置必须完全一致。
Redis Sentinel 本身不处理业务请求，它的配置直接影响故障发现速度、切换成功率和客户端感知延迟——性能最优的关键不是压测吞吐，而是让 failover-timeout、down-after-milliseconds 和 parallel-syncs 彼此咬合，避免超时叠加或同步阻塞。
sentinel monitor 的 quorum 值设为多少才不误判也不分裂
quorum 不是哨兵节点总数，而是触发“客观下线”所需的最少同意哨兵数。设得太小（比如 1）会导致单个哨兵网络抖动就误判主节点下线；设得太大（比如等于哨兵总数）又可能因个别哨兵失联导致无法故障转移。
- 3 个哨兵节点时，
quorum推荐设为2：容忍 1 个哨兵短暂失联，同时避免单点误判 - 5 个哨兵节点时，
quorum推荐设为3：符合“过半原则”，兼顾容错与决策效率 - 绝对不要设为偶数（如 4 个哨兵配
quorum 2），否则可能出现 2:2 投票僵局，导致故障转移卡住
down-after-milliseconds 和 failover-timeout 怎么配合才不拖慢切换
这两个参数存在隐式依赖：failover-timeout 必须显著大于 down-after-milliseconds，否则哨兵还没确认主节点下线，就已超时放弃本次故障转移。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
down-after-milliseconds mymaster 30000表示连续 30 秒无响应才标记主观下线 -
failover-timeout mymaster 180000必须 ≥ 3 ×down-after-milliseconds（即至少 90 秒），留出投票、选举、从节点同步的时间余量 - 若网络延迟波动大（如跨机房部署），建议把
down-after-milliseconds提到60000，同时把failover-timeout调至300000，否则容易因瞬时丢包反复触发假切换
parallel-syncs 设为 1 真的最稳妥吗
默认 parallel-syncs 1 是为避免新主节点被多个从节点同步请求打垮，但在数据量小、带宽充足、从节点数量 ≤ 3 的场景下，它反而成了瓶颈——所有从节点排队等同步，故障恢复窗口被拉长。
- 若从节点只有 2–3 台，且每台内存 parallel-syncs 2 或
3 - 若使用 SSD + 千兆以上内网，且
repl-backlog-size已调大（如 128MB），parallel-syncs可设为从节点数，加速全量同步完成 - 切忌在主节点 CPU 长期 >70% 或磁盘 I/O 饱和时调高该值，会加剧主节点压力，甚至触发 OOM
真正影响可用性的不是某个参数调得多漂亮，而是所有哨兵节点的 down-after-milliseconds 和 failover-timeout 必须完全一致——哪怕只有一台哨兵配置不同，就可能导致部分节点认为该切换、部分认为不该切，最终整个集群卡在“半客观下线”状态。
