Redis高可用集羣方案——哨兵

本篇文章版權歸博客園和做者吳雙本人共同全部，轉載和爬蟲請註明原文系列地址http://www.cnblogs.com/tdws/tag/NoSql/

集羣方案 三主三從 http://www.cnblogs.com/tdws/p/7710545.html

以前有篇文章，講到了redis主從複製，讀寫分離。然而留下的問題是當主服務器掛了，咱們就沒法向客戶端提供任何服務了呀，這樣的方案，就不能稱之爲高可用方案。下面，提供一種Redis集羣高可用方案，拙劣之處，歡迎指正和補充。

Redis爲咱們提供了哨兵，它就像一個爲咱們的Redis服務站崗的人，當主服務器發生異常時，他會經過投票的方式，將從服務節點升爲主服務節點。當咱們處理好主節點故障並重啓時，原來掛掉的主節點，做爲新的主節點的子節點。

爲了在本機測試，首先我在6379，6380，6381節點上開啓三個redis服務，6379作爲master節點，6380和6381做爲其從服務節點。關於主從的配置若是有疑問的話請看個人這篇文章http://www.cnblogs.com/tdws/p/5705782.html。

下面你須要再將redis文件夾機器內容複製出一份，我將其文件夾命名爲Sentinel.

咱們將其配置文件最後，增長以下配置信息。配置信息配置了哨兵端口5000，咱們的redis客戶端，好比C#的stackservice,stackExechange,能夠從哨兵中讀取當前集羣狀況，也就是說主掛後，咱們客戶端均可以獲取到信息，而且重新的服務節點及端口中進行鍵值的操做。另外配置文件說到，主服務節點爲6379，而且多個哨兵時，獲得哨兵們的投票爲1票時就認爲主節點失聯，可切換從節點爲主。

down-after-milliseconds 指明嘗試多少毫秒無反應，哨兵認爲其失聯。

parallel-sync指明當故障發生時，容許有多少個從節點，同時重新的主節點同步數據。這個配置意義在於，你這個值設置的越小，全部從節點同步時間也就越久，好比以下配置，每次只能同步一個，從節點越多，天然也就越久。那麼這個值設置的大，或形成什麼影響，這取決於咱們的配置文件，咱們能夠配置在從同步主節點時，以舊的數據提供給客戶端，在同步完成後，提供新數據，這樣不會形成從節點同步期間不可用的狀況。而然而，在同步完成後，須要刪除舊的數據，加載新的數據，在這短暫的期間，仍是會有從節點不可用的狀況發生。

port 5000
sentinel monitor mymaster 127.0.0.1 6379 1 
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000 
sentinel parallel-syncs mymaster 1

下面就到了咱們啓動sentinel(哨兵)的時候了！

一樣切換到Sentinel文件夾目錄下，執行命令

這樣一來，哨兵"觀察站"啓動了。

首先咱們展現下正常狀況，主從的複製以及讀寫狀況。

上圖主節點寫入新鍵。下圖在兩個從節點讀取數據。

接下來，咱們看一下主節點掛掉以後，會發生什麼。我將主節點服務關閉。

咱們以前的只讀從節點，如今已經升爲可寫的主節點了！

固然，想要作到高可用，哨兵也應該多個節點，有關更多哨兵命令，配置及其原理，下回分解。

 

 

若是個人點滴分享對您有點低幫助，歡迎點擊下方紅色關注，我將持續分享，共同進步