Redis 哨兵机制

为什么要有哨兵（sentinel）机制

在 Redis 主从架构中，当主服务器宕机，需要手动将从服务器切换为主服务器，这需要人工干预，不仅费时费力而且还会造成一段时间内服务不可用。

哨兵机制就是为了解决主从复制的缺点，以实现自动故障转移

什么是哨兵机制

Redis 的哨兵（Sentinel）系统（由一个或多个 Sentinel 实例组成）用于管理多个 Redis 主服务器（Master），以及这些主服务器属下的所有从服务器（Slave），并在被监控的主服务器进入下线状态时，自动将下线主服务器（Master）属下的某个从服务器（Slave）升级为新的主服务器（Master），然后由新的主服务器代替已下线的主服务器（Master）继续处理 Redis 客户端发送的命令请求。

该系统执行以下三个任务：

监控（Monitoring）

哨兵（sentinel）会不断地检查你的 Master 和 Slave 是否正常运行。
提醒（Notification）

当被监控地某个 Redis 出现问题时，哨兵可以通过 API 向管理员或者其他应用程序发送通知。
自动故障转移（Automatic failover）

当一个 Master 不能正常工作时，哨兵会开始一次自动故障转移操作，它会将失效 Master 的其中一个 Slave 升级为新的 Master，并且让失效的 Master 的其他 slave 改为复制新的 Master；当客户端试图链接失效地 Master 时，集群也会向客户端返回新的 Master 地址，使得集群可以使用新的 Master 代替失效地 Master。

哨兵机制的高可用（HA）

原理：哨兵系统监控到有 Redis 主服务器（Master）出现故障时，将从哨兵系统中选举一个哨兵（sentinel）作为领导者，由它负责完成故障转移，从而实现高可用性。

哨兵的实时监控任务

任务1：每个哨兵节点每10 秒会向主节点和从节点发送 info 命令获取最新地拓扑结构图，哨兵配置时只需要配置对主节点地监控即可，通过向主节点发送 info，获取从节点的信息，并当有新的从节点加入时可以马上感知到。

任务2：每个哨兵节点每隔 2 秒会向 Redis 数据节点的指定频道上发送该哨兵节点对于主节点地判断以及当前哨兵节点的信息，同时每个哨兵节点也会订阅该频道，来了解其他哨兵节点的信息及对主节点的判断，其实就是通过发布/订阅来完成的

任务3：每隔 1 秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次ping命令做一次心跳检测，这个也是哨兵判断节点是否正常的重要依据。

主观下线：根据定时任务 3 对没有有效回复的节点做主观下线处理。
客观下线：当主观下线的节点是主节点时，此时该哨兵 3 节点会寻求其他哨兵节点对主服务器（Master）的判断，当同意该主服务器（Master）下线的数量达到配置指定的数量时，此时哨兵节点则认为该主服务器确实有问题，则将主服务器标注为进入客观下线状态。

领导者哨兵（Sentinel）选举机制

当一个主服务器（Master）进入客观下线状态时，哨兵系统会进行协商，选举出一个哨兵领导者，而领导者哨兵的选举规则如下：

每个在线的哨兵节点都可以成为领导者，当有哨兵确认（比如哨兵3）主服务器（Master）客观下线时，会向其他哨兵发送投票请求，要求将自己设置为领导者哨兵；
其他哨兵收到投票请求后，遵循先到先得：即最先收到的请求会投票同意，接着收到的请求都将投票拒绝
如果哨兵3发现自己在选举的票数达到半数以上，则选举胜出，将会成为领导者，否则继续选举

故障转移流程

选举出领导者哨兵之后，接着就由它完成对下线主服务器执行故障转移操作，如下：

故障转移流程

将从服务器 slave-1 升级为主服务器（Master）
将从服务器 slave-2 指向新的服务器（Master）
通知 Redis 客户端主服务器（Master）已经更换
将故障恢复的原主服务器（Master）变成从服务器（Slave）

选择从服务器升级为主服务的规则

过滤掉所有不健康的（下线或者短线），没有回复哨兵 ping 响应的从服务器
选择 slave-priority 从服务器优先级最高的
优先级相同则选择复制偏移量最大的从服务器（也就是复制数据最完整）
偏移量相同则按照运行从服务器 ID 进行排序，选出其中运行 ID 最小的从服务器

总结

redis 哨兵的作用

监控主服务器（Master）和从服务器（Slave）是否正常运行
一旦主服务器（Master）出现故障时，选举一个领导者哨兵，让它将从服务器（Slave）转换为主服务器（Master），实现故障转移

Redis

Redis 哨兵机制