前言

Sentinel(哨岗、哨兵)是Redis的**高可用性(high availability)解决方案:由一个或多个Sentinel实例(instance)**组成的Sentinel系统 (system)可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器，然后由新的主服务器代替 已下线的主服务器继续处理命令请求。

1. 创建联想主服务器的网络连接

初始化Sentinel的最后一步是创建连向被监视主服务器的网络连接，Sentinel将成为主服务器的客户端，它可以向主服务器发送命令， 并从命令回复中获取相关的信息。

对于每个被Sentinel监视的主服务器来说，Sentinel会创建两个连向 主服务器的异步网络连接:

• 一个是命令连接，这个连接专门用于向主服务器发送命令，并接收命令回复。

• 另一个是订阅连接，这个连接专门用于订阅主服务器的__sentinel__:hello频道。

说白了命令连接就是向服务器发送命令，订阅连接就是接收服务器的频道消息。

为什么有两个连接?
在Redis目前的发布与订阅功能中，被发送的信息都不会保存 在Redis服务器里面，如果在信息发送时，想要接收信息的客户端 不在线或者断线，那么这个客户端就会丢失这条信息。因此，为了 不丢失__sentinel__:hello频道的任何信息，Sentinel必须专门用一个 订阅连接来接收该频道的信息。
另一方面，除了订阅频道之外，Sentinel还必须向主服务器发 送命令，以此来与主服务器进行通信，所以Sentinel还必须向主服 务器创建命令连接。
因为Sentinel需要与多个实例创建多个网络连接，所以Sentinel 使用的是异步连接。

2. 创建连向其他Sentinel的命令连接 （也就是调度中心的高可用）

当Sentinel通过频道信息发现一个新的Sentinel时，它不仅会为新 Sentinel在sentinels字典中创建相应的实例结构，还会创建一个连向新 Sentinel的命令连接，而新Sentinel也同样会创建连向这个Sentinel的命令连接，最终监视同一主服务器的多个Sentinel将形成相互连接的网络: Sentinel A有连向Sentinel B的命令连接，而Sentinel B也有连向Sentinel A 的命令连接。

3.选举领头Sentinel 调度中心高可用

当一个主服务器被判断为客观下线时，监视这个下线主服务器的各个Sentinel会进行协商，选举出一个领头Sentinel， 并由领头Sentinel对下线主服务器执行故障转移操作。

以下是选举的规则：

• 所有在线的Sentinel都有被选为领头Sentinel的资格，换句话说，监视同一个主服务器的多个在线Sentinel中的任意一个都有可能成为领头Sentinel。
• 每次进行领头Sentinel选举之后，不论选率是否成功，所有Sentinel的配置纪元 (configuration epoch）的值都会自增一次。配置纪元实际上就是一个计数器，并没有什么特别的。
• 在一个配置纪元里面，所有Sentinel都有一次将某个Sentinel设置为局部领头Sentinel的机会，并且局部领头一旦设置，在这个配置纪元里面就不能再更改。
• 每个发现主服务器进入客观下线的Sentinel都会要求其他Sentinel将自己设置为局部领头Sentinel。
• 当一个Sentinel（源Sentinel）向另一个Sentinel （目标Sentinel发送SENTINEL is-master-down-by-addr命令，并且命令中的runid参数不是*符号而是源Sentinel的运行ID时，这表示源Sentinel要求目标Sentinel将前者设置为后者的局部领头Sentinel。
• Sentinel设置局部领头Sentinel的规则是先到先得：最先向目标Sentinel发送设置要求的源Sentinel将成为目标Sentinel的局部领头Sentinel，而之后接收到的所有设置要求都会被目标Sentinel拒绝。
• 目标Sentinel在接收到SENTINEI is-master-down-by-addr命令之后，将向源Sentinel返回一条命令回复，回复中的leader_runid参数和leader_epoch参数分别记录了目标Sentinel的局部领头Sentinel的运行ID和配罝纪元。
• 源Sentinel在接收到目标Sentinel返回的命令回复之后，会检查回复中leader_epoch参数的值和自己的配置纪元是否相同，如果相同的话那么源Sentinel继续取出回复中的leader_runid参数，如果leader_runid参数的值和源Sentinel的运行ID一致，那么表示目标Sentinel将源Sentinel设置成了局部领头 Sentinel。
• 如果有某个Sentinel被半数以上的Sentinel设置成了局部领头Sentinel，那么这个Sentinel成为领头Sentinel。举个例子，在一个由10个Sentinel组成的Sentinel系统里面，只要有大于等于10/2+1=6个Sentinel将某个Sentinel设置为局部领头Sentinel，那么被设置的那个Sentinel就会成为领头Sentinel。
• 因为领头Sentinel的产生需要半数以 上Sentinel的支持，并且每个Sentinel在每个配置纪元里面只能设置一次局部领头Sentinel， 所以在个配置纪元里面，只会出现一个领头Sentinel。
• 如果在给定时限内，没有一个Sentinel被选举为领头Sentinel，那么各个Sentinel将在一段时间之后再次进行选举，直到选出领头Sentinel为止。

流程有点长，希望大家能够仔细看完。

4.故障转移 选出新的主服务器 redis服务器高可用

在选举产生出领头Sentinel之后，领头Sentinel将对已下线的主服务器执行故障转移操作，该操作包含以下三个步骤:

1）在已下线主服务器属下的所有从服务器里面，挑选出一个从服务器，并将其转换为主服务器。

2）让已下线主服务器属下的所有从服务器改为复制新的主服务器。

3）将已下线主服务器设置为新的主服务器的从服务器，当这个旧的主服务器重新上线时，它就会成为新的主服务器的从服务器。

如何挑选新的主服务器？

领头Sentinel会将己下线主服务器的所有从服务器保存到一个列表里面，然后按照以下规则，一项一项地对列表进行过滤：
1）删除列表中所有处于下线或者断线状态的从服务器，这可以保证列表中剩余的从服务器都是正常在线的。

2）删除列表中所有最近五秒内没有回复过领头 Sentinel的INFO命令的从服务器，这可以保证列表中剩余的从服务器都是最近成功进行过通信的。

3）删除所有与己下线主服务器连接断开超过down-after-milliseconds10毫秒的从服务器：down-after-milliseconds选项指定了判断主服务器下线所需的时间，而刚除断开时长超过down-after-
milliseconds10毫秒的从服务器，则可以保证列表中剩余的从服务器都没有过早地与主服务器断开连接，换句话说，列表中剩氽的从服务器保存的数据都是比较新的。

之后，领头Sentinel将根据从服务器的优先级，对列表中剩余氽的从服务器进行排序，并选出其中优先级最高的从服务器。

如果有多个具有相同最高优先级的从服务器，那么领头Sentinel将按照从服务器的复制偏移量，对具有相同最高优先级的所有从服务器进行排序，并选出其中偏移量最大的从服务器（复制偏移量最大的从服务器就是保存着最新数据的从服务器）。

最后，如果有多个优先级最高、复制偏移量最大的从服务器，那么领头Sentinel将按照运行ID对这些从服务器进行排序，并选出其中运行ID最小的从服务器。

总结

redis的Sentinel模式既实现了协调者的高可用，也实现了redis服务的高可用。使用的一致性算法和Raft差不多。