在生产环境中，Redis 作为缓存或数据库，一旦宕机就可能造成服务雪崩。哨兵模式（Sentinel） 正是为此而生——它能自动完成故障发现与主从切换，无需人工干预。本文将系统梳理哨兵模式的原理、功能、选主逻辑，并通过一个完整的搭建示例，带你掌握这套高可用方案。

一、核心概览

Redis 哨兵模式是一套分布式的高可用解决方案，核心目标就一个：

当主节点宕机时，自动将某个从节点提升为新主节点，让集群继续正常服务。

整个系统由一组哨兵进程和一组Redis实例组成，哨兵之间通过共识机制完成故障判定和切换。

下图展示了典型的哨兵架构：

graph TD subgraph 哨兵集群 S1[Sentinel 1] S2[Sentinel 2] S3[Sentinel 3] end subgraph Redis 集群 M[Master] R1[Slave 1] R2[Slave 2] end S1 -->|监控| M S1 -->|监控| R1 S1 -->|监控| R2 S2 -->|监控| M S2 -->|监控| R1 S2 -->|监控| R2 S3 -->|监控| M S3 -->|监控| R1 S3 -->|监控| R2 S1 <-->|通信| S2 S1 <-->|通信| S3 S2 <-->|通信| S3 M --> R1 M --> R2

二、工作原理

哨兵模式依赖三个关键机制实现自动化运维。

1. 分布式监控与协商

• 每个哨兵节点会同时监控所有 Redis 节点（主、从）以及其他哨兵节点。
• 当某个哨兵发现某节点不可达时，会将其标记为主观下线（SDOWN）。
• 随后它会询问其他哨兵，当足够数量（可配置的 quorum）的哨兵都认为该节点已下线，就将其标记为客观下线（ODOWN），并触发故障转移。

sequenceDiagram participant S1 as Sentinel 1 participant S2 as Sentinel 2 participant S3 as Sentinel 3 participant M as Master Note over S1,M: 正常心跳监控 S1->>M: PING M--xS1: 无响应 S1->>S1: 判定 SDOWN S1->>S2: 询问 Master 状态 S1->>S3: 询问 Master 状态 S2-->>S1: 也认为下线 S3-->>S1: 也认为下线 S1->>S1: 达成 quorum，判定 ODOWN S1->>S2: 发起故障转移投票 S2-->>S1: 同意 S3-->>S1: 同意 S1->>S1: 选举新 Master，执行切换

2. 三个核心定时任务

哨兵通过三个周期性的任务维持整个集群的健康感知：

这三个任务构成一个闭环：
心跳发现异常 → 协商确认下线 → 从拓扑中选择新主 → 广播新主信息。

graph LR subgraph 每10秒 A[INFO 命令] --> B[更新拓扑] end subgraph 每2秒 C[发布/订阅 hello 频道] --> D[哨兵发现彼此] end subgraph 每1秒 E[PING 心跳] --> F{超时?} F -->|是| G[主观下线] end G --> H[询问其他哨兵] H --> I{达成 quorum?} I -->|是| J[客观下线 + 故障转移] B --> K[选主参考] K --> J

三、四大核心功能

哨兵不仅仅是一个“看门狗”，它还承担了服务发现和通知的职责。

1. 监控 (Monitoring)
   持续检查主从节点是否在线、角色是否正确。

2. 自动故障转移 (Automatic Failover)
   主节点故障后，自动从从节点中选举一个提升为新主节点，并通知其他从节点跟随新主。

3. 配置提供者 (Configuration Provider)
   客户端直接连接哨兵，哨兵充当服务发现中心，返回当前主节点的地址。这样主节点变化时，客户端无需修改配置。

   客户端 -> 哨兵: “mymaster 的主是谁？”
   哨兵 -> 客户端: “当前主节点是 192.168.6.217:7002”
   客户端 -> 新主: 正常读写
   

4. 通知 (Notification)
   当发生下线、故障转移等事件时，可通过脚本（如 sentinel notification-script）或发布/订阅机制通知管理员。

四、选主逻辑

当原主节点被判定客观下线，哨兵会按以下优先级从所有健康的从节点中选出新主：

