當(dāng)主服務(wù)器宕機后，需要手動把一臺從服務(wù)器切換為主服務(wù)器，這就需要人工干預(yù)，費事費力，還會造成一段時間內(nèi)服務(wù)不可用。 所以更多時候，我們優(yōu)先考慮哨兵(sentinel) 模式。

Redis sentinel是Redis高可用實現(xiàn)方案：故障發(fā)現(xiàn)、故障自動轉(zhuǎn)移、配置中心、客戶端通知。從Redis的2.6版本開始提供的，但是當(dāng)時這個版本的模式是不穩(wěn)定的，直到Redis的2.8版本以后，這個哨兵模式才穩(wěn)定下來，在生產(chǎn)環(huán)境中，如果想要使用Redis的哨兵模式，也會盡量使用Redis的2.8版本之后的版本。

哨兵雖然有一個單獨的可執(zhí)行文件Redis-sentinel ，但實際上它只是一個運行在特殊模式下的 Redis服務(wù)器，你可以在啟動一個普通Redis服務(wù)器時通過給定--sentinel選項來啟動哨兵，哨兵的一些設(shè)計思路和zookeeper非常類似。

sentinel的定時任務(wù)

sentinel機制中有三種重要的定時任務(wù)。

每10秒每個sentinel對master和slave執(zhí)行info

作用：

• 發(fā)現(xiàn)slave節(jié)點。

• 確認(rèn)主從關(guān)系。

每2秒每個sentinel通過master節(jié)點的channel交換信息(pub/sub)

作用：

• 互相通信掌握節(jié)點的信息和自身信息，可以感知新加入的sentinel

通過master節(jié)點的__sentinel__:hello頻道進(jìn)行交互，所有sentinel訂閱這個頻道并每2秒向該頻道發(fā)布信息

每1秒每個sentinel對其他sentinel和master，slave進(jìn)行ping

作用：

• 心跳檢測

主觀下線和客觀下線

主觀下線

主觀下線：單個sentinel節(jié)點對Redis節(jié)點通信失敗的“偏見”。

這是一種主觀下線。因為在復(fù)雜的網(wǎng)絡(luò)環(huán)境下，這個sentinel與這個master不通，但是如果master與其他的sentinel都是通的呢？所以是一種“偏見”。

這是依靠的第三種定時：每秒去ping一下周圍的sentinel和Redis。對于slave Redis,可以使用這個主觀下線，因為他不需要進(jìn)行故障轉(zhuǎn)移；但是對于master Redis，必須使用客觀下線。

客觀下線

客觀下線：所有sentinel節(jié)點對master Redis節(jié)點失敗“達(dá)成共識”(超過quorum個則統(tǒng)一，quorum可配置)。

這是依靠的第二種定時：每兩秒，sentinel之間進(jìn)行“商量”(一個 sentinel 可以通過向另一個 sentinel 發(fā)送 SENTINEL is-master-down-by-addr 命令來詢問對方是否認(rèn)為給定的服務(wù)器已下線。)

對于master redis的下線，必須要達(dá)成共識才可以，因為涉及故障轉(zhuǎn)移，僅僅依靠一個sentinel判斷是不夠的

領(lǐng)導(dǎo)者選舉

當(dāng)sentinel集群需要故障轉(zhuǎn)移的時候會在集群中選出Leader執(zhí)行故障轉(zhuǎn)移操作。sentinel采用了Raft協(xié)議實現(xiàn)了sentinel間選舉Leader的算法，不過也不完全跟論文描述的步驟一致。sentinel集群運行過程中故障轉(zhuǎn)移完成，所有sentinel又會恢復(fù)平等。Leader僅僅是故障轉(zhuǎn)移操作出現(xiàn)的角色。

選舉流程

某個sentinel認(rèn)定master客觀下線的節(jié)點后，該sentinel會先看看自己有沒有投過票，如果自己已經(jīng)投過票給其他sentinel了，在2倍故障轉(zhuǎn)移的超時時間自己就不會成為Leader。相當(dāng)于它是一個Follower。

如果該sentinel還沒投過票，那么它就成為Candidate。

和Raft協(xié)議描述的一樣，成為Candidate，sentinel需要完成幾件事情
3.1 更新故障轉(zhuǎn)移狀態(tài)為start
3.2 當(dāng)前epoch加1，相當(dāng)于進(jìn)入一個新term，在sentinel中epoch就是Raft協(xié)議中的term。
3.3 更新自己的超時時間為當(dāng)前時間隨機加上一段時間，隨機時間為1s內(nèi)的隨機毫秒數(shù)。

3.4 向其他節(jié)點發(fā)送is-master-down-by-addr命令請求投票。命令會帶上自己的epoch。

