Redis哨兵配置详解：主节点与Quorum设置

Redis哨兵配置的核心在于精准把控主从拓扑发现与分布式故障判定的每一个关键参数：`sentinel monitor`的三要素（唯一master-name、可连通的主节点IP和端口）是哨兵感知整个集群的唯一入口，缺一即导致监控失效；quorum并非哨兵总数而是触发投票的最小同意数，直接影响仲裁可靠性；密码必须在主节点（requirepass）、从节点（masterauth）和哨兵（auth-pass）三方严格一致，ACL场景还需补充masteruser；`down-after-milliseconds`需依网络质量谨慎设为3000–5000ms（内网）或更高，避免抖动引发误判；而启动顺序——先主节点、再从节点（确认复制链路就绪）、最后哨兵——更是防止健康节点被误标sdown的生命线。这看似简单的几行配置，实则是状态驱动的分布式系统中灵敏度、一致性与容错性的精密平衡，任何一处偏差都可能在高并发下放大为服务中断。

sentinel monitor 配置项必须写对三要素，少一个就监控失败

配置哨兵第一步不是启动，而是让 sentinel monitor 正确指向主节点——它不是“建议”，是哨兵发现整个主从拓扑的唯一入口。写错 IP、端口或名字，哨兵压根不会拉取从节点信息，后续所有自动故障转移都成空谈。

• master-name 是自定义标识符，必须全集群唯一；多个主从组共存时（比如同时管 mymaster 和 cache2），重名会导致配置覆盖或监控混乱
• ip 和 port 必须是主节点当前可连通的地址——不能写 127.0.0.1 或 localhost，哨兵进程和 Redis 实例不在同一台机器时必连不上
• quorum 不是哨兵总数，而是“触发投票所需的最小同意数”；3 个哨兵就填 2，5 个哨兵填 3；填 1 等于放弃仲裁，极易误判宕机

主节点带密码？sentinel auth-pass 必须同步配，否则同步直接静默断开

哨兵要和主节点通信、要让从节点去复制主节点，这两处都校验密码。只在 redis.conf 里设了 requirepass，但没在哨兵配置里加 sentinel auth-pass，现象是：哨兵日志里几乎不报错，INFO SENTINEL 显示 master0:status=odown，但从节点始终无法完成全量同步，数据一直为空。

• 密码必须完全一致：主节点的 requirepass、从节点的 masterauth、哨兵的 sentinel auth-pass 三者值相同
• 如果主节点用 ACL（Redis 6+），还需额外加 sentinel masteruser ，否则认证失败
• 测试是否生效：用 redis-cli -p 26379 连哨兵，执行 SENTINEL get-master-addr-by-name mymaster；返回正常地址才说明认证链跑通

down-after-milliseconds 设太小，内网抖动就被判“主观下线”

默认 30 秒太保守，生产环境一般调到 5000（5 秒）；但别无脑缩到 1000 以下——局域网偶尔丢一两个心跳包很常见，sentinel down-after-milliseconds 设太小，会导致哨兵频繁发起“主观下线”判定，进而触发不必要的选举，从节点反复切换角色，客户端连接抖动。

• 合理值参考：内网稳定环境设 3000–5000；跨机房或高延迟链路不低于 10000
• 这个参数只影响“主观下线”，真正触发故障转移还要看 quorum 是否达成“客观下线”，所以它本质是灵敏度调节阀
• 配合 SENTINEL masters 命令观察 last-ok-ping-reply 字段，能直观看到哨兵上次收到主节点响应的时间戳，比盲调参数更靠谱

启动前必须确认主从已就绪，否则哨兵会把健康的从节点也标记为 sdown

哨兵启动时会立即尝试连接配置的主节点，并通过主节点的 INFO REPLICATION 获取从节点列表。如果此时主节点还没起来，或者从节点虽运行但尚未完成复制握手（slave0:state=connect 或 state=syncreply），哨兵会把那些“连不上主”的从节点统一标为 sdown（主观下线），后续即使主从恢复，也要等 failover-timeout 超时后才重新评估。

• 正确顺序：先启主节点 → 再启从节点并确认 INFO REPLICATION 中 role:slave 且 master_link_status:up → 最后启哨兵
• 验证命令：redis-cli -p 26379 SENTINEL slaves mymaster 返回的每个从节点状态应为 ok，而非 disconnected 或 noaddr
• 容器化部署时尤其注意：别用单个 docker-compose up 启全部，要用 depends_on + 健康检查，或分两阶段启动

哨兵模式真正的复杂点不在配置语法，而在于它是个“状态驱动”的分布式协调系统——所有参数都在影响状态转换的时机和边界。哪怕 quorum 多写一个 1，或 down-after-milliseconds 少设 200 毫秒，在流量高峰时都可能让一次网络抖动演变成服务中断。

以上就是《Redis哨兵配置详解：主节点与Quorum设置》的详细内容，更多关于的资料请关注golang学习网公众号！