详解redis(3):哨兵

一、为什么需要 Redis Sentinel?

在主从复制架构下，Redis 仍然存在一个问题：

主节点宕机后，没有自动切换能力

Redis Sentinel 的目标是：

在不引入复杂分片的前提下，为 Redis 提供“自动故障检测 + 自动主从切换 + 服务发现”能力

换句话说：

Sentinel =高可用控制平面
Redis 主从 =数据平面

二、Sentinel 是一个“分布式系统”

为什么 Sentinel 必须是分布式的

如果只有一个 Sentinel：

• Sentinel 自己宕机 → 无法监控

• Sentinel 网络异常 → 误判主节点

所以 Redis 设计为：

多个 Sentinel 进程协同工作

Sentinel本身不能有单点故障

三、Sentinel 的核心职责

监控（Monitoring）

Sentinel 定期向：

主节点

从节点

发送PING

判断：

是否存活

是否可达

是否响应正常

通知（Notification）

当 Sentinel 发现异常时，可以：

记录日志

发送告警（邮件 / webhook / 脚本）

通知运维系统

Sentinel不仅是自动系统，也是监控系统

故障转移管理（Failover）

这是 Sentinel最核心的能力。

当：

主节点不可达

且达到法定数量（Quorum）

Sentinel 会：

确认主节点客观下线

选举一个 Sentinel 作为领导者

从副本中选一个新的主节点

重新配置其他副本

通知客户端新主节点地址

配置管理 / 服务发现

Sentinel 类似于：

Zookeeper

Consul

客户端：

不直接写死 Redis 主节点

启动时向 Sentinel 查询：

“当前主节点是谁？”

当主节点变化：

Sentinel 会告知客户端

客户端重新连接新主

四、故障判定：主观下线 vs 客观下线

主观下线（SDOWN）

单个 Sentinel 判断：

“我联系不上主节点”

可能原因：

网络抖动

Sentinel 自己异常

不立即触发故障转移

客观下线（ODOWN）

多个 Sentinel 达成一致

达到配置的Quorum

例如：

3 个 Sentinel

Quorum = 2

至少 2 个 Sentinel 认为主节点不可用

才会触发故障转移

五、Quorum（法定人数）到底是什么意思

Quorum 的作用是：

防止“误判”和“单点异常”

表格含义解释

含义：

只有多数 Sentinel 同意

才能判定主节点失效

少数派不能发起切换

六、一次完整的 Sentinel 故障转移流程

主节点不可达

多个 SentinelPING失败

达成 Quorum

主节点被标记为ODOWN

Sentinel 领导者选举

Sentinel 之间投票

选出一个Leader Sentinel

选择新的主节点

根据优先级：

在线的副本

复制偏移量最大（数据最新）

延迟低、配置优先级高

提升副本为主

向该副本发送：

SLAVEOF NO ONE

重配置其他副本

让其复制新主节点

通知客户端

Sentinel 更新主节点信息

客户端重新查询并连接新主

七、Sentinel 的局限性和真实风险

网络分区

最危险的问题

场景：

原主节点被网络隔离

Sentinel 多数派在另一侧

选出新主

旧主：

仍然接受写入

结果：

旧主上的写入最终会丢失

Redis 的态度是：

一致性让位于可用性（AP）

写丢失问题（不可避免）

原因：

Redis 复制是异步的

客户端可能仍在向“旧主”写

当客户端发现新主：

旧主写入的这段数据：

无法合并

直接丢弃

Sentinel 与客户端拓扑错位

如果：

Sentinel 认为主节点可达

客户端却连不上

产生“我认为你活着，但你用不了”的问题

八、如何减少数据丢失

强制写入至少一个副本

Redis 提供配置：

min-replicas-to-write 1 min-replicas-max-lag 10

含义：

至少有 1 个副本

延迟不超过 10 秒

否则主节点拒绝写入

用可用性换一致性

启用持久化（RDB + AOF）

防止 Redis 进程级崩溃导致全丢

但：

不能解决脑裂写丢失

客户端正确使用 Sentinel

新连接前：

查询 Sentinel

写失败后：

重新发现主节点

不要缓存主节点地址过久