哨兵节点数量必须为奇数，因故障判定和主节点选举依赖多数派协议（quorum ≥ n/2 + 1），偶数易致平票僵局；3个是容错下限，须分散部署且quorum值须与实际哨兵数严格匹配。
哨兵节点数量为什么必须是奇数？
因为哨兵的故障判定和主节点选举依赖“多数派协议”（quorum），不是简单过半，而是需要至少 quorum ≥ (sentinel总数 / 2) + 1 个哨兵达成一致。偶数节点会导致平票——比如 4 个哨兵，2 票赞成宕机、2 票反对，无法触发故障转移；而 3 个哨兵时，只要 2 票同意就能推进，5 个则需 3 票，天然避开僵局。
-
quorum值在配置中显式指定，如sentinel monitor mymaster 192.168.1.10 6379 2，它必须 ≤ 实际哨兵总数，且推荐设为(N/2)+1（N 为哨兵数） - 哨兵进程本身不存数据、不处理业务请求，资源开销极小；多部署 1–2 个不会拖慢性能，但少 1 个可能让整个高可用机制失效
- 生产环境严禁只用 1 个哨兵：它无法判断是“主节点真挂了”，还是“自己网络断了”，会直接失能
3 个哨兵是最小可行配置，但别全塞在同一台机器上
3 节点是满足容错的下限，但若它们都跑在同一物理机或同一云主机上，这台机器一宕，哨兵集群就集体失联，等同于没部署。真实故障场景里，单点硬件/系统/网络故障远比 Redis 进程崩溃更常见。
- 优先把 3 个哨兵分散到不同服务器，哪怕只是三台低配虚拟机；实在资源紧张，至少确保它们跨操作系统实例（如不同 Docker 容器 + host 网络隔离）
- 哨兵可以和 Redis 数据节点混部（例如每台机器跑 1 主/1 从 + 1 哨兵），但要避免把所有角色压在一台机器的单个 OS 进程里
- 监控时重点看
sentinel_masters:1和sentinels:3是否稳定匹配，而不是只盯status=ok
quorum 配置写错，哨兵就“装死”不干活
很多人配完哨兵发现主节点挂了却没人接管，翻日志全是 +sdown master 但没有 +odown 或 +switch-master，问题往往出在 quorum 值设得太大或太小。
- 设成 1：任意一个哨兵觉得主挂了就强制切换，极易误判（比如短暂网络抖动）
- 设成 3 但只起了 2 个哨兵：永远凑不够 3 票，
odown永远不会触发 - 正确做法：启动前确认哨兵总数，再按公式算
quorum；上线后用redis-cli -p 26379 sentinel masters检查输出中的quorum字段是否与配置一致
客户端连哨兵，不是连 Redis，但不能只连一个哨兵地址
客户端初始化时向哨兵询问当前主节点地址，之后直连 Redis 主节点；但哨兵地址列表必须提供全部哨兵节点（如 3 个 IP+端口），否则某个哨兵宕机后，客户端无法 failover 到其他哨兵获取新主信息。
- 错误写法：
sentinel.add_sentinel("192.168.1.10", 26379)—— 只加了一个 - 正确写法（以 Jedis 为例）：
Set<string> sentinels = new HashSet(); sentinels.add("192.168.1.10:26379"); sentinels.add("192.168.1.11:26379"); sentinels.add("192.168.1.12:26379");</string> - 客户端库必须支持 Sentinel 自动发现，老版本 Jedis/Lettuce 或自研 SDK 若只实现静态 IP 列表，会在这里掉坑里
