【Redis】Sentinel哨兵

🛡️ 深入理解 Redis Sentinel:高可用架构的守护者

在实际开发中,我们常用 Redis 构建缓存系统或数据中间件。然而,主从复制虽然能实现数据同步,但无法自动故障转移(failover),这就意味着如果主节点宕机,必须手动介入切换,非常影响系统可用性。

为了解决这个问题,Redis 提供了专门的高可用组件 ------ Redis Sentinel(哨兵)

本文将带你系统了解:

  • 为什么需要 Sentinel?
  • Sentinel 的工作机制与核心原理
  • 自动故障转移的流程
  • 如何配置 Sentinel 模式
  • Sentinel 的优缺点与实践建议

☁️ 一、为什么需要 Redis Sentinel?

我们知道,Redis 主从复制模式如下图:

复制代码
       Master
        /   \
     Slave1  Slave2

在主从结构中:

  • 主节点(Master)负责写操作
  • 从节点(Slave)同步数据,负责读操作

但存在一个致命缺陷:

❗ 如果 Master 宕机,整个写服务就会瘫痪!主从无法自行切换主节点,只能人工干预。

因此,我们需要一种机制能够自动识别 Master 的故障,并切换角色 ------ 这就是 Sentinel 的职责


🔧 二、什么是 Redis Sentinel?

Redis Sentinel(哨兵) 是 Redis 官方提供的分布式系统监控与故障转移组件,具备以下核心能力:

  1. 监控(Monitoring):持续监控主从节点是否在线;
  2. 通知(Notification):当某个节点出现问题时,通过 API 通知系统管理员或其他服务;
  3. 自动故障转移(Automatic Failover):当主节点宕机,自动从从节点中选举新的主节点;
  4. 服务发现(Configuration Provider):客户端可以通过 Sentinel 获取当前主节点地址。

⚙️ 三、Sentinel 的核心原理

Sentinel 是一组独立的进程,它们互相通信共同协作完成主节点的监控与切换

Sentinel 监控机制

每个 Sentinel 定期向主从节点发送 PING 命令:

  • 超过 down-after-milliseconds 时间未响应,会被标记为 主观下线(sdown)
  • 多个 Sentinel 一致认为某节点下线,称为 客观下线(odown)

🧱 四、Sentinel 的部署与配置

1️⃣ 启动 Redis 主从节点

bash 复制代码
# 启动主节点
redis-server ./redis.conf

# 启动从节点(配置 replicaof)
redis-server --port 6380
redis-cli -p 6380 replicaof 127.0.0.1 6379

2️⃣ 创建 Sentinel 配置文件(sentinel.conf)

ini 复制代码
port 26379
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 10000
sentinel parallel-syncs mymaster 1

解释:

  • mymaster:主节点名称(自定义)
  • 127.0.0.1 6379:主节点地址
  • 2:quorum,判定客观下线至少需要 2 个哨兵同意
  • down-after-milliseconds:节点无响应时间(ms)
  • failover-timeout:最大故障转移超时时间
  • parallel-syncs:故障转移时同时同步从节点的数量

3️⃣ 启动 Sentinel

bash 复制代码
redis-sentinel ./sentinel.conf

多个 sentinel 节点建议分布式部署(推荐奇数个,如 3 个或 5 个)


🔁 五、故障转移后客户端怎么处理?

故障转移后,客户端需要获取新主节点地址,否则继续访问旧主节点会失败。

✅ 方法一:使用 Sentinel 模式客户端

很多 Redis 客户端支持连接 Sentinel 节点,自动发现新的 Master,例如:

  • Jedis(Java)
  • Lettuce(Spring Data Redis)
  • StackExchange.Redis(.NET)

✅ 方法二:通过 Sentinel 命令查询主节点

bash 复制代码
redis-cli -p 26379
SENTINEL get-master-addr-by-name mymaster

返回新的主节点 IP 和端口,客户端可动态切换连接。


🧠 六、优缺点分析

优点 缺点
自动监控、自动故障转移 配置复杂,依赖哨兵自身稳定性
架构简单,不依赖第三方服务 延迟仍然存在,不能强一致
客户端支持服务发现 无法横向扩展,仍受限单主写

