一套合理的监控机制是Sentinel节点判定节点不可达的重要保证, Redis Sentinel通过三个定时监控任务完成对各个节点发现和监控:
1) 每隔10秒, 每个Sentinel节点会向主节点和从节点发送info命令获取最新的拓扑结构, 如图所示
例如下面就是在一个主节点上执行info replication的结果片段:
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.179.103,port=6379,state=online,offset=190458,lag=0
slave1:ip=192.168.179.104,port=6379,state=online,offset=190313,lag=1
master_replid:ddc0f2a7490a07d4462f53bd034731f3f2ed32b3
Sentinel节点通过对上述结果进行解析就可以找到相应的从节点。这个定时任务的作用具体可以表现在三个方面:
·通过向主节点执行info命令, 获取从节点的信息, 这也是为什么Sentinel节点不需要显式配置监控从节点。
·当有新的从节点加入时都可以立刻感知出来。
·节点不可达或者故障转移后, 可以通过info命令实时更新节点拓扑信息。
2) 每隔2秒, 每个Sentinel节点会向Redis数据节点的__sentinel__: hello 频道上发送该Sentinel节点对于主节点的判断以及当前Sentinel节点的信息, 同时每个Sentinel节点也会订阅该频道, 来了解其他Sentinel节点以及它们对主节点的判断, 所以这个定时任务可以完成以下两个工作:
127.0.0.1:6379> pubsub channels
1) "__sentinel__:hello"
127.0.0.1:6379> subscribe __sentinel__:hello
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "__sentinel__:hello"
3) (integer) 1
1) "message"
2) "__sentinel__:hello"
3) "192.168.179.104,26379,4adf7ee7492961131ffcd0d40d8683fc11ae2294,0,mymaster,192.168.179.102,6379,0"
1) "message"
2) "__sentinel__:hello"
3) "192.168.179.102,26379,bf889f09dcbd3539e41d06b575fc831dce9c0538,0,mymaster,192.168.179.102,6379,0"
1) "message"
2) "__sentinel__:hello"
3) "192.168.179.103,26379,2fe22e2d94cc8eea00e13dffafd7563a742147a1,0,mymaster,192.168.179.102,6379,0"
·发现新的Sentinel节点: 通过订阅主节点的__sentinel__: hello了解其他的Sentinel节点信息, 如果是新加入的Sentinel节点, 将该Sentinel节点信息保存起来, 并与该Sentinel节点创建连接。
·Sentinel节点之间交换主节点的状态, 作为后面客观下线以及领导者选举的依据。
Sentinel节点publish的消息格式如下:
<Sentinel节点IP> <Sentinel节点端口> <Sentinel节点runId> <Sentinel节点配置版本>
<主节点名字> <主节点Ip> <主节点端口> <主节点配置版本>
3) 每隔1秒, 每个Sentinel节点会向主节点、 从节点、 其余Sentinel节点发送一条ping命令做一次心跳检测, 来确认这些节点当前是否可达。 如图所示。 通过上面的定时任务, Sentinel节点对主节点、 从节点、 其余Sentinel节点都建立起连接, 实现了对每个节点的监控, 这个定时任务是节点失败判定的重要依据。