一套合理的監控機制是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節點都建立起連接， 實現了對每個節點的監控， 這個定時任務是節點失敗判定的重要依據。