✅ 七、适用场景与实践建议

适用场景:

  • 中小型系统,高可用 Redis 方案
  • 需要主从自动切换,但不需要分片
  • 高性价比替代 Redis Cluster

建议:

  • Sentinel 节点部署在不同主机,避免单点失败;
  • quorum + 哨兵节点数应满足多数派;
  • 搭配 DNS + 代理等方式实现客户端透明切换;
  • 注意客户端的连接模式配置,避免连接旧主节点。

📚 总结

能力 是否支持
主从自动同步 ✅ 主从复制实现
主节点宕机自动转移 ✅ Sentinel 实现
客户端服务发现 ✅ 通过哨兵查询
高可用读写分离 ✅ 从节点读,主节点写
分布式分片 ❌(需 Redis Cluster)

Redis Sentinel 是 Redis 官方推荐的高可用方案之一。对比 Redis Cluster 更加轻量,适合对数据量、分片要求不高但高可用需求强烈的中小型系统。


当然可以,下面是一篇围绕 Redis Sentinel(哨兵)实现原理 的技术博客,重点突出其核心工作机制:定时监控 → 主观下线 → 客观下线 → 领导者选举 → 故障转移,适合用于面试准备、团队分享、CSDN/掘金博客发布。


🛡️ Redis Sentinel 实现原理全解析:监控、判定、选举与故障转移

在 Redis 的高可用架构中,主从复制解决了读写分离和数据冗余问题 ,但却无法完成自动故障转移。这意味着,一旦主节点(Master)宕机,我们需要人工介入,将某个从节点(Slave)提升为主节点。

为了弥补这一缺陷,Redis 提供了一个独立的、强大的高可用组件 ------ Redis Sentinel(哨兵) ,实现主从架构下的 自动监控、故障检测与主从切换

本篇博客将聚焦 Sentinel 的 实现原理,逐步剖析其核心机制:

定时监控 → 主观下线 → 客观下线 → 领导者选举 → 故障转移


☁️ 1. 为什么需要 Sentinel?

主从复制虽好,但当 Master 出现故障:

  • Slave 不会自动"上位"
  • 客户端依然连接旧 Master,访问失败
  • 需要人为手动切换主从、修改配置、通知客户端

🔧 这对系统可用性、容错性要求较高的场景,是不可接受的。

因此,我们需要一个机制来完成这些事情的自动化 ------ Sentinel 哨兵系统应运而生。


⚙️ 2. Sentinel 实现原理总览

下面我们围绕 Sentinel 的核心四步展开详细讲解:

复制代码
Sentinel 原理核心流程:

定时监控
   ↓
主观下线(sdown)
   ↓
客观下线(odown)
   ↓
选举领导者
   ↓
执行故障转移

🔍 3. 定时监控:PING 检测健康状态

每个 Sentinel 节点都会以固定频率(默认 1 秒)向所有监控的 Redis 实例(包括主从和其他 Sentinel)发送 PING 命令。

  • 若某个节点在 down-after-milliseconds 时间内没有回复(默认 5 秒),
  • Sentinel 会将其标记为 主观下线(Subjectively Down, sdown)
ini 复制代码
sentinel down-after-milliseconds mymaster 5000

✅ 这一步是单哨兵的主观判断,并不代表真正的故障。


🚨 4. 主观下线 → 客观下线

如果一个节点被多个 Sentinel 同时标记为 sdown,并且达到配置的投票数量(quorum),则会升级为:

客观下线(Objectively Down, odown)

ini 复制代码
sentinel monitor mymaster 127.0.0.1 6379 2

以上配置中,表示至少两个 Sentinel 一致认为 mymaster 宕机,才认定为 odown

✅ 多哨兵一致达成共识,保证判断的可靠性,防止网络波动带来的误判。


🗳️ 5. 领导者选举(Leader Election)

一旦发生 odown,需要一个 Sentinel 作为Leader(领导者),负责协调主从切换。

