Redis 哨兵節點之間相互自動發現機制（自動重寫哨兵節點的配置文件）

 

Redis的哨兵機制中，若是是多哨兵模式，哨兵節點之間也是能夠相互感知的，各類搜索以後出來的是千篇一概的一個基礎配置文件，
在配置當前哨兵節點的配置文件中，並無配置其餘哨兵節點的任何信息。
以下是一個哨兵節點的配置信息，能夠看到，哨兵與哨兵之間沒有任何配置，死活想不明白，哨兵之間是如何自動識別的。

#sentinel端口
port 26379
#工做路徑，注意路徑不要和主重複
dir "./"
# 守護進程模式
daemonize yes
#關閉保護模式
protected-mode no
# 指明日誌文件名
logfile "./sentinel.log"
#哨兵監控的master，主從配置同樣，這裏只用輸入redis主節點的ip/port和法定人數。
sentinel monitor mymaster 127.0.0.1 6379 2
# master或slave多長時間（默認30秒）不能使用後標記爲s_down狀態。
sentinel down-after-milliseconds mymaster 5000
#若sentinel在該配置值內未能完成failover操做（即故障時master/slave自動切換），則認爲本次failover失敗。
sentinel failover-timeout mymaster 18000
#設置master和slaves驗證密碼
sentinel auth-pass mymaster root

參考「http://www.javashuo.com/article/p-xtdpgzll-ed.html」中的說法

 

那麼哨兵節點直接是如何自動發現的呢，或者說從哪裏能夠體現出來哨兵節點之間的自動發現呢？
既然會自動識別，所以就懷疑，哨兵節點啓動以後，會將自動將這些信息記錄到配置文件中去，試了一把，果不其然。

 

以下是在Redis主從複製的基礎上，依次啓用三個哨兵節點的後，sentinel.cnf的變化狀況
能夠發現，當啓用了三個哨兵節點以後，sentinel.cnf配置文件會被自動重寫，主要有一下幾點，如截圖從#Generated by CONFIG REWRITE開始
1，增長了一個sentinel myid （標識哨兵節點的惟一性）
2，自動追加哨兵節點自己的信息（這樣哨兵節點之間就會相互自動發現），以及redis數據服務的slave的信息
3，自動移除主節點的密碼
4，dir 的相對路徑被修改成絕對路徑

可見，Redis的哨兵不只是Redis自動故障轉義，並且實現了哨兵節點本身的高可用。同時對於密碼之類的信息，也是在哨兵節點初始化以後自動移除。

 

其實這個哨兵機制的拓撲圖（來自於redis開發與運維），我的感受以下，各個哨兵節點之間應該是一個「圖」的關係，任何兩個哨兵節點都是互通的。

主節點自動故障轉移的效果。