适用版本：Redis 7.2.x
学完 Redis 主从复制后，很多人都会自然想到一个问题：
如果主库挂了，谁来把从库切成新的主库？
如果答案是“靠人工登录机器改配置”，那这种高可用只能算半自动，面对线上故障时往往来不及。Redis Sentinel（哨兵）就是为了解决这个问题出现的。
Sentinel 本身不存储业务数据，它更像一组长期运行的“监控 + 协调 + 故障切换”进程，负责盯住 Redis 主从节点的健康状态，并在主库故障时自动选举新主、通知客户端完成切换。
这篇文章会从 Sentinel 要解决的问题开始，讲清楚它的职责、判定机制、故障转移流程、配置示例以及常见问题。理解 Sentinel 之后，你就能真正看懂 Redis 单主高可用的实现方式。
一、为什么有了主从复制还不够
主从复制已经能把数据同步到多个副本，但它并不会自动完成“主库故障接管”。
假设架构如下：
+----------------+
| Client |
+--------+-------+
|
v
+-------------+
| Master 主库 |
+------+------+
|
复制流 |
+-----------+-----------+
| |
v v
+-----------+ +-----------+
| Replica A | | Replica B |
+-----------+ +-----------+
这时如果主库宕机，会出现几个现实问题：
- 哪个从库该升为新主？
- 谁来判断主库是真的挂了，不是网络一时抖动？
- 切换后其他从库如何重新挂到新主上？
- 客户端怎么知道新的主库地址？
主从复制只解决“数据副本同步”，而 Sentinel 解决的是“自动发现故障并自动切换”。
二、Sentinel 的核心职责
Sentinel 的职责可以概括成三件事。
1. 监控（Monitoring）
Sentinel 会持续检查：
- 主库是否在线；
- 从库是否在线；
- 其他 Sentinel 是否在线。
2. 通知（Notification）
当实例状态发生变化，比如主库下线、故障转移完成，Sentinel 可以通过发布事件、日志、客户端发现接口等方式把变化暴露出去。
3. 自动故障转移（Automatic Failover）
当主库被判定故障后，Sentinel 会：
- 在从库中选出新的主库；
- 让其他从库改为复制新主；
- 对外宣布新的主节点信息；
- 等原主恢复后，再把它作为从库挂回新主。
所以 Sentinel 更准确的理解是：
它不是数据节点，而是 Redis 主从架构的“高可用控制平面”。
三、Sentinel 的部署图景
典型的 Sentinel 架构如下：
+----------------------+
| Client |
| 通过 Sentinel 找主库 |
+----------+-----------+
|
+--------------------+--------------------+
| | |
v v v
+-------------+ +-------------+ +-------------+
| Sentinel-1 | | Sentinel-2 | | Sentinel-3 |
+------+------+ +------+------+ +------+------+
| | |
+--------------------+--------------------+
|
v
+--------------+
| Master 主库 |
+------+-------+
|
+----------+-----------+
| |
v v
+-----------+ +-----------+
| Replica A | | Replica B |
+-----------+ +-----------+
这里有两个关键点：
1. Sentinel 通常至少部署 3 个
原因不是为了“看起来更高可用”，而是因为 Sentinel 自己也需要多数派来做判断和选举。
2. Sentinel 与 Redis 数据节点是两个角色
- Redis 主从节点负责存数据、处理请求；
- Sentinel 负责判断状态和执行切换。
不要把两者混成一个概念。
四、Sentinel 如何监控 Redis 实例
Sentinel 会周期性向 Redis 节点和其他 Sentinel 发送命令，比如：
PINGINFOPUBLISHSENTINEL is-master-down-by-addr
通过这些信息，它可以知道：
- 当前主库是否能响应；
- 主从拓扑有没有变化；
- 某个从库复制延迟是否过大；
- 当前是否有足够 Sentinel 一起确认主库故障。
1. 主观下线（SDOWN）
如果某个 Sentinel 在设定时间内一直无法从主库拿到有效响应，它会先认为：
这个主库在“我看来”已经下线了。
这叫 主观下线，通常记作 SDOWN。
2. 客观下线（ODOWN）
但 Sentinel 不会因为“我一个人觉得它挂了”就直接切换。它还会去问其他 Sentinel：
- 你们也觉得主库挂了吗？
如果达到配置中的法定票数（quorum），才会把主库认定为 客观下线，即 ODOWN。
这个机制非常关键，因为它避免了单点误判。
五、为什么 Sentinel 要区分主观下线和客观下线
这是 Sentinel 设计里非常经典的一点。
1. 只靠单个 Sentinel 判断，误判风险很大
例如：
- 某个 Sentinel 自己网络抖了；
- 它到主库的链路暂时异常；
- 主库短暂卡顿但很快恢复。
如果单个 Sentinel 就能触发切换，那故障转移会非常混乱。
2. 多数派机制可以降低误切换
只有当多个 Sentinel 都认为主库不可达，才认为这更像真实故障而不是局部网络问题。
3. 这也是为什么 Sentinel 不能只部署 1 个
单个 Sentinel 不具备“交叉确认”的能力。一旦它误判，就可能做出错误切换。
所以生产中常见建议是：
- 至少 3 个 Sentinel；
- 尽量分布在不同机器或不同可用区；
- 避免 Sentinel 和主库完全同故障域。
六、Sentinel 是如何完成故障转移的
当主库被判定为 ODOWN 后，Sentinel 并不是所有节点一起抢着操作，而是会先在 Sentinel 之间选出一个领导者 Sentinel 来负责本次故障转移。
1. 选领导者 Sentinel
多个 Sentinel 会基于纪元和投票机制选出一个 leader，用于组织这轮 failover。
2. 从可用副本中挑选新主
领导者 Sentinel 会在从库里选一个最适合提升为主库的节点。选择时通常会综合考虑：
- 是否在线；
- 与旧主的复制偏移量谁更新；
replica-priority优先级；- 网络连通性；
- 断线时长。
3. 向被选中的从库发送提升命令
被选中的从库会执行：
REPLICAOF NO ONE
这样它就不再跟随旧主，而是成为新的主库。
4. 让其他从库改为复制新主
其他副本随后会被重新指向新主。
5. 对外发布新的主库信息
客户端或中间件通过 Sentinel 查询主库地址时，就会得到新的结果。
6. 原主恢复后重新加入
如果旧主恢复，它通常不会继续当主，而是会被重配置为新主的从库。
七、从库选主时，Sentinel 大致看什么
这是很多面试和线上排查中常被问到的问题。
1. 优先看复制数据更新程度
如果一个副本明显比其他副本更新，通常更适合提升为新主。因为这样能尽量减少故障切换时的数据丢失。
2. 参考 replica-priority
可以在 Redis 配置中设置：
replica-priority 100
数值越小，优先级越高；如果设置成 0，表示该副本永远不参与被选为主库。
这对于某些只想保留为只读备份、硬件规格较差、跨地域延迟较大的从库很有用。
3. 过滤明显异常的副本
比如：
- 长时间断线；
- 与主库复制落后很多；
- 当前状态不稳定；
- 与 Sentinel 通信异常。
所以新主的选举并不是随机抽一个从库，而是带有明确偏好的“择优提升”。
八、Sentinel 配置示例
下面是一份常见的 Sentinel 配置片段：
port 26379
bind 0.0.0.0
protected-mode no
sentinel monitor mymaster 192.168.10.10 6379 2
sentinel auth-user mymaster default
sentinel auth-pass mymaster your_master_password
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
下面逐项理解。
1. sentinel monitor
sentinel monitor mymaster 192.168.10.10 6379 2
含义是：
- 监控的主库名字叫
mymaster； - 主库地址是
192.168.10.10:6379； 2表示至少需要 2 个 Sentinel 认同主库下线，才能形成客观下线判断。
2. sentinel down-after-milliseconds
sentinel down-after-milliseconds mymaster 5000
表示如果 5000 毫秒内主库持续不可达，则该 Sentinel 会把它判为主观下线。
这个值太小容易误判，太大又会拉长故障发现时间。
3. sentinel failover-timeout
sentinel failover-timeout mymaster 60000
控制故障转移相关超时窗口，影响失败重试、切换节奏等行为。
4. sentinel parallel-syncs
sentinel parallel-syncs mymaster 1
表示在新主产生后，同时允许多少个从库并行去同步新主。
如果这个值太大，切换后可能短时间内给新主造成很大复制压力；太小则整体收敛会更慢。
九、Sentinel 模式下客户端怎么找主库
Sentinel 模式下，客户端一般不直接把主库地址写死，而是通过 Sentinel 查询当前主节点。
常见命令如下：
127.0.0.1:26379> SENTINEL get-master-addr-by-name mymaster
1) "192.168.10.10"
2) "6379"
还可以查看监控信息：
127.0.0.1:26379> SENTINEL masters
127.0.0.1:26379> SENTINEL replicas mymaster
127.0.0.1:26379> SENTINEL sentinels mymaster
这几个命令分别用于：
- 查看所有主库监控项；
- 查看某个主库下的副本列表；
- 查看同样在监控该主库的其他 Sentinel。
一个实践上的重点
客户端应尽量使用支持 Sentinel 的 Redis SDK，而不是手工把主库地址写死。否则主从切换后，业务仍然会继续连旧主，导致故障恢复效果大打折扣。
十、一个最小 Sentinel 实验图景
可以搭建如下实验环境：
- 主库：
6379 - 从库 A：
6380 - 从库 B：
6381 - Sentinel：
26379、26380、26381
1. 主从先建立复制关系
从库配置：
replicaof 127.0.0.1 6379
2. 三个 Sentinel 都监控同一主库
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 5000
3. 人工关闭主库
例如停掉 6379 实例。
4. 观察 Sentinel 日志与主从变化
你通常会看到：
- 先出现
+sdown； - 然后达到票数出现
+odown； - 某个 Sentinel 成为 leader；
- 某个从库被提升为新主；
- 另一个从库改为复制新主。
这套实验很适合帮助你把“主观下线、客观下线、故障转移、重新挂载”这些概念真正串起来。
十一、Sentinel 机制的优点与边界
1. 优点
- 适合单主多副本的高可用架构；
- 自动发现主故障并切换；
- 部署相对简单；
- 对业务接入门槛不高。
2. 边界
Sentinel 也不是万能的，它有明显适用边界：
- 只解决单主架构的高可用；
- 不解决横向分片容量问题；
- 复制仍然是异步的，切换时仍可能丢失最近少量数据；
- 客户端必须正确支持主库地址更新；
- Sentinel 自己也需要合理部署，否则容易误判或失去多数派。
所以如果业务已经发展到单机容量不足、需要多主分片，一般要考虑 Redis Cluster，而不是继续只靠 Sentinel。
十二、常见问题
1. 为什么 Sentinel 一般至少要部署 3 个？
因为 Sentinel 自身需要多数派机制来避免误判和完成选举。1 个不可靠，2 个又无法很好处理“1 个挂了之后谁算多数”的问题，3 个是更常见的最小生产组合。
2. quorum 是不是越小越好？
不是。
- 太小：容易误判主库下线；
- 太大：真实故障时又可能迟迟达不到票数。
需要结合 Sentinel 数量、网络稳定性和故障域来设置。
3. Sentinel 切换后为什么业务还连着旧主？
常见原因有：
- 客户端没有使用 Sentinel 感知能力；
- 连接池没有及时刷新；
- 中间层缓存了旧地址；
- 业务用了硬编码地址。
这类问题在线上非常常见，所以“客户端是否真正支持自动切主”必须提前验证。
4. Sentinel 会不会导致数据零丢失？
不会。
因为 Redis 主从复制默认仍是异步的。主库宕机前最后一小段尚未复制到从库的数据，仍然可能丢失。
5. 某个从库为什么一直不被选成新主？
重点看：
replica-priority是否为0；- 它的复制进度是否落后；
- 它是否经常断线；
- 它与 Sentinel 的连通性是否稳定。
6. down-after-milliseconds 应该怎么设？
没有固定万能值。常见思路是：
- 太短容易误判；
- 太长会导致切换慢；
- 需要结合网络质量、主机稳定性和业务容忍时间反复演练。
十三、实践建议
1. Sentinel 至少三节点，且分散部署
尽量不要把所有 Sentinel 都放在同一台机器、同一机架、同一可用区，否则它们可能一起故障或一起误判。
2. 不要忽略客户端切主能力验证
很多团队 Sentinel 本身配得没问题，真正出故障时却发现业务侧没有自动刷新主库地址。这个问题比 Sentinel 配置错误更常见。
3. 关注复制延迟与副本质量
Sentinel 能切换成功，不代表切换后数据一定最完整。副本平时复制越稳定，故障转移时损失越小。
4. 对关键参数做压测和演练
至少要演练：
- 主库进程退出；
- 主机断网；
- Sentinel 少数节点失联；
- 从库复制延迟变大；
- 切换后客户端重连。
5. 认清 Sentinel 和 Cluster 的适用场景
如果你要的是：
- 单主高可用；
- 容量还没有大到必须分片；
- 业务更想保持简单接入；
那么 Sentinel 很合适。
如果你要的是：
- 多主分片；
- 水平扩容；
- 大规模数据分布；
那就要考虑 Redis Cluster。
十四、小结
Redis Sentinel 机制的核心逻辑可以概括为：
- 持续监控 Redis 主从节点状态；
- 先由单个 Sentinel 判定主观下线，再由多个 Sentinel 形成客观下线；
- 选出一个领导者 Sentinel 来组织故障转移；
- 从多个副本中挑选更合适的节点提升为新主；
- 让其他从库重新挂到新主上，并对外暴露新的主节点信息。
如果你把 Sentinel 理解为“Redis 的自动故障转移协调器”，就已经抓住了它最本质的定位。它不是分片方案，但它让单主架构从“能复制”走向了“能自动恢复”。
接下来如果继续学习 Redis Cluster，你会发现：Sentinel 关注的是单主高可用，而 Cluster 关注的是分片 + 高可用，两者解决的问题层级并不一样。
📝 版权声明：本文为原创技术博客，转载请注明出处。
如文章中存在错误或不准确之处，欢迎在评论区指正，感谢您的阅读与支持！