Sentinel简述

Sentinel为了解决什么问题？

Sentinel（哨岗、哨兵）是Redis的高可用性（high availability）解决方案。

我们知道Redis 的主从复制模式可以将主节点的数据改变同步给从节点，这样从节点就可以起到以下作用：

1. 作为主节点的一个备份，一旦主节点出了故障不可达的情况，从节点可以作为后备“顶”上来，并且保证数据尽量不丢失(主从复制是最终一致性)。

2. 从节点可以扩展主节点的读能力，一旦主节点不能支撑住大并发量的读操作，从节点可以在一定程度上帮助主节点分担读压力。

但是主从复制也带来了以下问题:

1. 一旦主节点出现故障，需要手动将一个从节点晋升为主节点，同时需要修改应用方的主节点地址，还需要命令其他从节点去复制新的主节点,整个过程都需要人工干预。可用性比较差。

2. 主节点的写能力受到单机的限制。

3. 主节点的存储能力受到单机的限制。

Sentinel是什么？

它是一种解决方案，一般由多个Sentinel实例组成的Sentinel系统。
一个Sentinel实例是一个特殊化redis客户端。不再具备数据读写能力。

Sentinel工作流程

由一个或多个Sentinel实例（instance）组成的Sentinel系统（system）可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。

Sentinel与主从架构的Redis关系图

server1为主服务器
server2，server3，server4为从服务器。
server2、server3、server4三个从服务器正在复制主服务器server1，而Sentinel系统则在监视所有四个服务器。

Sentinel的全局流程

Sentinel的工作状态流转

1. Sentinel完成初始化，开始监听
2. 假设这时，主服务器server1进入下线状态。从服务器server2、server3、server4对主服务器的复制操作将被中止，并且Sentinel系统会察觉到server1已下线。
3. 当server1的下线时长超过用户设定的下线时长上限时，Sentinel系统就会对server1执行故障转移操作：
   首先，Sentinel系统会挑选server1属下的其中一个从服务器，并将这个被选中的从服务器升级为新的主服务器。
   之后，Sentinel系统会向server1属下的所有从服务器发送新的复制指令，让它们成为新的主服务器的从服务器，
   当所有从服务器都开始复制新的主服务器时，故障转移操作执行完毕。
   另外，Sentinel还会继续监视已下线的server1，并在它重新上线时，将它设置为新的主服务器的从服务器。

Sentinel的初始化

1.启动Sentinel的命令

$ redis-sentinel /path/to/your/sentinel.conf

$ redis-server /path/to/your/sentinel.conf --sentinel

2.启动Sentinel的内部流程

当一个Sentinel启动时，它需要执行以下步骤：

1）初始化服务器。
因为Sentinel执行的工作和普通Redis服务器执行的工作不同，所以Sentinel的初始化过程和普通Redis服务器的初始化过程并不完全相同。

例如，普通服务器在初始化时会通过载入RDB文件或者AOF文件来还原数据库状态，但是因为Sentinel并不使用数据库，所以初始化Sentinel时就不会载入RDB文件或者AOF文件。

2）将普通Redis服务器使用的代码替换成Sentinel专用代码。

3）初始化Sentinel状态。

4）根据给定的配置文件，初始化Sentinel的监视主服务器列表。

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

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

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

·另一个是订阅连接，这个连接专门用于订阅主服务器的__sentinel__:hello频道。（为了发现新加入的Sentinel实例）

Sentinel的通信功能

作为一套合理的监控机制，Sentinel必须用合理的通信功能来保证对主节点，从节点，以及不同Sentinel实例之间的信息交流。

Sentinel通过三个定时监控任务完成对各个节点发现和监控。

每隔十秒的定时任务（INFO命令）

Sentinel默认会以每十秒一次的频率，通过命令连接向被监视的主服务器和从服务器发送INFO命令，并通过分析INFO命令的回复来获取主服务器的当前信息。
INFO命令的作用

1. 获取主服务器信息
2. 获取从服务器信息
3. 节点不可达或者故障转移后，可以实时更新节点拓扑信息

这三个作用其实都是从返回的信息中进行解析做到的。
类似于以下内容的回复：

# Server
...
run_id:7611c59dc3a29aa6fa0609f841bb6a1019008a9c
...
# Replication
role:master
...
slave0:ip=127.0.0.1,port=11111,state=online,offset=43,lag=0
slave1:ip=127.0.0.1,port=22222,state=online,offset=43,lag=0
slave2:ip=127.0.0.1,port=33333,state=online,offset=43,lag=0
...
# Other sections
...

