1、Redis Sentinel服務配置

1.1簡介

Redis 的 Sentinel 系統(tǒng)用于管理多個 Redis 服務器（instance）， 該系統(tǒng)執(zhí)行以下三個任務：

監(jiān)控（Monitoring）： Sentinel 會不斷地檢查你的主服務器和從服務器是否運作正常。

提醒（Notification）： 當被監(jiān)控的某個 Redis 服務器出現(xiàn)問題時， Sentinel 可以通過API 向管理員或者其他應用程序發(fā)送通知。

自動故障遷移（Automatic failover）： 當一個主服務器不能正常工作時， Sentinel 會開始一次自動故障遷移操作， 它會將失效主服務器的其中一個從服務器升級為新的主服務器， 并讓失效主服務器的其他從服務器改為復制新的主服務器； 當客戶端試圖連接失效的主服務器時， 集群也會向客戶端返回新主服務器的地址， 使得集群可以使用新主服務器代替失效服務器。

Redis Sentinel 是一個分布式系統(tǒng)， 你可以在一個架構(gòu)中運行多個 Sentinel 進程（progress）， 這些進程使用流言協(xié)議（gossip protocols)來接收關(guān)于主服務器是否下線的信息， 并使用投票協(xié)議（agreement protocols）來決定是否執(zhí)行自動故障遷移，以及選擇哪個從服務器作為新的主服務器。

雖然 Redis Sentinel 釋出為一個單獨的可執(zhí)行文件 redis-sentinel ， 但實際上它只是一個運行在特殊模式下的 Redis 服務器， 你可以在啟動一個普通 Redis 服務器時通過給定 --sentinel 選項來啟動Redis Sentinel 。

1.2相關(guān)配置

案例：

如果要監(jiān)控兩個redis實例，可以進行如下配置Redis安裝目錄下sentinel.conf文件：

常規(guī)配置：

port 26379

daemonize yes

logfile "/var/log/redis/sentinel.log"

#master 7000

sentinel monitor master1 127.0.0.1 7000 2                #配置master名、ip、port、需要多少個sentinel才能判斷[客觀下線]（2）

sentinel down-after-milliseconds master-7000 30000      #配置sentinel向master發(fā)出ping，最大響應時間、超過則認為主觀下線

sentinel parallel-syncs master-7000 1                   #配置在進行故障轉(zhuǎn)移時，運行多少個slave進行數(shù)據(jù)備份同步(越少速度越快)

sentinel failover-timeout master-7000 180000            #配置當出現(xiàn)failover時下一個sentinel與上一個sentinel對[同一個master監(jiān)測的時間間隔](最后設(shè)置為客觀下線)
 

#master 7001

sentinel monitor master2 127.0.0.1 7001 1

sentinel down-after-milliseconds master-7001 30000

sentinel parallel-syncs master-7001 1

sentinel failover-timeout master-7001 180000

特殊配置：

min-slaves-to-write 1

min-slaves-max-lag 10

通過上面的配置，當一個redis是master時，如果它不能向至少一個slave寫數(shù)據(jù)(上面的min-slaves-to-write指定了slave的數(shù)量)，它將會拒絕接受客戶端的寫請求。由于復制是異步的，master無法向slave寫數(shù)據(jù)意味著slave要么斷開連接了，要么不在指定時間內(nèi)向master發(fā)送同步數(shù)據(jù)的請求了(上面的min-slaves-max-lag指定了這個時間)。

1.3 相關(guān)術(shù)語說明

Sentinel包括兩個重要的術(shù)語：主觀下線和客觀下線>

1. 主觀下線（Subjectively Down， 簡稱 SDOWN）指的是單個 Sentinel 實例對服務器做出的下線判斷。

2. 客觀下線（Objectively Down， 簡稱 ODOWN）指的是多個 Sentinel 實例在對同一個服務器做出 SDOWN 判斷， 并且通過SENTINEL is-master-down-by-addr 命令互相交流之后， 得出的服務器下線判斷。

客觀下線條件只適用于主服務器： 對于任何其他類型的 Redis 實例， Sentinel 在將它們判斷為下線前不需要進行協(xié)商， 所以從服務器或者其他 Sentinel 永遠不會達到客觀下線條件。

只要一個 Sentinel 發(fā)現(xiàn)某個主服務器進入了客觀下線狀態(tài)， 這個Sentinel 就可能會被其他 Sentinel 推選出， 并對失效的主服務器執(zhí)行自動故障遷移操作。

每個Sentinel實例都執(zhí)行的定時任務

1. 每個Sentinel 以每秒鐘一次的頻率向它所知的主服務器、從服務器以及其他 Sentinel 實例發(fā)送一個 PING 命令。

2. 如果一個實例（instance）距離最后一次有效回復 PING 命令的時間超過 down-after-milliseconds 選項所指定的值， 那么這個實例會被 Sentinel 標記為主觀下線。 一個有效回復可以是： +PONG 、 -LOADING 或者-MASTERDOWN 。

3. 如果一個主服務器被標記為主觀下線， 那么正在監(jiān)視這個主服務器的所有 Sentinel 要以每秒一次的頻率確認主服務器的確進入了主觀下線狀態(tài)。

