回到目錄

關於redis-sentinel出現的原因

Redis叢集的主從模式有個最大的弊端，就是當主master掛了之前，它的slave從伺服器無法提升為主，而在redis-sentinel出現之後，有效的解決了這個問題，它相當於是一個投票者或者哨兵，它時刻監視著redis叢集的各個伺服器，當主master掛了之後，它將進行投票進行新master的選舉，一般地，我們會建立多個redis-sentinel伺服器，它們都會進行主master的選舉工作，當多個redis-sentinal都選擇同一個主之後，這個主才有效！

關於之前的主從模式

對於內部的主從模式（master-slaves)主要實現了資料的讀寫分離，可以有效的提升伺服器的吞吐量，但對於高可用上，表現不佳，因為當主掛了之後，從slave無法成為主，或者沒有這種機制，相關主從環境搭建請像我的這篇文章

關於sentinel環境的搭建

1 下載redis3.2版

2 建立幾個副本資料夾

3 對redis-window.conf的資訊進行修改，主要有以下3點

sentinel monitor mymaster 127.0.0.1 6379 2 //當前的主master,2個sentinel選舉成功後，才有效
sentinel down-after-milliseconds mymaster 60000 //判斷主master掛機的時間（毫秒）
sentinel failover-timeout mymaster 180000 //失敗的超時時間
sentinel parallel-syncs mymaster 1  //選項指定了在執行故障轉移時， 最多可以有多少個從伺服器同時對新的主伺服器進行同步， 這個數字越小， 完成故障轉移所需的時間就越長
 

4 以sentinel模組支援redis-server

對於windows版本的redis，沒有像linux環境裡redis-sentinel程序，而可以使用redis-server來啟動sentinal，我們只要新增這個引數即可，程式碼如下

5 檢視redis-sentinel下的主從伺服器

• SENTINEL masters ：列出所有被監視的主伺服器，以及這些主伺服器的當前狀態。
• SENTINEL slaves ：列出給定主伺服器的所有從伺服器，以及這些從伺服器的當前狀態。
• SENTINEL get-master-addr-by-name ： 返回給定名字的主伺服器的 IP 地址和埠號。 如果這個主伺服器正在執行故障轉移操作， 或者針對這個主伺服器的故障轉移操作已經完成， 那麼這個命令返回新的主伺服器的 IP 地址和埠號。
• SENTINEL reset ： 重置所有名字和給定模式 pattern 相匹配的主伺服器。
• SENTINEL failover ： 當主伺服器失效時， 在不詢問其他 Sentinel 意見的情況下， 強制開始一次自動故障遷移 （不過發起故障轉移的 Sentinel 會向其他 Sentinel 傳送一個新的配置，其他 Sentinel 會根據這個配置進行相應的更新）。

連線指定的redis-sentinel伺服器

顯示當前的主master伺服器

Redis-sentinel的實際意義

對於我們使用方來說，有了redis-sentinel就等於有了當前的redis-master，即我們的資料就知道向哪臺伺服器寫入了（其它slave都是從master同步的資料），這對於使用客戶端的開發人員來說，直接連結redis-sentinel的返回值即可，當然前提是你不要求橫向擴充套件，不要求分片儲存，當然，這對一個大型資料儲存來說，是可笑的，我們當然需要擴充套件，對大資料當然要進行自動分片，所有我們需要為redis-sentinal再加一層統一的代理伺服器，如Twemproxy，有了ＴＷ代理，我們在連線redis時，直接連線ＴＷ的地址即可，這會自動分片，並且自動向redis-sentinel並連線真實的redis-master伺服器！

對於我們的Sentinel來說，我們只能對它進行一些簡單的操作，如訂閱服務，同時，它為我們開放了很多事件，供我們在外面呼叫

Sentinel模式下的幾個事件

• +reset-master ：主伺服器已被重置。
• +slave ：一個新的從伺服器已經被 Sentinel 識別並關聯。
• +failover-state-reconf-slaves ：故障轉移狀態切換到了 reconf-slaves 狀態。
• +failover-detected ：另一個 Sentinel 開始了一次故障轉移操作，或者一個從伺服器轉換成了主伺服器。
• +slave-reconf-sent ：領頭（leader）的 Sentinel 向例項傳送了 [SLAVEOF](/commands/slaveof.html) 命令，為例項設定新的主伺服器。
• +slave-reconf-inprog ：例項正在將自己設定為指定主伺服器的從伺服器，但相應的同步過程仍未完成。
• +slave-reconf-done ：從伺服器已經成功完成對新主伺服器的同步。
• -dup-sentinel ：對給定主伺服器進行監視的一個或多個 Sentinel 已經因為重複出現而被移除 —— 當 Sentinel 例項重啟的時候，就會出現這種情況。
• +sentinel ：一個監視給定主伺服器的新 Sentinel 已經被識別並新增。
• +sdown ：給定的例項現在處於主觀下線狀態。
• -sdown ：給定的例項已經不再處於主觀下線狀態。
• +odown ：給定的例項現在處於客觀下線狀態。
• -odown ：給定的例項已經不再處於客觀下線狀態。
• +new-epoch ：當前的紀元（epoch）已經被更新。
• +try-failover ：一個新的故障遷移操作正在執行中，等待被大多數 Sentinel 選中（waiting to be elected by the majority）。
• +elected-leader ：贏得指定紀元的選舉，可以進行故障遷移操作了。
• +failover-state-select-slave ：故障轉移操作現在處於 select-slave 狀態 —— Sentinel 正在尋找可以升級為主伺服器的從伺服器。
• no-good-slave ：Sentinel 操作未能找到適合進行升級的從伺服器。Sentinel 會在一段時間之後再次嘗試尋找合適的從伺服器來進行升級，又或者直接放棄執行故障轉移操作。
• selected-slave ：Sentinel 順利找到適合進行升級的從伺服器。
• failover-state-send-slaveof-noone ：Sentinel 正在將指定的從伺服器升級為主伺服器，等待升級功能完成。
• failover-end-for-timeout ：故障轉移因為超時而中止，不過最終所有從伺服器都會開始複製新的主伺服器（slaves will eventually be configured to replicate with the new master anyway）。
• failover-end ：故障轉移操作順利完成。所有從伺服器都開始複製新的主伺服器了。
• +switch-master ：配置變更，主伺服器的 IP 和地址已經改變。 這是絕大多數外部使用者都關心的資訊。
• +tilt ：進入 tilt 模式。
• -tilt ：退出 tilt 模式。

 回到目錄