一、三个定时监控任务

一套合理的监控机制是Sentinel节点判定节点不可达的重要保证，Redis Sentinel通过三个定时监控任务完成对各个节点发现和监控

每隔10秒

每隔10秒，每个Sentinel节点会向主节点和从节点发送info命令获取最新的拓扑结构，如下图所示

例如下面就是在一个主节点上执行info replication的结果片段：

这个定时任务的作用具体可以表现在三个方面：
通过向主节点执行info命令，获取从节点的信息，这也是为什么 Sentinel节点不需要显式配置监控从节点
当有新的从节点加入时都可以立刻感知出来
节点不可达或者故障转移后，可以通过info命令实时更新节点拓扑信息

每隔2秒

如下图所示：每隔2秒，每个Sentinel节点会向Redis数据节点的__sentinel__：hello频道上发送该Sentinel节点对于主节点的判断以及当前Sentinel节点的信息，同时每个Sentinel节点也会订阅该频道，来了解其他 Sentinel节点以及它们对主节点的判断

所以这个定时任务可以完成以下两个工作：
发现新的Sentinel节点：通过订阅主节点的__sentinel__：hello了解其他的Sentinel节点信息，如果是新加入的Sentinel节点，将该Sentinel节点信息保存起来，并与该Sentinel节点创建连接
Sentinel节点之间交换主节点的状态，作为后面客观下线以及领导者选举的依据
Sentinel节点publish的消息格式如下：

<Sentinel节点IP> <Sentinel节点端口> <Sentinel节点runId> <Sentinel节点配置版本><主节点名字> <主节点Ip> <主节点端口> <主节点配置版本>

每隔1秒

每隔1秒，每个Sentinel节点会向主节点、从节点、其余Sentinel节点发送一条ping命令做一次心跳检测，来确认这些节点当前是否可达
如下图所示。通过上面的定时任务，Sentinel节点对主节点、从节点、其余 Sentinel节点都建立起连接，实现了对每个节点的监控，这个定时任务是节点失败判定的重要依据

二、主观下线和客观下线

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

客观下线

客观下线过程：
当Sentinel主观下线的节点是主节点时，该Sentinel节点会通过sentinel ismaster-down-by-addr命令向其他Sentinel节点询问对主节点的判断，当超过个数（quorum是sentinel配置文件中的
sentinel monitor配置选项后指定的值），Sentinel节点认为主节点确实有问题，这时该Sentinel节点会做出客观下线的决定
这样客观下线的含义是比较明显了，也就是大部分Sentinel节点都对主节点的下线做了同意的判定，那么这个判定就是客观的，如下图所示

sentinel is-master-down-by-addr命令格式如下：
ip：主节点IP
port：主节点端口
current_epoch：当前配置纪元
runid：此参数有两种类型，不同类型决定了此API作用的不同
当runid等于“*”时，作用是Sentinel节点直接交换对主节点下线的判定
当runid等于当前Sentinel节点的runid时，作用是当前Sentinel节点希望目标Sentinel节点同意自己成为领导者的请求，有关Sentinel领导者选举下面介绍

sentinel is-master-down-by-addr <ip> <port> <current_epoch> <runid>

例如sentinel-1节点对主节点做主观下线后，会向其余Sentinel节点（假设sentinel-2和sentinel-3节点）发送该命令：

sentinel is-master-down-by-addr 127.0.0.1 6379 0 *

返回结果包含三个参数，如下所示：
down_state：目标Sentinel节点对于主节点的下线判断，1是下线，0是在线
leader_runid：当leader_runid等于“*”时，代表返回结果是用来做主节点是否不可达，当leader_runid等于具体的runid，代表目标节点同意runid成为领导者
eader_epoch：领导者纪元

redis三个定时监控任务和主观下线、客观下线相关推荐

二十五、三个定时任务及主观客观下线
# 三个定时任务及主观客观下线 ###1.三个定时任务 ###2.主观.客观下线
Sentinel（哨兵）检测主观下线、客观下线、选举领头Sentinel、实现故障转移
文章目录主观下线客观下线选举领头Sentinel 故障转移修改从服务器的复制目标主观下线默认情况下,Sentinel哨兵会以每秒一次的频率向所有与它创建命令连接的实例(包括主服务器.从服务 ...
Redis Sentinel判断主观下线和客观下线
我们需要知道 Sentinel 是通过对自己监控的所有实例(主服务器.从服务器.监控当前主服务器的其他Sentinel)发送PING 命令来判断服务是否下线的,然后Sentinel既然发送了一个命令, ...
Redis 6.2 sentinel判断主观下线和客观下线(源码)
推荐渐进式解析 Redis 源码 - 哨兵 sentinel 上面有讲解的主观下线和客观下线文章目录前言 sentinelCheckSubjectivelyDown(主观下线) sentinelC ...
redis三种架构：主从Cluster哨兵+整合Springboot访问redis
文章目录概要:redis集群方案主从架构部署主从示例: Redis主从工作原理 Sentinel(哨兵)模式哨兵的Jedis连接代码: springboot访问哨兵结点 Cluster模式 R ...
redis三种集群方案
在开发测试环境中,我们一般搭建Redis的单实例来应对开发测试需求,但是在生产环境,如果对可用性.可靠性要求较高,则需要引入Redis的集群方案.虽然现在各大云平台有提供缓存服务可以直接使用,但了解一 ...
Redis三种集群模式介绍
三种集群模式 redis有三种集群模式,其中主从是最常见的模式. Sentinel 哨兵模式是为了弥补主从复制集群中主机宕机后,主备切换的复杂性而演变出来的.哨兵顾名思义,就是用来监控的,主要作用就是 ...
redis 三种集群模式详解
概念:redis有三种集群模式,分别为主从模式,哨兵模式以及集群模式,其中主从是最常见的模式三种集群模式说明 **·**Sentinel 哨兵模式是为了弥补主从复制集群中主机宕机后,主备切换的复杂性 ...
redis php方案,Redis三种部署方案图文详解
standaloan(单机模式) standaloan 是redis单机模式,及所有服务连接一台redis服务,该模式不适用生产.如果发生宕机,内存爆炸,就可能导致所有连接改redis的服务发生缓存失 ...

redis三个定时监控任务和主观下线、客观下线