主从复制有个绕不开的短板：
它撑不起 Redis 的高可用。
主节点一旦宕机，整个集群就失去了写入能力。
哨兵模式就是为解决这个问题而生的，它能让主从集群自动完成故障恢复。
哨兵到底是什么
哨兵节点本质也是 Redis 实例，一般由多台组成集群，生产上至少部署 3 个。
它干三件事。
第一是监控，持续探活主从节点，确认它们都在正常工作。
第二是自动故障恢复，主节点挂了，哨兵会挑一个从节点顶上去继续服务；从节点挂了，它会自动剔除。
第三是通知，客户端通过 Sentinel 获取当前主节点地址，主节点切换后能够自动发现新的 Master。
这三件事合起来，就是 Redis 主从高可用的底气。
哨兵是怎么盯哨的
哨兵靠心跳机制判断服务生死，默认每 1 秒向集群每个实例发一次 PING。
收到 PONG 就说明实例活着。
如果某个实例在限定时间内没回 PONG，这台哨兵就单方面判定它"主观下线"。
注意，主观下线只是这一台哨兵自己的判断。
要确认节点真挂了，还得其他哨兵一起投票。
当认为它下线的哨兵数量达到 quorum 阈值，才会被标记为"客观下线"。
这个 quorum 值在 redis.conf 里配，quorum 通常配置为能够形成多数判断的数量，例如 3 个 Sentinel 时通常设置为 2。
主节点挂了，哨兵怎么选新主
首先会过滤掉长时间断开的从节点，然后按照优先级、复制偏移量、run id 依次选择。
第一条看断连时长。从节点跟主节点断开太久，直接失去候选资格，因为断得越久丢的数据越多。这个时长在配置文件里设。
第二条比优先级，配置项值越小优先级越高，优先被选。优先级同样可配。
第三条比 offset。优先级相同就看复制偏移量，offset 越大说明数据越接近原主节点，越先被选中。
第四条基本轮不到，前面都相同时才按 run id 随便挑一个。
四条里最关键的其实是第三条：offset 越大，数据越全，越优先上位。
不过哨兵模式也不是万能，它有个经典坑叫"脑裂"，也是面试的高频题。
脑裂：一个大脑裂成两个
看一个正常的主从加哨兵架构。
假如主节点和哨兵被网络切到了不同分区，哨兵连不上主节点，只能看到从节点。
按选主规则，哨兵会从从节点里提拔一个新主。
但老主节点其实没挂，只是网络断了，客户端还连着它。
于是集群里同时出现了两个 master，像大脑分裂了一样，这就是脑裂。
问题来了：
客户端还在往老主写数据，新主因为网络不通根本同步不到。
等网络恢复，哨兵把老主强制降级成从节点，老主要从新主全量同步，本地数据被清空。
脑裂期间客户端写进老主的数据，就这么丢了。
脑裂怎么治
两个配置就能大幅止血。
第一，设 min-replicas-to-write 至少为 1。
意思是主节点要接收写请求，必须至少有 1 个从节点在线。
连不上从节点，主节点直接拒绝写入。
第二，设置 min-replicas-max-lag，限制从节点 ACK 延迟时间。
两个条件任一不满足，主节点就拒绝客户端写请求。
这样即使发生脑裂，也能拦住大量数据写进孤岛，避免恢复后清空丢失。
面试实战：三连问
问：怎么保证 Redis 的高可用？
答案就是哨兵模式，它让主从集群能自动故障恢复，包含三个作用。
监控，盯住每个实例是否健康。
自动故障恢复，主节点挂了按选主规则提拔从节点顶上。
通知，哨兵主动告诉客户端该连哪个 Redis。
问：你们 Redis 是单点还是集群？用的哪种集群？
参考答法：
主从通常一主一从加哨兵就够。
单节点内存控制在 10G 以内。
Redis 是缓存，不该把海量数据硬塞进去，只放热点数据，一般项目 10G 足够。
一主一从能扛住多数项目的高并发和高可用：
主节点负责写，从节点负责读，Redis 单节点通常可以支撑数万到十万级 QPS，具体性能取决于硬件和业务模型，多数业务根本触不到这个上限。
数据量特别大时，就按业务拆多套主从，比如订单服务一套、秒杀服务一套，多套集群并行解决容量问题。
问：Redis 集群脑裂怎么解决？
先讲清脑裂：
主从和哨兵处在不同网络分区，哨兵收不到主节点心跳，就把一个从节点提成了主节点，出现两个 master。
客户端还在老主写数据，新主同步不到。
网络恢复后老主降级成从节点，从新主同步数据，导致老主在脑裂期间写入的数据大量丢失。
解决靠改两个配置：
设最小从节点数，缩短主从同步延迟上限。
不达标就直接拒绝客户端写请求，从而避免大量数据丢失。