上一篇 我們模擬了單機器下哨兵模式的搭建，那麼接下來我們看下哨兵模式的實現與工作。 為什麼又分成兩篇呢？因為篇幅太長（偷懶），再一個這篇主要說的是Sentinel的初始化以及信息交換，下一篇著重說下狀態檢查、Sentinel頭領選舉與故障轉移 。 啟動並初始化Sentinel 當一個Sentinel ...
上一篇 我們模擬了單機器下哨兵模式的搭建，那麼接下來我們看下哨兵模式的實現與工作。
為什麼又分成兩篇呢？因為篇幅太長（偷懶），再一個這篇主要說的是Sentinel的初始化以及信息交換，下一篇著重說下狀態檢查、Sentinel頭領選舉與故障轉移 。
啟動並初始化Sentinel
當一個Sentinel啟動時，需要執行以下步驟：
（1）初始化伺服器。
因為Sentinel本事上是一個運行在特殊模式下的Redis伺服器，所以啟動時的第一步也就是初始化一個普通的Redis伺服器。不同點是在初始化的時候不會載入RDB或AOF文件。
（2）將普通的Redis伺服器使用的代碼替換成Sentinel專用代碼。
埠替換Redis伺服器使用redis.h/REDIS_SERVERPORT（6379）常量作為伺服器埠，而Sentinel則使用sentinel.c/REDIS_SENTINEL_PORT（26379）常量作為伺服器埠。
另外Redis伺服器使用redisCommandTable伺服器作為命令表，而Sentinel則使用sentinelcmds作為伺服器的命令表，並且其中的info命令會使用Sentinel模式下專用的sentinelInfoCommand函數，而不是普通redis伺服器使用的redis.c/infoCommand函數。
（3）初始化Sentinel狀態。
伺服器會初始化一個sentinel.c/sentinelState結構（'Sentinel狀態'），用於保存伺服器中所有和Sentinel功能有關的狀態。
struct sentinelState{ //當前紀元，用於實現故障轉移 uint64_t current_epoch; //保存了所有被這個sentinel監視的主伺服器 //字典的鍵是主伺服器的名字 //字典中的值是一個指向sentinelRedisInstance結構的指針 dict *masters; //是否進入TILT模式 int tilt; //目前正在執行的腳本數量 int running_scripts; //進圖TILT模式的時間 mstime_t tilt_start_time; //一個FIFO隊列，包含了所有需要執行的用戶腳本 list *scripts_queue; } sentinel;
（4）根據給定的配置文件，初始化Sentinel的監視主伺服器列表。
sentinelRedisInstance結構（實例結構）
typedef struct sentinelRedisInstance{ //標識值，記錄了實例的類型以及該實例的當前狀態 int flag; //實例的名稱（主伺服器由用戶配置，從伺服器自動設置ip:port） char *name; //實例的運行id char *runid; //配置紀元，用戶實現故障轉移 uint64_t config_epoch; //實例的地址 //sentinelAddr *addr; //實例無相應多少毫秒之後才會被判斷主觀下線 mstime_t down_after_period‘； //判斷這個實例為客觀下線所需要支持的投票數量 int quorun; //在執行故障轉移操作時，可以同時對新的主伺服器進行同步的從伺服器數量 int parallel_syncs; //刷新故障遷移狀態的最大時間限制 mstime_t fallover_timeout; } sentinelRedisInstance;
*addr 指向sentinelAddr結構：
typedef struct sentinelAddr{ char *ip; int port; } sentinelAddr;
根據用戶的配置初始化實例結構：
#名稱 ip port
sentinel monitor mymaster 127.0.0.1 6379 2
#實例在相應多少毫秒之後才會被判斷主觀下線
sentinel down-after-milliseconds mymaster 3000
sentinel failover-timeout mymaster 10000
#在執行故障轉移操作時，可以同時對新的主伺服器進行同步的從伺服器數量
sentinel parallel-syncs mymaster 1
（5）創建連向主伺服器的網路連接。
Sentinel將稱為主伺服器的客戶端，它可以向主伺服器發送命令，並從命令回覆中獲取相關的信息：對於被Sentinel監視的主伺服器來說，Sentinel會創建兩個連向主伺服器的非同步網路連接，一個是命令連接這個連接專門用於向主伺服器發送命令，並接收命令回覆；另一個是訂閱連接這個連接專門用於訂閱主伺服器的_sentinel_:hollo頻道。
獲取主伺服器信息
sentinel預設會以每十秒一次的頻率，通過命令連接向被監視的主伺服器發送INFO命令，並通過分析INFO命令的回覆來獲取主伺服器的當前信息。
通過分析主伺服器返回的INFO命令回覆，Sentinel可以獲取以下兩個方面的信息：
一方面是關於主伺服器本身的信息，包括run_id域記錄的伺服器運行ID以及role域記錄的伺服器角色；另一方面是關於主伺服器屬下的所有從伺服器信息，每個從伺服器由一個“slave”字元串開頭的行記錄，每行的ip=域記錄了從伺服器的IP地址，而port=域則記錄了從伺服器的埠號。根據這些IP地址和埠號，Sentinel無須用戶提供從伺服器的地址信息，就可以自動發現從伺服器。
主伺服器 實力結構的flags屬性的值為SRI_MASTER，而從伺服器實例結構的flags屬性的值為SRI_SLAVE。
當Sentinel發現主伺服器有新的從伺服器出現時，Sentinel除了會為這個新的從伺服器創建相應的實例結構外，Sentinel還會創建連接到從伺服器的命令連接和訂閱連接。
在預設情況下，Sentinel會以每兩秒一次的頻率，通過命令連接向所有被監視的主伺服器和從伺服器發送以下格式的命令，PUBLISH _sentinel_:hello "< s_ip > < s_port >< s_runid >< s_epoch > < m_name > < m_ip >< m_ip ><m_epoch>"。
接收來自主伺服器和從伺服器的頻道信息
當Sentinel與一個主伺服器或者從伺服器建立起訂閱連接之後，Sentinel就會通過訂閱連接，向伺服器發送以下命令：SUBSCRIBE __semtomel__:hello
當一個Sentinel從__sentinel__:hello頻道收到一條信息時，Sentinel會對這條信息進行分析，提取出信息中的Sentinel IP地址，Sentinel埠號，Sentinel運行ID等八個參數，併進行檢查：如果信息中記錄的Sentinel運行ID和基爾獸信息的Sentinel的運行ID相同，那麼說明這條信息時Sentinel自己發送的，Sentinel將丟棄這條信息，不做處理，反之如果記錄的Sentinel運行ID和接收消息的Sentinel的運行ID不相同，那麼說明這條信息時監視同一個伺服器的其他Sentinel發來的，接收信息的Sentinel將根據這些信息中的參數，對相應主伺服器的實例結構進行更新。
Sentinel為主伺服器創建的實例結構中的sentinels字典中除了保存本身以外，還會保存同樣監視這個主伺服器的其他Sentinel的資料，其中字典鍵為 ip:port 值為Sentinel實例結構。
如果目標Sentinel（接收消息的Sentinel）接收到源Sentinel（發送消息的Sentinel）的消息，提取其中的參數檢查主伺服器實例結構的sentinels字典中源Sentinel實例結構是否存在，如果存在則更新，不存在則創建實例結構並存儲到主伺服器的sentinels字典中。並且，目標Sentinel還會創建連接向源Sentinel的命令連接，最終監視同一主伺服器的多個Sentinel將形成互相連接的網路。
但是Sentinel之間不對創建訂閱連接，這是因為Sentinel需要通過接收主伺服器或者從伺服器發來的頻道信息發現未知的新Sentinel，所以才需要建立訂閱連接，而相互已知的Sentinel只要使用命令連接來進行通信就足夠了。
每天學一點，總會有收穫。
下篇我們看下Redis的Sentinel(哨兵)的狀態檢查、Sentinel頭領選舉與故障轉移。
說明：尊重作者知識產權，文中內容參考《Redis設計與實現》，僅在此做學習與大家分享。