4. 如果一個主服務器被標記為主觀下線， 并且有足夠數(shù)量的 Sentinel （至少要達到配置文件指定的數(shù)量）在指定的時間范圍內(nèi)同意這一判斷， 那么這個主服務器被標記為客觀下線。

5. 在一般情況下， 每個 Sentinel 會以每10 秒一次的頻率向它已知的所有主服務器和從服務器發(fā)送 INFO 命令。 當一個主服務器被 Sentinel 標記為客觀下線時， Sentinel 向下線主服務器的所有從服務器發(fā)送 INFO 命令的頻率會從 10 秒一次改為每秒一次。

6. 當沒有足夠數(shù)量的 Sentinel 同意主服務器已經(jīng)下線， 主服務器的客觀下線狀態(tài)就會被移除。 當主服務器重新向 Sentinel 的 PING 命令返回有效回復時， 主服務器的主管下線狀態(tài)就會被移除。

1.4服務日志說明

Sentinel服務啟動后會打印一些相關(guān)日志信息，以下是相關(guān)日志特殊字符說明：

+reset-master instance details> ：主服務器已被重置。

+slave instance details> ：一個新的從服務器已經(jīng)被 Sentinel 識別并關(guān)聯(lián)。

+failover-state-reconf-slaves instancedetails> ：故障轉(zhuǎn)移狀態(tài)切換到了reconf-slaves 狀態(tài)。

+failover-detected instance details>：另一個 Sentinel 開始了一次故障轉(zhuǎn)移操作，或者一個從服務器轉(zhuǎn)換成了主服務器。

+slave-reconf-sent instance details>：領(lǐng)頭（leader）的 Sentinel 向?qū)嵗l(fā)送了 SLAVEOF 命令，為實例設(shè)置新的主服務器。

+slave-reconf-inprog instancedetails> ：實例正在將自己設(shè)置為指定主服務器的從服務器，但相應的同步過程仍未完成。

+slave-reconf-done instance details>：從服務器已經(jīng)成功完成對新主服務器的同步。

-dup-sentinel instance details> ：對給定主服務器進行監(jiān)視的一個或多個 Sentinel 已經(jīng)因為重復出現(xiàn)而被移除 —— 當 Sentinel 實例重啟的時候，就會出現(xiàn)這種情況。

+sentinel instance details> ：一個監(jiān)視給定主服務器的新 Sentinel 已經(jīng)被識別并添加。

+sdown instance details> ：給定的實例現(xiàn)在處于主觀下線狀態(tài)。

-sdown instance details> ：給定的實例已經(jīng)不再處于主觀下線狀態(tài)。

+odown instance details> ：給定的實例現(xiàn)在處于客觀下線狀態(tài)。

-odown instance details> ：給定的實例已經(jīng)不再處于客觀下線狀態(tài)。

+new-epoch instance details> ：當前的紀元（epoch）已經(jīng)被更新。

+try-failover instance details> ：一個新的故障遷移操作正在執(zhí)行中，等待被大多數(shù) Sentinel 選中（waiting to be elected by themajority）。

+elected-leader instance details> ：贏得指定紀元的選舉，可以進行故障遷移操作了。

+failover-state-select-slave instancedetails> ：故障轉(zhuǎn)移操作現(xiàn)在處于select-slave 狀態(tài) —— Sentinel 正在尋找可以升級為主服務器的從服務器。

no-good-slave instance details> ：Sentinel 操作未能找到適合進行升級的從服務器。Sentinel 會在一段時間之后再次嘗試尋找合適的從服務器來進行升級，又或者直接放棄執(zhí)行故障轉(zhuǎn)移操作。

selected-slave instance details> ：Sentinel 順利找到適合進行升級的從服務器。

failover-state-send-slaveof-nooneinstance details> ：Sentinel 正在將指定的從服務器升級為主服務器，等待升級功能完成。

failover-end-for-timeout instancedetails> ：故障轉(zhuǎn)移因為超時而中止，不過最終所有從服務器都會開始復制新的主服務器（slaves will eventually be configured to replicate with the newmaster anyway）。

failover-end instance details> ：故障轉(zhuǎn)移操作順利完成。所有從服務器都開始復制新的主服務器了。

+switch-master master name>oldip> oldport> newip> newport> ：配置變更，主服務器的 IP 和地址已經(jīng)改變。 這是絕大多數(shù)外部用戶都關(guān)心的信息。

+tilt ：進入 tilt 模式。

-tilt ：退出 tilt 模式。

1.5測試驗證

可以對master-slave進行測試，將master關(guān)閉，此時slave會自動充當新的new-master；

當old-master恢復后，會充當new-master的slave，即：在這個過程中，sentinel.conf會被改寫，改寫為當前監(jiān)控的主機master服務；

如下圖測試所示：

Master服務停止：

Old-Master恢復服務：

以上這篇Redis Sentinel服務配置流程(詳解)就是小編分享給大家的全部內(nèi)容了，希望能給大家一個參考，也希望大家多多支持腳本之家。