INFO命令返回值的内容

通过分析主服务器返回的INFO命令回复，Sentinel可以获取以下两方面的信息：

1. 一方面是关于主服务器本身的信息，包括run_id域记录的服务器运行ID，以及role域记录的服务器角色；

根据run_id域和role域记录的信息，Sentinel将对主服务器的实例结构进行更新。
例如，主服务器重启之后，它的运行ID就会和实例结构之前保存的运行ID不同，Sentinel检测到这一情况之后，就会对实例结构的运行ID进行更新。

2. 另一方面是关于主服务器属下所有从服务器的信息，每个从服务器都由一个"slave"字符串开头的行记录，每行的ip=域记录了从服务器的IP地址，而port=域则记录了从服务器的端口号。根据这些IP地址和端口号，Sentinel无须用户提供从服务器的地址信息，就可以自动发现从服务器。

	于主服务器返回的从服务器信息，则会被用于更新主服务器实例结构的slaves字典，这个字典记录了主服务器属下从服务器的名单.
	Sentinel在分析INFO命令中包含的从服务器信息时，会检查从服务器对应的实例结构是否已经存在于slaves字典,如果从服务器对应的实例结构已经存在，那么Sentinel对从服务器的实例结构进行更新。
	如果从服务器对应的实例结构不存在，那么说明这个从服务器是新发现的从服务器，Sentinel会在slaves字典中为这个从服务器新创建一个实例结构。
	当Sentinel发现主服务器有新的从服务器出现时，Sentinel除了会为这个新的从服务器创建相应的实例结构之外，Sentinel还会创建连接到从服务器的命令连接和订阅连接。

每隔两秒的定时任务（publish/subscribe）

publish
在默认情况下，Sentinel会以每两秒一次的频率，通过命令连接向所有被监视的主服务器和从服务器发送以下格式的命令：

PUBLISH __sentinel__:hello "<s_ip>,<s_port>,<s_runid>,<s_epoch>,<m_name>,<m_ip>,<m_port>,<m_epoch>

·其中以s_开头的参数记录的是Sentinel本身的信息。

·而m_开头的参数记录的则是主服务器的信息。
如果Sentinel正在监视的是主服务器，那么这些参数记录的就是主服务器的信息；如果Sentinel正在监视的是从服务器，那么这些参数记录的就是从服务器正在复制的主服务器的信息。

subscribe
当Sentinel与一个主服务器或者从服务器建立起订阅连接之后，Sentinel就会通过订阅连接，向服务器发送以下命令：

SUBSCRIBE __sentinel__:hello

Sentinel对__sentinel__:hello频道的订阅会一直持续到Sentinel与服务器的连接断开为止。

这也就是说，对于每个与Sentinel连接的服务器，Sentinel既通过命令连接向服务器的__sentinel__:hello频道发送信息，又通过订阅连接从服务器的__sentinel__:hello频道接收信息

作用
通过这个定时任务的publish和subscribe命令，多个sentinel实例之间可以进行对于监控节点的信息校验和分析，也可以更新对其他sentinel实例的信息，因为他们同样都监听了服务器的__sentinel__:hello频道。

当Sentinel通过频道信息发现一个新的Sentinel时，它不仅会为新Sentinel在sentinels字典中创建相应的实例结构，还会创建一个连向新Sentinel的命令连接。
各个Sentinel之间的网络连接最终形成以下结构：

使用命令连接相连的各个Sentinel可以通过向其他Sentinel发送命令请求来进行信息交换

这是客观下线和领导者选举的依据

每隔一秒的定时任务（ping）

心跳监测
每隔1秒，每个Sentinel节点会向主节点、从节点、其余Sentinel节点发送一条ping命令做一次心跳检测，来确认这些节点当前是否可达。

Sentinel对于服务器的下线检测

主观下线

每个Sentinel节点会每隔1秒对主节点、从节点、其他Sentinel节点发送ping命令做心跳检测,当这些节点超过down-after-milliseconds没有进行有效回复，Sentinel节点就会对该节点做失败判定，这个行为叫做主观下线。从字面意思也可以很容易看出主观下线是当前Sentinel节点的一家之言,存在误判的可能。

· 有效回复：实例返回+PONG、-LOADING、-MASTERDOWN三种回复的其中一种。

· 无效回复：实例返回除+PONG、-LOADING、-MASTERDOWN三种回复之外的其他回复，或者在指定时限内没有返回任何回复。

