深入理解 Redis 哨兵模式：高可用架构的自动容错实践

在生产环境中，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. 三个核心定时任务

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

频率	任务	作用
每 10 秒	向所有 Master / Slave 发送 `INFO`	获取最新的 Redis 拓扑结构
每 2 秒	向 `__sentinel__:hello` 频道发布/订阅	哨兵间交换信息、发现新哨兵
每 1 秒	向所有节点（哨兵+Redis）发送 `PING`	心跳检测，判断节点是否存活

这三个任务构成一个闭环：

心跳发现异常 → 协商确认下线 → 从拓扑中选择新主 → 广播新主信息。
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

三、四大核心功能

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

监控 (Monitoring)

持续检查主从节点是否在线、角色是否正确。
自动故障转移 (Automatic Failover)

主节点故障后，自动从从节点中选举一个提升为新主节点，并通知其他从节点跟随新主。
配置提供者 (Configuration Provider)

客户端直接连接哨兵，哨兵充当服务发现中心，返回当前主节点的地址。这样主节点变化时，客户端无需修改配置。
text 复制代码
```
客户端 -> 哨兵: "mymaster 的主是谁？"
哨兵 -> 客户端: "当前主节点是 192.168.6.217:7002"
客户端 -> 新主: 正常读写
```
通知 (Notification)

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

四、选主逻辑

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

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

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

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

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

主机 IP	端口	组件	版本
192.168.6.217	7001	Redis (master)	6.2.14
192.168.6.217	7002	Redis (slave)	6.2.14
192.168.6.217	7003	Redis (slave)	6.2.14
192.168.6.212	27001	Sentinel	6.2.14
192.168.6.212	27002	Sentinel	6.2.14
192.168.6.212	27003	Sentinel	6.2.14

部署原则

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

步骤一：搭建 Redis 主从

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

步骤二：配置并启动 Sentinel

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

bash 复制代码

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

sentinel_27001.conf 关键配置：

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 的配置文件，只需修改端口和日志、数据目录即可。

启动所有哨兵：

bash 复制代码

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 &

验证哨兵进程：

bash 复制代码

ps -ef | grep sentinel

六、常用运维命令

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

bash 复制代码

redis-cli -p 27001

命令	说明
`INFO Sentinel`	查看本哨兵视角的整体信息
`SENTINEL SENTINELS mymaster`	列出监控 `mymaster` 的其他哨兵
`SENTINEL masters`	列出所有被监控的主节点
`SENTINEL master mymaster`	查看 `mymaster` 的详细状态
`SENTINEL get-master-addr-by-name mymaster`	获取当前主节点地址
`SENTINEL REPLICAS mymaster`	查看 `mymaster` 的所有从节点

七、故障转移测试

1. 正常查看主节点

bash 复制代码

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

2. 模拟主节点宕机

bash 复制代码

redis-cli -p 7001 -a 123456
> SHUTDOWN

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

bash 复制代码

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

3. 强制故障转移

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

bash 复制代码

redis-cli -p 27001
> SENTINEL FAILOVER mymaster
OK

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

八、客户端如何接入？

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

java 复制代码

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 才是更好的选择。哨兵模式主要解决高可用，不提供数据分片。对于读多写少、单机内存可容纳全量数据的业务，哨兵模式简洁、高效，至今仍被广泛采用。