Redis Sentinel哨兵机制

一、哨兵三大核心作用

1. 监控：多个Sentinel节点通过心跳持续巡检Master、Slave实例状态，每秒发送PING指令探测存活。
2. 自动故障转移：Master被判定客观下线后，哨兵集群选举合适的Slave晋升为新Master；原故障Master恢复上线后，自动降级为新主节点的从节点。
3. 通知：充当服务注册发现角色，主从切换后主动推送最新主节点地址，客户端可自动切换连接目标。

二、下线判定规则

1. 主观下线 SDOWN

单个Sentinel节点探测目标实例，超时未收到PING响应，仅当前哨兵将该节点标记为主观下线，不代表节点真实故障。

2. 客观下线 ODOWN

集群中满足quorum法定票数（超过半数哨兵）都将主节点标记为主观下线，此时判定Master为客观下线，正式触发故障转移。 配置建议：哨兵节点总数设为奇数（3个/5个），保证quorum数值大于哨兵总数一半。

三、故障转移：Slave晋升Master优先级规则

依次按以下条件比对，优先级从上至下排序：

1. 断开时间：与原Master失联超时的从节点直接淘汰，优先选择断线时间更短的Slave。
2. slave-priority 从库优先级：对应配置项slaveof-priority，数值越小优先级越高；默认值为100，设置为0的节点永远无法晋升为主节点。
3. offset偏移量：前两项相同时，repl_backlog offset数值越大，代表数据同步越完整，优先升级。
4. 实例运行ID：前三项全部一致时，实例运行ID字符串越小，越优先成为新主节点。

四、生产部署选型&面试问答

1. 常规架构选型

中小规模业务采用 1主N从 + 3个哨兵 架构；单Redis实例内存建议控制在10G以内，若内存不足，按业务维度拆分多套独立的主从+哨兵集群。

2. 脑裂问题（网络分区故障）

脑裂成因

出现网络分区，原Master与哨兵集群网络不通。哨兵探测不到旧Master，选举出新Master；而部分客户端依旧连接孤立的旧Master写入数据。当网络恢复后，旧Master降级为从节点，会全量同步新Master数据，导致旧Master上独有的写入数据全部丢失。

解决方案

通过配置 min-replicas-to-write + min-replicas-max-lag 限制写入：主节点必须保证至少N个从库，且同步延迟在指定毫秒范围内，不满足条件则主节点拒绝客户端写入，以此规避大量数据丢失。

五、面试高频问题解析

1. 问：Redis哨兵有哪些核心功能？

   答： 一是监控，定时心跳探测所有主从节点状态；二是自动故障转移，主节点客观下线后选举从库升级为主节点，故障节点恢复后自动降级为从库；三是消息通知，主动向客户端推送最新主节点地址。

2. 问：主观下线和客观下线有什么区别？

   答： 主观下线是单个哨兵判定节点异常，仅自身标记，不作故障处理；客观下线需要超过半数哨兵都判定主节点主观下线，此时认定节点真实故障，触发故障转移。

3. 问：哨兵选择新主节点的规则是什么？

   答： 优先排除失联超时的从库；再比较从库优先级，数值越小越优先；其次看数据同步偏移量，偏移越大数据越完整优先级越高；最后对比实例运行ID。

4. 问：什么是脑裂，如何解决？

   答： 网络分区导致集群出现两个主节点，客户端向旧主写入的数据会在网络恢复后丢失。通过配置min-replicas-to-write和min-replicas-max-lag，限制主节点写入条件，降低数据丢失风险。

5. 问：生产环境哨兵集群如何部署？

   答： 常规使用一主多从搭配3个哨兵，哨兵数量建议设为奇数；控制单实例内存大小，内存不足则拆分多套主从哨兵集群。