采用的是 Redis 自带的Raft 类似的投票机制

  • 所有 Sentinel 参与选举,每个 Sentinel 只能投一票;
  • 第一个获得多数票的 Sentinel 成为 Leader;
  • 其他 Sentinel 退让,监听转移过程。
bash 复制代码
SENTINEL is-master-down-by-addr <ip> <port> <runid> <config-epoch>

该命令是 Sentinel 之间互相交换"票据"的基础。


🔁 6. 故障转移(Failover)

当 Leader Sentinel 被选出后,它开始执行核心任务 ------ 自动故障转移

转移步骤如下:

  1. 从原主节点的从节点列表中挑选一个健康的从节点作为新主节点;
  2. 向选中的从节点发送 SLAVEOF NO ONE 指令,将其提升为主节点
  3. 通知其他从节点:执行 SLAVEOF <new-master-ip> <port>跟随新的主节点
  4. 更新自身和其他 Sentinel 的配置,如 epoch(配置版本号)、角色切换信息等。

🔔 Redis 的从节点可以快速接管主节点工作,且不会丢失大量数据(只会丢失少量未同步的写操作)。


📦 7. 一张图总结 Sentinel 原理

是 是 定时 PING 主节点 是否超时 标记为 sdown 询问其他 Sentinel 超过 quorum? 判定为 odown 发起领导者选举 Leader Sentinel 选出新主节点 下发 SLAVEOF 指令切换主从 更新配置并通知客户端


⚠️ 8. Sentinel 的局限与注意事项

问题 描述 应对方式
网络抖动误判下线 误触发 failover 合理设置 down-after 时间
配置不一致 多个 Sentinel 配置不同步 使用同一个 sentinel.conf 模板启动
客户端未自动切换 老连接依然访问旧主 使用支持 Sentinel 的客户端库
只支持单主架构 无法分片 可考虑 Redis Cluster 替代

✅ 9. 实践建议

  • 部署至少 3 个 Sentinel 实例,确保选举机制有效;
  • 将 Sentinel 与 Redis 节点部署在不同主机或容器中
  • 配置合理的 down-after-millisecondsquorum 值;
  • 使用 Redis 客户端支持 Sentinel 服务发现,如:Lettuce、Jedis、Redisson;
  • 可结合 Nginx、DNS、注册中心等实现透明故障切换

📚 总结

阶段 说明
监控 哨兵定时发送 PING,判断节点存活
主观下线 单个 Sentinel 判断某节点不可用
客观下线 多个 Sentinel 一致判断,形成共识
领导者选举 多个 Sentinel 选出 Leader 协调切换
故障转移 将从节点提升为新主节点,并通知其他节点

Redis Sentinel 是 Redis 高可用方案中的核心技术之一,它通过轻量级的组件设计和自动化的监控机制,让 Redis 从"单点架构"演化为"具备自我修复能力"的健壮系统。


🚦Redis Sentinel 中的主观下线与客观下线机制详解

在 Redis Sentinel 高可用机制中,"主观下线(sdown)"与"客观下线(odown)"是两个非常关键的概念,它们直接决定了 Sentinel 是否会对某个节点执行故障转移操作。

很多初学者容易混淆这两个术语,本文将结合实际机制、源码命令、以及时序过程,为你彻底讲清楚这两者的区别与配合原理


☁️ 什么是 Redis Sentinel?

Redis Sentinel 是 Redis 提供的一种高可用解决方案,具备:

  • 节点健康监控
  • 故障发现与自动转移
  • 客户端服务发现

其中,Sentinel 通过不断的健康检测,发现故障节点并自动完成主从切换。

而主观下线和客观下线就是故障判定的两个阶段。


🔍 1. 主观下线(Subjectively Down)

✅ 定义:

主观下线指的是某个 Sentinel 节点 认为目标 Redis 节点已经不可达,但这种判断是该 Sentinel 自己独立作出的并不代表共识或最终结论

✅ 判定机制:

每个 Sentinel 会:

  • 每隔 1 秒 向所有被监控的 Redis 实例(主节点、从节点、其他 Sentinel)发送一次 PING 命令;
  • 如果某个 Redis 节点在指定时间段(down-after-milliseconds,比如 5 秒)内没有做出有效回复
  • 那么该 Sentinel 会将这个节点标记为 主观下线(sdown)

