IT工程師數位筆記本

 回到目錄

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

 回到目錄