3.5 給自己投一票，在sentinel中，投票的方式是把自己master結(jié)構(gòu)體里的leader和leader_epoch改成投給的sentinel和它的epoch。

其他sentinel會收到Candidate的is-master-down-by-addr命令。如果sentinel當(dāng)前epoch和Candidate傳給他的epoch一樣，說明他已經(jīng)把自己master結(jié)構(gòu)體里的leader和leader_epoch改成其他Candidate，相當(dāng)于把票投給了其他Candidate。投過票給別的sentinel后，在當(dāng)前epoch內(nèi)自己就只能成為Follower。

Candidate會不斷的統(tǒng)計自己的票數(shù)，直到他發(fā)現(xiàn)認(rèn)同他成為Leader的票數(shù)超過一半而且超過它配置的quorum(quorum可以參考《redis sentinel設(shè)計與實現(xiàn)》)。sentinel比Raft協(xié)議增加了quorum，這樣一個sentinel能否當(dāng)選Leader還取決于它配置的quorum。

如果在一個選舉時間內(nèi)，Candidate沒有獲得超過一半且超過它配置的quorum的票數(shù)，自己的這次選舉就失敗了。

如果在一個epoch內(nèi)，沒有一個Candidate獲得更多的票數(shù)。那么等待超過2倍故障轉(zhuǎn)移的超時時間后，Candidate增加epoch重新投票。

如果某個Candidate獲得超過一半且超過它配置的quorum的票數(shù)，那么它就成為了Leader。

與Raft協(xié)議不同，Leader并不會把自己成為Leader的消息發(fā)給其他sentinel。其他sentinel等待Leader從slave選出master后，檢測到新的master正常工作后，就會去掉客觀下線的標(biāo)識，從而不需要進(jìn)入故障轉(zhuǎn)移流程。

故障轉(zhuǎn)移過程

當(dāng)多個sentinel發(fā)現(xiàn)并確認(rèn)了master有問題

接著會選舉出一個sentinel作為領(lǐng)導(dǎo)

再選舉出一個slave作為master

通知其余的slave，新的master是誰

通知客戶端一個主從的變化

最后，sentinel會等待舊的master復(fù)活，然后將新master成為slave

那么，如何選擇“合適”的slave節(jié)點呢？

選擇slave-priority(slave節(jié)點優(yōu)先級，人為配置)最高的slave節(jié)點，如果存在則返回，不存在則繼續(xù)。

其次會選擇復(fù)制偏移量最大的slave節(jié)點(復(fù)制得最完整)，如果存在則返回，不存在則繼續(xù)

最后會選擇run_id最小的slave節(jié)點(啟動最早的節(jié)點)

客戶端實現(xiàn)高可用的基本原理

故障轉(zhuǎn)移后客戶端無法感知將無法保證正常的使用。所以，實現(xiàn)客戶端高可用的步驟如下:

客戶端獲取sentinel節(jié)點集合

客戶端通過sentinel get-master-addr-by-name master-name這個api來獲取對應(yīng)主節(jié)點信息

客戶端驗證當(dāng)前獲取的“主節(jié)點”是真正的主節(jié)點，這樣的目的是為了防止故障轉(zhuǎn)移期間主節(jié)點的變化

客戶端保持和sentinel節(jié)點集合的聯(lián)系，即訂閱sentinel節(jié)點相關(guān)頻道，時刻獲取關(guān)于主節(jié)點的相關(guān)信息

從上面的模型可以看出，Redis sentinel客戶端只有在初始化和切換主節(jié)點時需要和sentinel進(jìn)行通信來獲取主節(jié)點信息，所以在設(shè)計客戶端時需要將sentinel節(jié)點集合考慮成配置(相關(guān)節(jié)點信息和變化)發(fā)現(xiàn)服務(wù)。

需要說明的問題

• 盡可能在不同物理機上和同一個網(wǎng)絡(luò)部署Redis sentinel的所有節(jié)點

• Redis sentinel中的sentinel節(jié)點個數(shù)應(yīng)該大于等于3且最好是奇數(shù)。(節(jié)點數(shù)多可以保證高可用)

• Redis sentinel中的數(shù)據(jù)節(jié)點和普通數(shù)據(jù)節(jié)點沒有區(qū)別。每個sentinel節(jié)點在本質(zhì)上還是一個Redis實例，只不過和Redis數(shù)據(jù)節(jié)點不同的是，其主要作用是監(jiān)控Redis數(shù)據(jù)節(jié)點

• 客戶端初始化時連接的是sentinel節(jié)點集合，不再是具體的Redis節(jié)點，但sentinel只是配置中心不是代理。

喜歡就點個“在看”唄^_^

總結(jié)

以上是生活随笔為你收集整理的redis 哨兵模式 cluster模式区别_Redis哨兵（Sentinel）模式快速入门的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。