必须至少部署3个哨兵实例，quorum应设为⌊n/2⌋+1（如3哨兵设2、5哨兵设3），既防脑裂又保容错；若主节点启用密码，须配置sentinel auth-pass与monitor名称一致的密码。

必须至少部署3个哨兵实例，否则无法可靠判断“客观下线”，容易因网络抖动或单点故障误触发故障转移。

sentinel.conf 配置里 sentinel monitor 的 quorum 值怎么设

这个值不是哨兵总数，而是判定主节点“客观下线”所需的最小同意哨兵数。例如你启动了5个哨兵，sentinel monitor mymaster 127.0.0.1 6379 3 表示：只要≥3个哨兵认为主节点主观下线，就触发客观下线流程。

• quorum 必须 ≤ 哨兵总数，且建议设为 ⌊N/2⌋ + 1（N为哨兵数），比如3哨兵设2、5哨兵设3
• 设得太小（如3哨兵设1）会导致脑裂：网络分区时两边都以为自己是多数，各自选主
• 设得太大（如3哨兵设3）会导致容错性差：任意1个哨兵宕机，就再也无法触发故障转移
• 该值不影响选举 leader 的投票规则——leader 选举始终要求“超过半数同意”，和 quorum 无关

为什么哨兵连不上主节点时会报 NOAUTH Authentication required

哨兵本身不读取主节点的 requirepass 配置，它连接主节点时不会自动带上密码。如果你的 Redis 主节点启用了密码认证，必须显式配置哨兵的认证信息：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 在 sentinel.conf 中添加：sentinel auth-pass mymaster your_redis_password
• 注意：这里的 mymaster 必须和 sentinel monitor 后的第一个参数完全一致
• 如果主从节点密码不同（不推荐），哨兵只认 auth-pass 配的这个密码，从节点也必须用同一密码，否则故障转移后部分从节点同步失败
• 密码变更后，必须重启所有哨兵进程才能生效——哨兵不热加载密码配置

故障转移后客户端连不上新主节点的常见原因

哨兵虽然完成了切换，但客户端能否自动发现新主，取决于它是否通过哨兵获取地址，而不是直连旧IP。

• Java 客户端（如 Jedis）需使用 JedisSentinelPool，传入哨兵地址列表，而非直接 new Jedis("old-ip:6379")
• Python 的 redis-py 要用 Sentinel(host, port) 实例调用 get_master_address() 动态获取，不能硬编码主节点地址
• 如果客户端缓存了旧主地址（比如 DNS 缓存、连接池预热），即使哨兵已更新拓扑，客户端仍可能持续重试旧地址直到超时
• 哨兵默认每10秒向客户端推送一次配置变更，但客户端库实现各异；某些老版本库不监听 +switch-master 事件，需升级或手动刷新

最容易被忽略的一点：哨兵之间必须能互相通信，且与所有 Redis 实例的网络连通性要双向正常——不是只要哨兵能 ping 通 Redis 就行，Redis 实例也必须能反向连接哨兵的 26379 端口，否则 _sentinel_:hello 频道订阅会失败，导致哨兵集群无法达成共识。