Redis：哨兵模式 (Sentinel)

在 Redis 的日常使用中，主从复制 (Master-Slave Replication) 是我们最常用的一种架构。它通过将一台 Redis 服务器（主节点）的数据单向复制到其他服务器（从节点），实现了数据的冗余热备份，并能通过读写分离分担服务器的负载。

但是，单纯的主从架构并不是为了提供高可用性而设计的。它的一个致命弱点是：如果 Master 节点挂了，系统无法自动在 Slave 节点中重选一个 Master，每次都需要人工干预才能恢复写服务。

为了实现真正的高可用，Redis 引入了哨兵模式 (Sentinel) 。

文章目录

[一、什么是 Redis Sentinel？](#一、什么是 Redis Sentinel？)
二、哨兵模式架构图
三、哨兵工作原理
- [1. 实时监控](#1. 实时监控)
- 2、主观下线（sdown）
- [3. 客观下线（odown）](#3. 客观下线（odown）)
- [4. 领导者选举](#4. 领导者选举)
- [5. 故障转移（Failover）](#5. 故障转移（Failover）)
四、哨兵配置实战
[五、启动 Sentinel](#五、启动 Sentinel)
六、哨兵模式的局限性
七、总结

一、什么是 Redis Sentinel？

Redis Sentinel 是 Redis 官方提供的一套高可用解决方案。

它通过运行独立的 Sentinel 进程，对 Redis 主从节点进行持续监控。

当主节点发生故障时：

自动发现故障
自动选举新的主节点
自动修改主从关系
自动通知客户端

从而保证 Redis 服务持续可用。

二、哨兵模式架构图

说明：

Sentinel1、2、3负责监控
Master提供读写
Slave负责同步数据
哨兵不存储业务数据
哨兵只负责监控和故障转移

三、哨兵工作原理

1. 实时监控

每个 Sentinel 都会定期向 Redis 节点发送：

bash 复制代码

PING

Redis 正常时返回：

bash 复制代码

PONG

则进入故障判定阶段。

2、主观下线（sdown）

当某个 Sentinel 发现：Master 在规定时间内没有响应

则会认为：Master 已下线

此时称为：Subjectively Down

注意：

此时只是当前 Sentinel 的个人判断。

3. 客观下线（odown）

为了避免误判：

Sentinel 会向其他 Sentinel 询问：

bash 复制代码

SENTINEL is-master-down-by-addr

例如：

Sentinel1：我认为 Master 挂了
Sentinel2：我同意
Sentinel3：我同意

如果同意数量达到：

quorum(配置值)

例如：

bash 复制代码

sentinel monitor mymaster 192.168.200.130 6379 2

表示：

至少2个 Sentinel 同意

才能认定 Master 真正故障。

此时进入：

客观下线（odown）

4. 领导者选举

确认主节点故障后：多个 Sentinel 会进行投票。

规则：

谁先发起选举
谁先获得多数票
谁成为 Leader

例如：

Sentinel1 获得 2票

Sentinel2 获得 1票

Sentinel3 获得 0票

最终：

Sentinel1 成为 Leader

负责执行故障转移。

5. 故障转移（Failover）

Leader 开始挑选新的主节点。

筛选规则：

第一步：过滤异常节点

排除：

离线节点

同步失败节点

网络异常节点

第二步：比较复制偏移量
Redis 中：
offset 越大
数据越完整

例如：

Slave1 offset=10000

Slave2 offset=9500

则优先选择：

Slave1

第三步：提升为主节点
Leader 执行：

bash 复制代码

SLAVEOF NO ONE

此时：

Slave1

↓

Master

第四步：修改其他从节点

bash 复制代码

SLAVEOF 新MasterIP 新MasterPort

例如：

bash 复制代码

SLAVEOF 192.168.200.131 6379

此时：

Slave2

↓

跟随新的 Master

四、哨兵配置实战

创建 sentinel.conf

bash 复制代码

port 26379

sentinel monitor mymaster 192.168.200.130 6379 2

sentinel down-after-milliseconds mymaster 5000

sentinel failover-timeout mymaster 10000

sentinel parallel-syncs mymaster 1

参数说明

monitor

bash 复制代码

sentinel monitor mymaster 192.168.200.130 6379 2

含义：

监控主节点

IP：192.168.200.130

端口：6379

法定票数：2

down-after-milliseconds

其实就是第二行后面的数字5000

5秒无响应

判定为主观下线

failover-timeout

10000

表示故障转移最大超时时间

parallel-syncs

1

每次只允许1个从节点同步

防止网络压力过大。

五、启动 Sentinel

启动命令：

bash 复制代码

redis-sentinel sentinel.conf

查看状态：

bash 复制代码

redis-cli -p 26379

bash 复制代码

info Sentinel

输出：

bash 复制代码

sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0

说明 Sentinel 已正常运行。

六、哨兵模式的局限性

七、总结

哨兵模式是 Redis 迈向高可用的重要一步，它通过自动化监控和故障转移，极大地解放了运维人员的双手。然而，如果你面临的是单机内存瓶颈，或者需要极其庞大的并发写能力，单靠哨兵模式依然不够。面对这种情况，Redis 提供了真正的分布式运行模式------集群部署 (Cluster) 。