概述

为了解决主从模式不能 failover 的缺点，Redis 提出了 sentinel 哨兵模式。

哨兵是一个运行在特殊模式下的 Redis 进程，其和主从库实例同时运行，主要负责 监控、选主、通知 三个任务。

监控任务实现

1. 哨兵会使用 PING 命令监控实例的网络连接状态。如果发现 PING 命令的响应超时了(超过 down-after-milliseconds 参数)，那么，哨兵就会先把相应节点标记为「主观下线」。
2. 如果检测的是从库，就直接下掉。
3. 如果检测的是主库，哨兵会给其他哨兵实例发送 is-master-down-by-addr 命令。其他实例会根据自己和主库的连接情况，决定是否投出赞成票。 → 防止误判频繁主从切换产生不必要的开销。
4. 当一个哨兵获得了仲裁所需的赞成票数（配置文件中的quorum配置项设定）后，就可以标记主库为「客观下线」。
5. 选举出一个哨兵作为 Leader 来执行主从切换(两个哨兵在不同的时间点标记同一个主库为客观下线，都执行主从切换，集群直接乱套了)，选举逻辑很简单，标记客观下线的节点发起Leader选举，自己给自己投一票，每个哨兵只能投一票，按照先到先得的原则进行投票(A和B都请求C给他票，A先来了，A票数+1)。成为 Leader 要满足：拿到半数以上的赞成票、拿到的票数 ≥ 哨兵配置文件中的quorum值两个条件。
6. 由选举出的 Leader 哨兵来执行选主任务。
7. 如果选主失败，哨兵集群会等待一段时间(哨兵 failover 超时时间的 2 倍)，再重新选举。 → 为了保证选举成功，通常会配置奇数个(3个)哨兵实例。

选主任务实现

1. 根据从库的在线状态(没下线就行)以及从库与主库的网络连接健康程度(要小于down-after-milliseconds(主从库断连的最大超时时间) * 10)，把不符合条件的从库筛掉。
2. 按照三个打分逻辑，逐级给剩下的从库打分，如果在某一级存在唯一得分最高的从库，就将其选为新主库，分别是：
   1. 从库优先级，通过 slave-priority 参数配置 → 比如可以给内存大的设置为高优先级
   2. 从库复制进度，和旧主库同步程度最接近的从库得分高 → 由主从复制过程中 repl_backlog_buffer (忘了就看看主从复制原理==)里的 slave_repl_offset 和 master_repl_offset 的距离决定。 → 在哨兵选主源码中是直接比较从库的slave_repl_offset 来选择和主库最接近的从库。
   3. 从库ID号，每个实例都有的那个id，从小到大选。
3. Leader 哨兵执行主从切换，给其他从库和客户端通知新主库的信息。

通知任务实现

在配置哨兵的信息时，我们只设置了主库的 IP 和端口(命令: sentinel monitor )，并没有配置和其他哨兵以及从库的连接信息，但是最终他们之间还是可以正常通信的，实现这个机制的核心就是 Redis 的 pub/sub 机制。

1. 哨兵在主库的 sentinel:hello 频道上发布自己的连接信息(ip、port)，并订阅其他哨兵发布的连接信息。→ 为了区分不同应用的消息，Redis会以频道的形式，对消息进行分类管理，只有消息类别相同，消息才属于同一个频道，只有订阅了同一个频道的应用，才能通过发布的消息进行信息交换。
2. 哨兵向主库发送 INFO 命令以获取从库列表，并根据其中的连接信息和每个从库建立连接并监控。

sentinel哨兵模式优缺点

优点：实现了主从自动切换，进一步提升可用性。

缺点：

1. 每个节点存储了同样的数据，过多的从节点造成内存浪费。
2. 在线扩容困难。如果写请求太多，从节点数量多了后，主节点同步数据的压力就会非常大→比较适合读多写少的业务场景，比如秒杀缓存活动信息。

参考：蒋德钧老师《Redis核心技术与实战》极客时间专栏，强烈推荐！