哨兵节点数必须为奇数，3个是生产最小可行配置，需分散部署且quorum设为2；偶数节点易因平票导致故障转移失效，quorum须严格按(N/2)+1配置并校验一致。
哨兵节点数必须是奇数，3个是生产可用的下限
单个哨兵完全没用——它无法区分“主节点真挂了”还是“自己网络断了”。3个是最小安全配置，但必须满足两个硬条件：分散部署在不同物理机或隔离的容器里，quorum 值设为 2（即 sentinel monitor mymaster 192.168.1.10 6379 2）。如果全塞在同一台机器上，这台机器一宕，整个哨兵集群就集体失能。
为什么不能用 4 个哨兵？
偶数节点在故障判定时容易卡死：4 个哨兵中若恰好 2 个认为主节点下线、2 个认为正常，就无法达成多数共识，+odown 事件永远不会触发，故障转移直接失效。而 3 个哨兵只要 2 票就能推进，5 个需要 3 票，天然避开平票。quorum 公式是 (N / 2) + 1（N 为哨兵总数），不是简单“过半”。
quorum 配错，哨兵会“装死”
常见错误是把 quorum 设得太大（比如 3 个哨兵却配成 3）或太小（配成 1）。前者导致永远凑不够票数；后者可能因单个哨兵误判就触发转移，引发脑裂。上线前务必用 redis-cli -p 26379 sentinel masters 检查输出里的 quorum 字段是否与配置一致。
客户端必须连全部哨兵地址，不能只写一个
客户端初始化时向哨兵查主节点地址，之后直连 Redis；但哨兵地址列表必须填全（如 3 个 IP+端口）。否则某个哨兵宕机后，客户端无法 failover 到其他哨兵获取新主信息，连接就会卡死。go-redis、redis-py、Lettuce 等库都要求传入哨兵列表，不是单点地址。
真正容易被忽略的是网络拓扑：哨兵和 Redis 节点混部可以，但别让所有哨兵共享同一台交换机、同一块网卡、同一个云厂商可用区。故障从来不是“Redis 进程崩了”，而是整台机器、整个网络分区挂掉。