✅ 示例配置:

ini 复制代码
sentinel down-after-milliseconds mymaster 5000

即:如果主节点在 5 秒内没回应,则该 Sentinel 节点主观判定其"挂了"。

✅ 特点总结:

特性 描述
判定者 单个 Sentinel
时间依据 down-after-milliseconds
目标节点 Master/Slave/Sentinel
是否触发故障转移 ❌ 不会单独触发
是否可被误判 ✅ 可能因为网络抖动误判

🧠 2. 客观下线(Objectively Down)

✅ 定义:

当一个 Redis 主节点 被多个 Sentinel 节点同时标记为主观下线 ,且满足 quorum 票数要求,就会被认为是客观下线(odown),也就是集体判定其"真的挂了"。

✅ 判定机制:

  • 当某个 Sentinel 检测到 Master 节点 sdown 后,会发送:
bash 复制代码
SENTINEL is-master-down-by-addr

向其他 Sentinel 询问是否也判定该主节点 sdown。

  • 如果超过配置的 quorum 个数(如 2 个)也认为 sdown,则标记为 客观下线(odown)
  • 此时,Sentinel 会进入下一阶段:领导者选举和 failover 故障转移

✅ 示例配置:

ini 复制代码
sentinel monitor mymaster 127.0.0.1 6379 2

表示:若至少有 2 个 Sentinel 一致认定主节点不可用,即进入 odown 状态。

✅ 特点总结:

特性 描述
判定者 多个 Sentinel
依据 quorum 投票一致
目标节点 只针对主节点(Master)
是否触发故障转移 ✅ 是故障转移的前提条件
是否可信 ✅ 更可靠(多数派共识)

🖼️ 3. 时序图对比示意

Sentinel1 Sentinel2 Sentinel3 Master Master 宕机 PING PING PING 未响应超时,sdown 未响应超时,sdown is-master-down-by-addr? 是(sdown) is-master-down-by-addr? 是(sdown) quorum 达成 → 标记 odown Sentinel1 Sentinel2 Sentinel3 Master


📌 4. 实际生活中的类比

  • 主观下线就像某个员工说"老王今天好像没来上班"
  • 客观下线是多个员工都说"是的,老王真的请假了",老板才会安排别的人顶替他的工作

✅ 5. 总结对比表

对比项 主观下线(sdown) 客观下线(odown)
判定来源 单个 Sentinel 节点 多个 Sentinel 达成共识
适用对象 所有 Redis 节点 仅主节点
是否可靠 否(可能误判) 是(基于投票)
是否触发故障转移 ❌ 否 ✅ 是
实现命令 自动 ping 判定 is-master-down-by-addr

🎯 总结

Redis Sentinel 的下线机制是其高可用设计的关键之一:

  • 主观下线(sdown)是单哨兵的临时判断
  • 客观下线(odown)是多哨兵一致的最终裁决

只有当达到 客观下线 ,Sentinel 系统才会启动领导者选举和主从切换流程,从而实现 Redis 的自动故障恢复。


相关推荐
全栈凯哥18 分钟前
20.缓存问题与解决方案详解教程
java·spring boot·redis·后端·缓存
Hellyc7 小时前
用户查询优惠券之缓存击穿
java·redis·缓存
鼠鼠我捏,要死了捏9 小时前
缓存穿透与击穿多方案对比与实践指南
redis·缓存·实践指南
天河归来14 小时前
springboot框架redis开启管道批量写入数据
java·spring boot·redis
守城小轩14 小时前
Chromium 136 编译指南 - Android 篇:开发工具安装(三)
android·数据库·redis
Charlie__ZS15 小时前
若依框架去掉Redis
java·redis·mybatis
汤姆大聪明16 小时前
Redis 持久化机制
数据库·redis·缓存
钩子波比16 小时前
🚀 Asynq 学习文档
redis·消息队列·go
也许明天y18 小时前
Spring Cloud Gateway 自定义分布式限流
redis·后端·spring cloud
kk在加油18 小时前
Redis数据安全性分析
数据库·redis·缓存