Redis 的哨兵机制是什么？

Redis 的哨兵机制（Sentinel）主要解决一个问题：Redis 的主节点挂了，怎样自动选出新的主节点，让服务尽快恢复？

一、为什么需要哨兵机制？#

假设你的系统使用 Redis 主从架构：

问题来了：如果 Master 突然宕机了呢？

所以，我们需要 Redis Sentinel（哨兵）。

Redis Sentinel 是 Redis 提供的高可用组件，可以监控 Redis 节点、判断主节点是否故障、自动进行故障转移，并通知客户端新的主节点地址。

它主要有四个功能：

这是面试最重要的部分。

第一步：监控主节点

哨兵定期向 Master 发送 PING 等检测请求，判断它是否正常响应。

第二步：判断主节点是否客观下线

一个哨兵认为主节点不可达，称为主观下线（SDOWN）；多个哨兵通过协商，达到配置的法定数量（quorum）后，可以将其判定为客观下线（ODOWN）。

第三步：选举领导哨兵并执行故障转移

哨兵之间会选出一个领导哨兵，由它挑选合适的从节点，将其提升为新的 Master。

第四步：让其他从节点跟随新主节点

其他从节点改为复制新的 Master，客户端也通过哨兵获取新的主节点地址，恢复正常访问。

你可以把它理解成：发现故障 → 多方确认 → 选举负责人 → 更换主节点 → 通知客户端。

因为哨兵需要相互通信、协商故障状态，并选举领导哨兵。

例如，部署 3 个哨兵：

如果其中一个哨兵宕机，另外两个仍然可以通信、完成协商和选举（具体还要满足相应的 quorum 和选举条件）。

如果只部署一个哨兵，它自己宕机后就没有其他哨兵可以接管判断和故障转移。

注意：3 个哨兵不是绝对要求，但通常会部署奇数个，例如 3 个；quorum 是判断客观下线所需的同意数量，不完全等同于领导哨兵选举所需的多数票。

哨兵能实现高可用，但不代表数据绝对不丢失。

例如，Master 收到了写请求，但数据还没有复制到 Slave，Master 就宕机了。哨兵将某个 Slave 提升为新 Master 后，这部分尚未复制的数据就可能丢失。

另外，哨兵本身不负责数据分片。如果需要将数据分散到多个主节点上，通常要考虑 Redis Cluster 等方案。

Redis 哨兵机制是 Redis 提供的高可用方案，主要用于监控 Redis 节点，并在主节点发生故障时自动进行故障转移。

它主要有四个功能：监控、自动故障转移、通知和配置提供。

当主节点发生故障时，哨兵首先通过主观下线和客观下线机制判断故障，然后选举领导哨兵，由领导哨兵挑选一个合适的从节点，将其提升为新的主节点，其他从节点再跟随新主节点，客户端也可以获取新的主节点地址。

实际部署中通常会配置多个哨兵，避免单个哨兵故障导致无法进行故障转移。

不过，哨兵主要解决的是高可用问题，不能保证数据绝对不丢失，也不负责数据分片。

记忆重点：哨兵 = 监控 + 故障判断 + 自动切主 + 通知客户端。