Sentinel是 Redis的高可用性解决方案:由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器,以及这些主服务器属下的所有从服务器,并在被监视的主服务器进入下线状态时,自动 将下线主服务器属下的某个从服务器升级为新的主服务器,然后由新的主服务器代替已下线的主服务器继续处理命令请求。
启动有两种方式
sentinel启动时需要有配置文件
当一个Sentinel启动时,需要执行以下步骤
initServerConfig来初始化一个普通的Redis服务器。
初始化服务器端口,sentinel支持的命令替换普通命令
sentinel状态定义为
初始化在server.c/initSentinel
masters字典记录了所有被Sentinel监视的主服务器的相关信息,通过sentinelHandleConfiguration来处理配置文件中的与sentinel相关的配置
sentinel monitor
结构定义如下
对于每个被Sentinel监视的主服务器,会创建两个连向主服务器的异步网络连接
连接结构定义如下
为什么有两个链接?
在Redis目前的发布与订阅功能中,被发送的信息都不会保存在Redis服务器里面,如果在信息发送时,想要接收信息的客户端不在线或者断线,那么这个客户端就会丢失这条信息。因此,为了不丢失__sentinel__:hello频道的任何信息,sentinel必须专门用一个订阅连接来接收该频道的信息。
另一方面,除了订阅频道外,Sentinel还必须向主服务器发送命令,以此来与主服务器进行通信,所以Sentinel还必须向主服务器创建命令连接。
Sentinel默认会以每10s一次的频率,通过命令连接向被监视的主服务器发送info命令,并通过分析info命令的回复来获取主服务器的当前信息
通过分析主服务器返回的info命令回复,sentinel可以获取以下两方面的信息:
根据run_id域和role域记录的信息,sentinel将对主服务器的实例结构进行更新。至于主服务器返回的从服务器信息,则会被用于更新主服务器实例结构的slaves字典,这个字典记录了主服务器属下从服务器的名单。
sentinel在分析info命令中包含的从服务器信息时,会检查从服务器对应的实例结构是否已经存在于slaves字典:
当sentinel发现主服务器有新的从服务出现时,sentinel除了会为这个新的从服务器创建相应的实例结构之外,sentinel还会创建连接到从服务器的命令连接和订阅连接。在创建命令后,sentinel在默认情况下,会以10s一次的频率通过命令连接向从服务器发送info命令,并获得相应信息。
根据info命令的回复,sentinel会提取以下信息
根据这些信息,sentinel会对从服务器的实例结构进行更新。
在默认情况下,sentinel会以2s一次的频率,通过命令连接向所有被监视的主服务器和从服务器发送以下格式的命令
PUBLISH __sentinel__:hello "
以s_开头的参数记录的是sentinel本身的信息;以m_开头的参数记录的则是主服务器的信息。
参数 | 意义 |
s_ip | sentinel的ip地址 |
s_port | sentinele的端口号 |
s_runid | sentinel的运行ID |
s_epoch | sentinel当前的配置纪元 |
m_name | 主服务器的名字 |
m_ip | 主服务器的ip地址 |
m_port | 主服务器的端口号 |
m_epoch | 主服务器当前的配置纪元 |
当sentinel与一个主服务器或者从服务器建立起订阅连接之后, sentinel就会通过订阅连接,向服务器发送以下命令
SUBSCRIBE __sentinel__:hello
服务器会将客户端(sentinel)添加到server->pubsub_channels中
sentinel对__sentinel__:hello频道的订阅会一直持续到sentinel与服务器的连接断开为止。
对于每个与sentinel连接的服务器,sentinel既通过命令连接向服务器的__sentinel__:hello频道发送信息,又通过订阅连接从服务器的__sentinel__:hello频道接收信息。
将sentinel发布过来的消息转发给其它sentinel
对于监视同一个服务器的多个sentinel来说,一个sentinel发送的信息会被其他sentinel接收到,这些信息会被用于更新其他sentinel对发送信息sentinel的认知,也会被用于更新其他sentinel对被监视服务器的认知。
当一个sentinel从__sentinel__:hello频道收到一条信息时,sentinel会对这条信息进行分析,提取出信息中的sentinel IP地址,sentinel端口号,sentinel运行id等八个参数。
sentinel为主服务器创建的实例结构中的sentinels字典保存了除sentinel本身之外,所有同样监视这个主服务器的其他sentinel的资料
当一个sentinel接收到其他sentinel发来的信息时,目标sentinel会从信息中分析并提取出以下两方面参数
根据信息中提取出的主服务器参数,目标sentinele会在自己的sentinel状态的masters字典中查找相应的主服务器实例结构,然后根据提取出的sentinel参数,检查主服务器实例结构的sentinel字典中,源sentinel的实例结构是否存在:
当sentinel通过频道信息发现一个新的sentinel时,它不会会为新sentinel在sentinels字典中创建相应的实例结构,还会创建一个连向新sentinel的命令连接,而新sentinel也同样会创建连向这个sentinel的命令连接,最终监视同一主服务器的多个sentinel将形成相互连接的网络。
使用命令连接相连的各个sentinel可以通过向其他sentinel发送命令请求来进行信息交换。
sentinel之间不会创建订阅连接
sentinel在连接主服务器或者从服务器时,会同时创建命令连接和订阅连接,但是在连接其他sentinel时,却只会创建命令连接,而不创建订阅连接。这是因为sentinel需要通过接收主服务器或者从服务器发来的频道信息来发现未知的新sentinel,所以才需要建立 订阅连接,而相互已知的sentinel只要使用命令连接来进行通信就足够了。
默认情况下,sentinel会以1s一次的频率向所有与它创建了命令连接的实例(包括主服务器、从服务器、其他sentinel在内)发送ping命令,并通过实例返回的ping命令回复来判断实例是否在线。
实例对ping命令的回复可以分为以下两种情况
sentinel配置文件中的down-after-milliseconds选项指定了sentinel判断实例进入主观下线所需的时间长度:如果一个实例在down-after-milliseconds毫秒内,连续向sentinel返回无效回复,那么sentinel会修改这个实例对应的实例结构,在结构的flags属性中打开SRI_S_DOWN标识,以此来表示这个实例已经进入主观下线状态。
当sentinel将一个主服务器判断为主观下线后,为了确认这个主服务器是否真的下线了,它会向同样监视这一主服务器的其他sentinel进行询问,看它们是否也认为主服务器已经进入了下线状态(可以是主观下线或者客观下线)。当sentinel从其他sentinel那里到足够数据的已下线判断之后,sentinel就会将主服务器判断为客观下线,并对主服务器执行故障转移操作。
sentinel使用
SENTINEL is-master-down-by-addr
ip | 被sentinel判断为主观下线的主服务器的ip地址 |
port | 被sentinel判断为主观下线的主服务器的端口号 |
current_epoch | sentinel当前的配置纪元,用于选举领头sentinel |
runid | 可以是*符号或者sentinel的运行id:*符号代表命令仅仅用于检测主服务器的客观下线状态,而sentinel的运行id则用于选举领头sentinel |
当一个sentinel(目标sentinel)接收到另一个sentinel(源sentinel)发来的SENTINEL is-master-down-by命令时,目标sentinel会分析并取出命令请求中包含的各个参数,并根据其中的主服务器ip和端口号,检查主服务器是否已下线,然后源sentinel返回一条包含三个参数的Multi Bulk回复作为SENTINEL is-master-down-by命令的回复
down_state | 返回目标sentinel对主服务器的检查结果,1代表主服务器已下线,0代表主服务器未下线 |
leader_runid | 可以是 *符号或者目标sentinel的局部领头sentinel的运行id:*符号代表命令仅仅用于检测主服务器的下线状态。而局部领头sentinel的运行id则用于选举领头sentinel。 |
leader_epoch | 目标sentinel的局部领头sentinel的配置纪元,用于选举领头sentinel。仅在leader_runid的值不为*时有效,如果leader_runid的值为*,那么leader_epoch总为0 |
根据其他sentinel发回的SENTINEL is-master-down-by-addr命令回复,sentinel将统计其他sentinel同意主服务器已下线的数量,当这一数量达到配置指定的判断客观下线所需的数量时,sentinel会将主服务器实例结构flags属性的SRI_O_DOWN标识打开 ,表示主服务器已经进入客观下线状态。
下面是处理接收到的回复
下面是检查数量
当一个主服务器被判断为客观下线时,监视这个下线主服务器的各个sentinel会进行协商,选举出一个领头sentinel,并由领头sentinel对下线主服务器进行故障转移操作,以下是redis选举领头sentinel的规则和方法:
在选举产生出领头sentinel之后,领头sentinel将对已下线的主服务器执行故障转移操作,该操作包含以下三个步骤
故障转移状态机状态转移图为
故障转移操作第一步要做的就是在已下线主服务器属下的所有从服务器中,挑选出一个状态良好、数据完整的从服务器,然后向这个从服务器发送slaveof no one命令,将这个从服务器转换为主服务器。
如何选择新的主服务器?
当新的主服务器出现之后,领头sentinel下一步要做的就是,让已下线主服务器属下的所有从服务器支复制新的主服务器,通过向从服务器发送slaveof命令来实现。
故障转移操作最后要做的是,将已下线的主服务器设置为新的主服务器的从服务器。