Sentinel（哨兵）是Redis高可用的解决方案之一，由一个或者多个Sentinel实例组成的系统可以监视任意个主服务器及从服务器组成的集群，当某个主服务器不在线时，Sentinel会主动将下线的主服务器下的从服务器升级为主服务器继续提供服务。

Sentinel模式架构

Sentinel常见的架构如下：

• Sentinel集群与Redis主从集群通过ping-pong心跳进行验活。
• 当检测到Master失效后，Sentinel会将失活的Master对应的Slave升级为Master，并更新Proxy的路由表。
• Sentinel本身也是一个集群，集群内的所有实例之间相互会有心跳，保证Sentinel集群自身的可靠性。

Sentinel实现原理

Sentinel启动流程如下：

1. 初始化服务器。
2. 将普通Redis服务器的代码替换为Sentinel专用代码。
3. 初始化Sentinel状态。
4. 跟进配置文件sentinel.conf初始化Sentinel的监视主服务器列表。
5. 创建连向主服务器的网络连接。

Sentinel初始化

Sentinel初始化服务器

Sentinel本质上只是一个运行在特殊模式下的Redis服务器，因此启动Sentinel也就是初始化一个普通的Redis服务器，但是启动的模式与普通服务器不一致：

• redisServer中的commands在Sentinel模式下会被替换为sentinelcmds。
• Sentinel模式启动阶段不会载入RDB文件或者AOF文件初始化数据库。

初始化Sentinel状态

Sentinel启动时根据配置文件初始化masters节点的配置，具体结构如下：

与主服务器建立连接

Sentinel向主服务器建立连接，Sentinel作为服务器的客户端，可以向主服务器发送命令，从恢复中获取主服务相关信息。Sentinel会与主服务器建立两个连接：

• 命令连接：专门用于向主服务发送命令，并接受命令回复。
• 订阅连接：专门用于订阅主服务器的__sentinel__:hello频道。

Sentinel与主/从服务器通信

Sentinel默认会以没10s一次的频率通过命令连接向主服务器发送INFO命令，通过这个命令的响应，Sentinel可以用获取到主服务的信息以及其对应的从服务器信息，然后将这些信息更新到对应的masters->sentinelRedisInstance#slaves结构中。

通过主服务获取到从服务器信息后，Sentinel也会和从服务器默认没10s通信一次，也是通过INFO命令获取从服务器信息，然后将回复数据更新到对应的从服务器结构中。

Sentinel与主/从服务器的频道消息

Sentinel默认会以2s一次的频率向主服务__sentinel__:hello频道发送PUSH命令，该命令包含当前Sentinel的基本信息已经订阅的主服务器信息。同时__sentinel__:hello频道产生消息时，主服务、所有订阅该频道的从服务器（包括发送这条消息的Sentinel服务器），都会接收到这条频道消息，收到这条消息的Sentinel服务器（发送这条消息的Sentinel服务器可以通过消息内的信息过滤掉这条消息）会讲信息更新到对应的masters->sentinelRedisInstance#sentinels结构中。

通过频道消息获取到集群其它的Sentinel后，Sentinel将会与其它连接同一个主服务的Sentinel建立命令连接，通过该命令连接可以交换Sentinel之间的信息。最终的连接示意图如上：哨兵模式。

主观/客观下线检测

Sentinel会以每秒一次的频率向所有建立连接的实例（主从服务器及其它Sentinel）发送PING命令，通过这个命令回复来判断响应方是否在线，如果在指定的时间内连续多次返回无效响应（除+PONG、-LOADING、-MASTERDOWN这三种回复以外的其他任何响应或者无响应），则会将实例对应的状态flags标记为SRI_S_SOWN，即主观下线状态。

当Sentinel判断主服务器为主观下线状态后，Sentinel会将SENTINEL is-master-sown-by-addr命令发送给其它所有Sentinel，其它Sentinel接收到命令后会检查对应主服务状态并返回主服务的状态及配置纪元，接收到各个响应后Sentinel会判断响应中标记为下线的响应数量，如果超过quorum的值，则将会把主服务器标记位客观下线状态。

故障转移

当一个主服务器下线后，Sentinel集群首先会选举出一个领头的来做故障转移，选主的过程是基于Raft算法（Raft算法演示：http://thesecretlivesofdata.com/raft/），基本思想就是最先得到半数以上的选票的Sentinel将成为领头Sentinel。

选举出领头Sentinel后，其将对已下线的服务器进行故障转移操作，具体步骤如下：

1. 在已下线的主服务对应的从服务器中，选择其中一个将其转换为主服务器。
2. 将其它的从服务器的复制关系改为新的主服务器。
3. 将已下线的服务器变为从服务器，当其恢复后会作为一个从服务器从而不会影响现有运行的主从集群。

如何选出新的主服务器

领头的Sentinel会将所有的从服务器保存到一个列表，然后通过以下规则来进行过滤：

• 删除列表中所有失效的从服务器，只保留健康的。
• 删除列表中所有近5s没有回复领头Sentinel的INFO命令的从服务器。
• 删除列表中最先与原主服务器断连的从服务器（断连时间大于down-after-milliseconds*10 ms的），为了保证从服务器数据尽可能最新。
• 判断剩余从服务器的优先级，排序取最高的。
• 如果多个从服务器优先级相同，则选择复制偏移量最大的。
• 若还是有多个则选择runid最小的从服务器。

转换各服务器主从订阅关系

当新的主服务器选举成功后，领头Sentinel将首先对其发送SLAVEOF no one命令，然后会每秒一次的频率发送INFO命令，通过命令的回复中角色（role:master）的变化信息来判断被选中的从服务器是否成功变更为主服务器。

下一步，领头Sentinel将会通过SLAVEOF <master ip:port>命令发送给所有的从服务器，该命令将更换所有从服务器的订阅关系。

最后，领头Sentinel会在旧的master重新连线后将其更新为新主服务器的从服务器。

至此，整个故障转移过程结束。

以上就是Redis Sentinel的介绍，如果各位还想了解更多，欢迎转发+关注+评论，Redis图解系列专栏持续更新中。