Redis Sentinel 高可用架构详解与实践
一、Sentinel 核心概念
1. Sentinel 的定位
Redis Sentinel 是官方提供的高可用解决方案，用于解决主从复制架构中主节点故障时的自动切换问题。它是一个独立的守护进程，能够监控多个主从集群，在主节点不可用时自动完成故障转移。
2. 核心功能架构
Sentinel 作为监控中心，持续检测主从节点的健康状态，并在异常时触发自动化的故障恢复流程。
3. 三大核心职责
- 健康监控：周期性检查主从节点运行状态
- 事件通知：通过 API 向管理员或应用发送告警
- 自动故障转移：主节点失效时自动选举新主节点，并重新配置复制关系
二、节点发现机制
1. 主节点发现
Sentinel 通过配置文件中的 sentinel monitor 指令定位主节点，随后建立两类连接：
- 命令连接：用于发送监控指令
- 订阅连接：订阅
__sentinel__:hello频道，发现其他 Sentinel
配置示例
# 启动 Sentinel 服务
redis-sentinel /etc/redis/sentinel.conf
# 多集群监控配置
sentinel monitor cluster-alpha 192.168.1.10 6379 2
sentinel down-after-milliseconds cluster-alpha 30000
sentinel parallel-syncs cluster-alpha 1
sentinel failover-timeout cluster-alpha 180000
sentinel monitor cluster-beta 192.168.1.20 6379 3
sentinel down-after-milliseconds cluster-beta 50000
sentinel parallel-syncs cluster-beta 2
sentinel failover-timeout cluster-beta 3000002. 从节点自动发现
Sentinel 通过向主节点发送 INFO 命令获取从节点列表，无需手动配置。发现从节点后，同样建立命令连接和订阅连接。
3. Sentinel 节点发现
各 Sentinel 节点通过发布/订阅机制相互感知：
- 每 2 秒向
__sentinel__:hello频道广播自身信息（IP、端口、运行 ID） - 同时订阅该频道接收其他 Sentinel 的广播
- 新节点加入时，对比配置版本，自动更新为最新配置
- 通过运行 ID 或地址去重，维护已知节点列表
4. 节点间通信
Sentinel 之间仅建立命令连接进行直接通信，订阅连接通过主从节点中转，避免网状订阅连接。
三、故障检测机制
1. 主观下线（SDOWN）
单个 Sentinel 通过 PING 命令判定节点状态。若节点在 down-after-milliseconds 时间内未返回有效响应，则被标记为主观下线。
有效响应包括：
+PONG-LOADING（加载中）-MASTERDOWN（主节点宕机）
2. 客观下线（ODOWN）
当足够数量的 Sentinel（达到配置中的法定票数）都将主节点标记为 SDOWN 时，触发客观下线。此判定仅针对主节点，从节点和 Sentinel 节点不存在客观下线概念。
Sentinel 通过 SENTINEL is-master-down-by-addr 命令交换各自的判定结果，采用流言协议（Gossip Protocol）达成共识。
四、故障转移流程
1. 选举 Leader Sentinel
基于 Raft 算法选举领头 Sentinel，确保同一时期内只有一个执行者：
- 每个 Sentinel 在一个 epoch 内只投一票
- 获得多数票的 Sentinel 成为 Leader
- 选举失败则在超时后重试
2. 新主节点选择策略
筛选条件：
1. 排除已主观下线、断线或响应延迟超过 5 秒的从节点
2. 排除与主节点断开时间超过 down-after 时长 10 倍的从节点
优选规则：
1. 选择复制偏移量（replication offset）最大的从节点
2. 若偏移量相同，选择运行 ID 最小的从节点3. 故障转移执行步骤
- 向选中的从节点发送
SLAVEOF NO ONE升级为主节点 - 通过发布/订阅广播新配置，其他 Sentinel 同步更新
- 向其他从节点发送
SLAVEOF指向新主节点 - 旧主节点恢复后，自动配置为新主节点的从节点
- 向重写配置的节点发送
CONFIG REWRITE持久化配置
4. 配置一致性保证
- 配置附带版本号（epoch），采用 last-write-wins 策略传播
- 网络分区时，min-slaves-to-write 可防止数据不一致
- 配置自动持久化到 Sentinel 配置文件，重启安全
五、实战部署
1. 环境规划
| 角色 | 主机 | IP:端口 |
|---|---|---|
| 主节点 | redis-node-01 | 10.0.0.51:6379 |
| 从节点 A | redis-node-01 | 10.0.0.51:6380 |
| 从节点 B | redis-node-01 | 10.0.0.51:6381 |
2. Sentinel 配置与启动
# 创建配置目录
mkdir -p /etc/redis/sentinel-26379 && cd /etc/redis/sentinel-26379
# 编写配置文件
cat > sentinel.conf << 'EOF'
port 26379
dir "/etc/redis/sentinel-26379"
sentinel monitor redis-main 10.0.0.51 6379 1
sentinel down-after-milliseconds redis-main 5000
sentinel failover-timeout redis-main 60000
sentinel parallel-syncs redis-main 1
EOF
# 后台启动
redis-sentinel /etc/redis/sentinel-26379/sentinel.conf &3. 故障切换验证
# 连接主节点并关闭
redis-cli -h 10.0.0.51 -p 6379
> SHUTDOWN
# 观察原从节点 6380 状态
redis-cli -h 10.0.0.51 -p 6380
> INFO replication
# 输出显示 role:master，完成切换
# 重启原主节点 6379，自动变为从节点
redis-server /etc/redis/6379/redis.conf
redis-cli -h 10.0.0.51 -p 6379
> INFO replication
# 输出显示 role:slave，master_host:10.0.0.51:63804. 关键配置参数说明
| 参数 | 说明 |
|---|---|
sentinel monitor <name> <ip> <port> <quorum> | 监控主节点，quorum 为判定客观下线所需 Sentinel 票数 |
sentinel down-after-milliseconds | 主观下线判定时间阈值 |
sentinel failover-timeout | 故障转移超时时间，含重试间隔 |
sentinel parallel-syncs | 同时向新主节点同步的从节点数，避免全量同步冲击 |
六、管理命令
# 连接 Sentinel
redis-cli -p 26379
# 基础检测
> PING
PONG
# 查看监控的主节点
> SENTINEL masters
# 查看指定主节点的从节点
> SENTINEL slaves redis-main
# 获取主节点地址
> SENTINEL get-master-addr-by-name redis-main
# 强制触发故障转移（慎用）
> SENTINEL failover redis-main
# 重置状态
> SENTINEL reset redis-main