1. 优先级：slave-priority 配置值越小的从节点越优先（默认均为100）。
2. 偏移量：复制偏移量越大，表示从主节点同步的数据越完整。
3. 运行 ID：在优先级和偏移量都相同的情况下，选择运行 ID 字典序最小的节点（保证确定性）。

这种多层策略确保选出的新主既能最快接管，又拥有最完整的数据。

五、实战：搭建一主两从三哨兵

假设我们有三台机器，部署规划如下（可部署在同一机器不同端口，生产环境应分散到不同物理机）：

部署原则

• 物理分散：哨兵节点决不要部署在同一台物理机上，否则宿主机宕机会导致整个哨兵集群失效。
• 奇数个节点：至少 3 个且为奇数，保证故障判定时能达成多数派（quorum）。
• 管控粒度：根据规模选择，可一套哨兵管控一套 Redis，也可一套哨兵管控多套（通过不同主节点名区分）。

步骤一：搭建 Redis 主从

一主两从的配置省略，确保 7001 为主，7002、7003 为从即可。

步骤二：配置并启动 Sentinel

创建数据目录和配置文件，这里以 27001 为例，其余两个同理。

mkdir -p /usr/local/redis6/data/sentinel_{27001,27002,27003}

sentinel_27001.conf 关键配置：

port 27001
daemonize yes
logfile "/usr/local/redis6/log/27001.log"
dir /usr/local/redis6/data/sentinel_27001

# 监控的主节点名称为 mymaster，ip:port，quorum=2
sentinel monitor mymaster 192.168.6.217 7001 2
sentinel auth-pass mymaster 123456
sentinel down-after-milliseconds mymaster 10000

同样的方式生成 27002 和 27003 的配置文件，只需修改端口和日志、数据目录即可。

启动所有哨兵：

nohup redis-sentinel /usr/local/redis6/conf/sentinel_27001.conf &
nohup redis-sentinel /usr/local/redis6/conf/sentinel_27002.conf &
nohup redis-sentinel /usr/local/redis6/conf/sentinel_27003.conf &

验证哨兵进程：

ps -ef | grep sentinel

六、常用运维命令

连接任意哨兵即可查看集群状态。

redis-cli -p 27001

七、故障转移测试

1. 正常查看主节点

redis-cli -p 27001
> SENTINEL get-master-addr-by-name mymaster
1) "192.168.6.217"
2) "7001"

2. 模拟主节点宕机

redis-cli -p 7001 -a 123456
> SHUTDOWN

此时哨兵会在 down-after-milliseconds (10秒) 后判定主观下线，并经过协商达到 quorum 后执行故障转移。再次查询主节点，应该已经切换到新的从节点（例如 7002）：

> SENTINEL get-master-addr-by-name mymaster
1) "192.168.6.217"
2) "7002"

3. 强制故障转移

即使主节点正常，你也可以通过命令直接触发切换，用于演练或维护。

redis-cli -p 27001
> SENTINEL FAILOVER mymaster
OK

切换后立即生效，客户端通过哨兵获取到的新主地址也会更新。

八、客户端如何接入？

使用哨兵模式时，客户端不再直接连接 Redis 的固定 IP，而是连接哨兵，并指定主节点名称（如 mymaster）。主流客户端（Jedis、Lettuce、redis-py 等）都支持 Sentinel 模式。例如 Java 的 Jedis：

Set<String> sentinels = new HashSet<>();
sentinels.add("192.168.6.212:27001");
sentinels.add("192.168.6.212:27002");
sentinels.add("192.168.6.212:27003");
JedisSentinelPool pool = new JedisSentinelPool("mymaster", sentinels);

无论后端主节点如何漂移，客户端都能从哨兵自动获取最新地址。

九、总结

Redis 哨兵模式用一套轻量的分布式监控组件，解决了 Redis 单点故障的自动恢复问题。它的核心运作依赖三个定时任务、主观/客观下线判定、以及基于优先级的选主逻辑。部署时要牢记物理分散、奇数节点、合理规划 quorum。再配合客户端的哨兵感知能力，即可构建出一个生产可用的 Redis 高可用方案。

但在数据分片、横向扩展场景下，Redis Cluster 才是更好的选择。哨兵模式主要解决高可用，不提供数据分片。对于读多写少、单机内存可容纳全量数据的业务，哨兵模式简洁、高效，至今仍被广泛采用。