哨兵模式sentinel深入分析

哨兵sentinel是一种特殊的模式，首先它是一个单独的进程，通过发送命令的方式从Redis服务器中获取Redis多个实例的状态，从而监控服务器是否正常运行。

1. 启动和初始化sentinel

使用命令redis-sentinel  /yourpath/sentinel.conf 

或者 redis-server /yourpath/sentinel.conf

启动时，它需要执行以下几个步骤

•  初始化服务器
• 将普通redis代码替换为sentinel代码
• 初始化sentinel状态
• 根据给定的配置文件，来初始化sentinel的监视器主服务列表
• 创建连向主服务器的连接

创建与主服务器网络连接是，sentinel会创建两个连向主服务器的异步网络连接

1. 一个是命令连接，这个专门用来向主服务器发送命令，并接受命令回复
2. 另一个是订阅连接，这个订阅专门用于订阅主服务器的_sentinel_:hello频道

为什么要有两个连接？

redis的发布订阅功能中，发布的信息不会保存在redis服务器中，如果信息发送时，想要接收的客户端不在线或者短线，那么这个客户端就会丢失这条消息，为保证消息不丢失，sentinel必须使用一个订阅连接来接收该频道的消息

除此之外，sentinel还必须向主服务器发送命令，以此来实现通信，所以sentinel必须与主服务器创建连接

Sentinel默认会以10s一次的频率向主服务器发送INFO命令，通过主服务器返回的信息来获取主服务器本身的信息（包括run_id域记录的服务器运行ID）和主服务器下的所有从服务器信息（一个由salve字符开头的行记录）

当Sentinel发现主服务器下出现新的从服务器后，Sentinel除了会为这个从服务器创建实例结构外，还会创建连接到从服务器的命令连接和订阅连接，默认10s一次发送INFO命令，并获得命令回复。（注意INFO命令不是探活命令）

 

向主服务器和从服务器发送信息

，默认情况下，Sentinel以每2s 一次的频率，通过命令连接向所有被监视的主服务器和从服务器发送一定格式的命令，通过接收来自主服务器和从服务器的频道信息，来更新自身的Sentinels字典

创建连向其他Sentinel的命令连接

对于监视同一个服务器的多个Sentinel来说，一个Sentinel发送的信息会被其他Sentinel接收到，这些信息用于更新其他Sentinel对于发送信息Sentinel的认知，也会用于其他Sentinel对服务器的认知。当Sentinel通过频道信息发现一个新的Sentinel时，不仅会为它在Sentinels字典中创建一个实例，还会创建连向新Sentinel 的连接，而新的Sentinel也会创建连向这个Sentinel 的连接。这样监视同一服务器的sentinel将会形成一个相互连接的网络。

检测主观下线

默认情况下，Sentinel会以每秒一次的频率向所以与他建立命令连接的实例（包括主，从服务器和其他Sentinel）发送PING命令，并通过实例PING回复来判断实例是否在线。Sentinel的配置文件中指定了判断实例主观下线所需要的时间长度，如果在down-after-milliseconds毫秒内，连续向Sentinel返回无效，则在flags属性中打开SRI_S_DOWN标识，用来表示实例已经进入主观下线状态。

检测客观下线

 由于每个Sentinel 的down-after-milliseconds 可能不一致，这就会导致SentinelA认为主服务器主观下线了，但是SentinelB由于设置的参数down-after-milliseconds 比较大，SentinelB认为主服务器没下线，那这样是不是就又问题了呢？（哈哈，先自己想想）

当SentinelA检测主服务器主观下线后，为了确认这个服务器是不是真的下线了，它会向同样监视这个服务器的其他Sentinel进行询问，看看他们是否认为该服务器也已经进入下线状态，当Sentinel从其他Sentinel中获取到足够数量的已下线判断后，Sentinel将从服务器判定客观下线，并对主服务器进行故障转移。（足够数量的已下线是多少呢，是不是也有参数配置？）

当认为主服务器进入下线状态的Sentinrl数量，大于Sentinel配置中的quorum数量时，那么该Sentinel会认为主服务器进入客观下线状态（每个Sentinel判断客观下线的条件可能不同）

选举领头Sentinel

当有一个Sentinel判断主服务器为客观下线后，监视这个下线主服务器的Sentinel会协商选举出一个领头Sentinel。规则如下：

• 所有Sentinel都有可能被选举为领头Sentinel
• 每次进行领头Sentinel选举后，不管是否选举成功，所有Sentinel的配置纪元（前面提到的Sentinel字典中）都会自增一次。
• 在一个配置纪元里，所有Sentinel都有一次选举的机会，一旦选了，在这个配置纪元里面就无法修改
• 每个发现主服务器进入客观下线的Sentinel都会要求其他Sentinel将自己设置为局部领头Sentinel（发送命令）
• Sentinel不能将自己设置为领头Sentinel（通过命令中的run_id判断是否是自己）
• Sentinel设置局部头领的规则是先到先得，先到的会被设置为局部头领，后到的会被拒绝
• 如果某个Sentinel被半数以上的Sentinel设置为局部领头Sentinel，那么这个Sentinel就会成为Sentinel
• 如果在给定时间内，没有一个Sentinel被选举为领头Sentinel，那么各个Sentinel将会在一段时间后重新开始一次选举，直到选出为止

选出的领头Sentinel开始执行故障转移，该操作分为三个步骤

1. 在已下线的主服务器的从服务器中选中一个从服务器，并将其转换为主服务器
2. 让已下线的主服务器属下的从服务器改为复制新的主服务器
3. 如果已下线的主服务器回复了的话，让其作为新的主服务器的从服务器

从服务器选主规则

领头Sentinel会将已下线的主服务器属下的从服务器保存到一个列表

• 删除列表中处于下线状态或者短线的服务器
• 删除列表中最近5s没有回复领头Sentinel的INFO命令的从服务器
• 删除与已下线主服务器连接断开超过down-after-milliseconds* 10 毫秒的服务器

之后领头Sentinel会对剩下的服务器进行排序，并选出优先级最高的从服务器。如果两个服务器优先级一致，那么回去查看从服务器中数据的偏移量，偏移量大的说明数据最新，并选出偏移量大的服务器。

领头Sentinel 向选中的服务器发送SLAVEOF no one命令之后，会以每秒一次的频率向选中的服务器发送INFO命令，并观察命令回复中的角色信息，当被升级的服务器的role从slave变为master后，领头Sentinel就知道被选中的从服务器升级为主服务器了。

 

各个从服务器开始改为从新的主服务器上复制消息（通过领头Sentinel向原来的从服务器发送SLAVEOF命令实现）

如果旧的主服务器活了过来，那么领头Sentinel也会发送SLAVEOF命令，让其成为新的主服务的一个从服务器。

 

Sentinel选举领头是通过Raft算法来实现的（感兴趣的可以自己去看看）

觉得还行就点个赞呗，哈哈！