客观下线

当Sentinel主观下线的节点是主节点时，该Sentinel节点会通过sentinel is-master-down-by-addr命令向其他Sentinel节点询问对主节点的判断，当超过<quorum>个数,Sentinel节点认为主节点确实有问题，这时该Sentinel节点会做出客观下线的决定，这样客观下线的含义是比较明显了，也就是大部分Sentinel节点都对主节点的下线做了同意的判定，那么这个判定就是客观的。

Sentinel的领导者选举

假如Sentinel节点对于主节点已经做了客观下线，那么是不是就可以立即进行故障转移了？
当然不是，实际上故障转移的工作只需要一个Sentinel节点来完成即可，所以 Sentinel节点之间会做一个领导者选举的工作，选出一个Sentinel节点作为领导者进行故障转移的工作。Redis使用了Raft算法实现领导者选举。

大致过程如下：
1 )每个在线的Sentinel节点都有资格成为领导者，当它确认主节点主观下线时候，会向其他Sentinel节点发送sentinel is-master-down-by-addr命令，要求将自己设置为领导者。

2)收到命令的Sentinel节点，如果没有同意过其他Sentinel节点的sentinel is-master-down-by-addr命令,将同意该请求,否则拒绝。

3）如果该Sentinel节点发现自己的票数已经大于等于max (quorum，num(sentinels)/2+1）,那么它将成为领导者。

4）如果此过程没有选举出领导者,将进入下一次选举。

选举的过程非常快,基本上谁先完成客观下线,谁就是领导者。

Raft算法
Sentinel系统选举领头Sentinel的方法是对Raft算法的领头选举方法的实现，关于这一方法的详细信息可以观看Raft算法的作者录制的“Raft教程”视频：Raft教程，或者Raft算法的论文。

Raft协议的详细版本：

raft-zh_cn/raft-zh_cn.md at master · maemual/raft-zh_cn · GitHub

如果你想手写一个Raft协议，可以看下蚂蚁金服的开发生产的raft算法组件

[GitHub - sofastack/sofa-jraft: A production-grade java implementation of RAFT consensus algorithm.](

Sentinel的故障转移

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

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

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

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

选取新的主服务器

1)在从节点列表中选出一个节点作为新的主节点,选择方法如下:

a)过滤:“不健康”(主观下线、断线)、5秒内没有回复过Sentinel节点 INFO命令、与主节点失联超过down-after-milliseconds*10毫秒

b)选择slave-priority(从节点优先级)最高的从节点列表，如果存在则返回,不存在(有多个具有最高优先级的从服务器)则继续。

c）选择复制偏移量最大的从节点(复制的最完整)，如果存在则返回,不存在则继续。

d）选择runid最小的从节点。

2 ) Sentinel领导者节点会对第一步选出来的从节点执行slaveof no one命令让其成为主节点。

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

3 ) Sentinel领导者节点会向剩余的从节点发送命令，让它们成为新主节点的从节点,复制规则和parallel-syncs参数有关。
领头Sentinel向已下线主服务器server1的两个从服务器server3和server4发送SLAVEOF命令，让它们复制新的主服务器server2的例子。

4 ) Sentinel节点集合会将原来的主节点更新为从节点，并保持着对其关注，当其恢复后命令它去复制新的主节点。
当server1重新上线时，Sentinel就会向它发送SLAVEOF命令，让它成为server2的从服务器。

Sentinel的一些问题

为什么在Sentinel模式下，Redis不能执行Set等命令

Sentinel只是一个运行在特殊模式下的Redis服务器，它使用了和普通模式不同的命令表，所以Sentinel模式能够使用的命令和普通Redis服务器能够使用的命令不同。

Sentunel为什么要和主从节点建立两个连接？

Sentinel会读入用户指定的配置文件，为每个要被监视的主服务器创建相应的实例结构，并创建连向主服务器的命令连接和订阅连接，其中命令连接用于向主服务器发送命令请求，而订阅连接则用于接收指定频道的消息。

在Redis目前的发布与订阅功能中，被发送的信息都不会保存在Redis服务器里面，如果在信息发送时，想要接收信息的客户端不在线或者断线，那么这个客户端就会丢失这条信息。因此，为了不丢失__sentinel__:hello频道的任何信息，Sentinel必须专门用一个订阅连接来接收该频道的信息。

大家如果还有其他相关问题的话，可以写在评论里，我尽量及时回复并且更新到文章中