Redis集羣~windows下搭建Sentinel環境及它對主從模式的實際意義

 回到目錄

關於redis-sentinel出現的緣由

Redis集羣的主從模式有個最大的弊端，就是當主master掛了以前，它的slave從服務器沒法提高爲主，而在redis-sentinel出現以後，有效的解決了這個問題，它至關因而一個投票者或者哨兵，它時刻監視着redis集羣的各個服務器，當主master掛了以後，它將進行投票進行新master的選舉，通常地，咱們會創建多個redis-sentinel服務器，它們都會進行主master的選舉工做，當多個redis-sentinal都選擇同一個主以後，這個主纔有效！

關於以前的主從模式

對於內部的主從模式（master-slaves)主要實現了數據的讀寫分離，能夠有效的提高服務器的吞吐量，但對於高可用上，表現不佳，由於當主掛了以後，從slave沒法成爲主，或者沒有這種機制，相關主從環境搭建請像個人這篇文章

《Redis學習筆記~conf自主集羣模式》

關於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 模式。

 回到目錄