Redis哨兵模式（Sentinel）深度解析

基于黑马程序员《Redis黑马点评》高级篇整理。哨兵模式是解决**主从架构"自动故障恢复"**的核心方案，也是高可用集群的基石。

一、为什么需要哨兵？

1.1 主从架构的痛点

在基础的主从复制中，如果Master节点宕机，虽然Slave节点数据完整，但：

写服务不可用：客户端无法写入。
需人工干预 ：必须手动执行 slaveof no one将某个Slave提升为Master，并修改客户端配置。
恢复慢：人工操作耗时，业务中断时间长。

1.2 哨兵的价值

哨兵（Sentinel）是一个独立的分布式进程 ，专门用于监控Redis节点，并实现自动故障转移（Failover）：

自动选主：Master宕机后，自动选举新的Master。
自动切换：知客户端和Slave节点新的Master地址。
高可用：哨兵自身也是集群部署，避免单点故障。

二、哨兵的核心工作机制

哨兵的工作流程可以概括为监控 -> 判定 -> 选举 -> 切换。

2.1 监控（Monitoring）

哨兵节点通过心跳机制（每秒一次的PING）监控所有Master和Slave的状态。

主观下线（SDOWN）：单个哨兵在配置的时间（如30秒）内未收到Master的响应，则标记其为"主观下线"。这仅代表该哨兵的个人判断，可能存在误判（如网络抖动）。
客观下线（ODOWN） ：当法定数量（quorum） 的哨兵都认为Master主观下线时，Master被标记为"客观下线"，此时才真正触发故障转移流程。

2.2 故障转移流程（Failover）

一旦Master被客观下线，哨兵集群会执行以下步骤：

选举哨兵Leader ：哨兵节点间通过Raft算法选举出一个Leader，由它来负责执行具体的故障转移操作（避免多个哨兵同时执行导致混乱）。
选举新Master：Leader根据规则从Slave中选出一个晋升为Master：
- 首先排除网络连接不佳或已下线的Slave。
- 优先选择优先级（slave-priority） 最高的节点（配置文件中设置，值越小优先级越高）。
- 优先级相同则选择复制偏移量（repl_offset） 最大的节点（数据最完整）。
- 若仍相同，则选择Run ID 较小的节点。
切换与通知：
- 向新Master发送 SLAVEOF NO ONE命令。
- 向其他Slave发送 SLAVEOF <new-master-ip> <new-master-port>，使其同步新Master。
- 更新自身元数据，将原Master标记为Slave（待其恢复后自动成为新Master的从节点）。

三、黑马点评项目实战：搭建与配置

3.1 哨兵集群搭建（以3节点为例）

哨兵通常部署奇数个（如3个），以方便进行Leader选举（避免脑裂）。

准备配置文件 （如 sentinel-26379.conf）：

shell 复制代码

# 哨兵端口
port 26379
# 监控的主节点：mymaster为集群名，1为quorum值（至少需要1个哨兵同意）
sentinel monitor mymaster 127.0.0.1 6379 2
# 主观下线判定时间（毫秒）
sentinel down-after-milliseconds mymaster 30000
# 故障转移超时时间
sentinel failover-timeout mymaster 180000
# 如果Redis有密码，必须配置
sentinel auth-pass mymaster your_redis_password

启动哨兵：

powershell 复制代码

redis-server sentinel-26379.conf --sentinel

验证状态：

shell 复制代码

redis-cli -p 26379
127.0.0.1:26379> info sentinel

3.2 SpringBoot整合（RedisTemplate）

在 application.yml中配置哨兵模式，客户端无需直接连接Master，而是通过哨兵动态获取Master地址：

shell 复制代码

spring:
  redis:
    password: 123456
    sentinel:
      master: mymaster # 哨兵中定义的集群名
      nodes: # 哨兵节点列表
        - 127.0.0.1:26379
        - 127.0.0.1:26380
        - 127.0.0.1:26381

注意：哨兵模式下，RedisTemplate默认仍为读写Master 。若需实现读写分离（读Slave），需额外配置 LettucePool或使用 @ReadOnly注解。

四、关键配置与调优

配置项	说明	生产建议
`quorum`	判定客观下线所需的最少哨兵票数	通常设为 `哨兵总数/2 + 1`（如3哨兵设为2）
`down-after-milliseconds`	主观下线判定超时	网络稳定可设小（如15s），不稳定设大（如30s）
`failover-timeout`	故障转移超时时间	默认3分钟，超时则放弃本次切换
`parallel-syncs`	故障转移后，同时向新Master同步的Slave数	设为1，避免新Master压力过大

五、面试高频考点

主观下线 vs 客观下线？
- 主观下线：单哨兵认为Master不可用，可能是误判。
- 客观下线 ：quorum个哨兵达成共识，确认Master故障，只有客观下线才会触发故障转移。
哨兵如何选举新Master？
- 先看优先级 （slave-priority），再看数据同步进度 （offset），最后看Run ID。
哨兵集群如何通信？
- 通过Redis的发布/订阅（Pub/Sub） 机制，在Master的 __sentinel__:hello频道进行通信，实现相互发现。
哨兵模式的数据一致性？
- 由于主从复制是异步的，故障转移时可能丢失少量数据（原Master未来得及同步给新Master的数据）。对于强一致性要求高的业务（如余额），需在代码中做补偿（如写后读主库校验）。

黑马点评总结：哨兵模式解决了主从架构的"自动故障恢复"问题，是构建高可用缓存服务的必备组件。在项目中，通常配合主从复制（读写分离）使用，确保在Master宕机时，秒杀、优惠券等核心业务能快速自动恢复。