為什么要有Redis高可用？

痛點(diǎn)：

• 如果一個(gè)服務(wù)的redis，只有一個(gè)master節(jié)點(diǎn)，那哪天接口機(jī)跟redis機(jī)器網(wǎng)絡(luò)不通，或者redis機(jī)器故障了，不就訪問不了Redis了，如果服務(wù)強(qiáng)依賴redis，那不就崩了
• master多節(jié)點(diǎn)級別的高可用：如果redis有master節(jié)點(diǎn)，以及還有slave節(jié)點(diǎn)，那如果網(wǎng)絡(luò)不通、redis機(jī)器故障了，哪怕故障1個(gè)小時(shí)，整個(gè)服務(wù)的redis都受影響，那如果redis有多個(gè)master節(jié)點(diǎn)（4個(gè)），數(shù)據(jù)分片到這些master里面，那redis機(jī)器如果只是掛了一個(gè)機(jī)器，受影響也是1/4的數(shù)據(jù)。損失減少3/4
• 地區(qū)級別的redis高可用：如果服務(wù)是南北都有部署的，廣州訪問廣州地區(qū)的redis，北京訪問北京的redis。如果北京地區(qū)redis掛了，可以北京地區(qū)連廣州redis，或者直接北京請求轉(zhuǎn)發(fā)到廣州；或者客戶端收到北京失敗請求后，重試到廣州

高可用的手段

高可用的本質(zhì)是有備份，在出現(xiàn)故障的時(shí)候，有backup可以提供服務(wù)。 所以問題核心是備份，那么怎么備份呢？

一下按幾個(gè)層次來簡單解析一下：

持久化：

解決的痛點(diǎn)：數(shù)據(jù)落盤，不會因?yàn)閞edis掛了內(nèi)存數(shù)據(jù)都丟了

redis數(shù)據(jù)存在內(nèi)存的，如果redis掛了，那么重啟后內(nèi)存數(shù)據(jù)就丟失，沒有備份。此時(shí)就是需要持久化了，即把redis存入的數(shù)據(jù)，同時(shí)也寫一份到磁盤，在redis掛了重啟的時(shí)候，可以重新導(dǎo)入磁盤數(shù)據(jù)，來達(dá)到恢復(fù)的目的。

好處：

• 有了磁盤的備份，故障的時(shí)候，可以通過磁盤數(shù)據(jù)恢復(fù)

壞處：

• 依然是單點(diǎn)服務(wù)，數(shù)據(jù)恢復(fù)的時(shí)候需要時(shí)間，這個(gè)時(shí)間長短要看數(shù)據(jù)大小而定，恢復(fù)過程中，服務(wù)依然是不可用
• 非自動化，要手動恢復(fù)

主從同步

解決的痛點(diǎn)：多節(jié)點(diǎn)備份數(shù)據(jù)

上面說的持久化，痛點(diǎn)是在故障的時(shí)候，還得手動通過磁盤文件恢復(fù)。 那么主從同步可以解決這個(gè)痛點(diǎn) 具體是這么做的：redis主節(jié)點(diǎn)，掛N個(gè)從節(jié)點(diǎn)，slave節(jié)點(diǎn)實(shí)時(shí)同步master節(jié)點(diǎn)的數(shù)據(jù)，在master掛了的時(shí)候，可以立刻把slave提升成為master節(jié)點(diǎn)。 因?yàn)閟lave有了master的所有數(shù)據(jù)，因此可以直接切換，不用從磁盤恢復(fù)數(shù)據(jù)，大大縮短這個(gè)恢復(fù)時(shí)間。

好處：

• 故障時(shí)候，不用從磁盤恢復(fù)數(shù)據(jù)，減短故障時(shí)間
• slave節(jié)點(diǎn)一直保持同步，所以數(shù)據(jù)是最新的，可以直接提升為master
• 讀寫分離，master接收寫請求，slave接收讀請求。

壞處：

• 如果代碼寫死了鏈接master節(jié)點(diǎn)，此時(shí)切換了slave節(jié)點(diǎn)，代碼就要更改redis連接配置。解決方案：因此需要設(shè)置一個(gè)VIP，中間件IP，客戶端連接這個(gè)VIP即可，VIP后面怎么轉(zhuǎn)發(fā)，對代碼透明。
• 非自動切換，需要手動切換，深夜時(shí)間無人值班，沒發(fā)現(xiàn)即時(shí)會讓故障時(shí)間延長。

哨兵模式（Sentinel）

解決的痛點(diǎn)：自動故障轉(zhuǎn)移

出故障的時(shí)候可能夜晚，又必須要精通的運(yùn)維才能快速搞定，否則一定崩了，影響服務(wù)和用戶。 有了主從同步，數(shù)據(jù)得以備份，以備故障的時(shí)候可以容器。但是這個(gè)故障切換要手動操作，哨兵模式就是解決這個(gè)痛點(diǎn)：自動轉(zhuǎn)移故障

工作原理： sentinel哨兵也是一個(gè)集群，而且是獨(dú)立于redis集群的一個(gè)服務(wù)。 因此哨兵是多個(gè)節(jié)點(diǎn)的，他的本質(zhì)原理就是，每個(gè)哨兵每秒定時(shí)發(fā)送ping給master，等master回應(yīng) 如果回應(yīng)正常，那沒問題 如果回應(yīng)超時(shí)，那就需要關(guān)注。但是超時(shí)也有可能很多原因，比如網(wǎng)絡(luò)不通暢、偶發(fā)的丟包等等。 假設(shè)有3個(gè)哨兵： 如果只有一個(gè)哨兵得不到回應(yīng)，他會標(biāo)識master 主觀下線，即只是他自己認(rèn)為master下線了 但另外兩個(gè)哨兵是正常的，那就說明master沒有真的下線，可能只是哨兵1網(wǎng)絡(luò)問題

這樣就有個(gè)好處，必須要多數(shù)哨兵認(rèn)為master下線了，才會切換主從。 哨兵自己認(rèn)為master掛了，這種叫主觀下線 半數(shù)以上哨兵認(rèn)為master掛了，他們通過互相信息同步，就認(rèn)為master是客觀下線 這個(gè)時(shí)候，就需要走主從切換流程了

主從切換原理： 正常情況下，多個(gè)slave配置，都配置了slaveof master 如果master被哨兵認(rèn)為客觀下線了，此時(shí)就要進(jìn)行一次“投票”，從slave里面選出新的master。 具體就是修改配置文件、重啟服務(wù)，這幾個(gè)操作的自動化

簡化理解 其實(shí)就好比平常工作中，寫了個(gè)腳本，定時(shí)掃描漏單之類的，這個(gè)定時(shí)腳本也要高可用，所以就部署在多個(gè)接口機(jī)上。 然后腳本定時(shí)探測一下master是否正常，多數(shù)發(fā)現(xiàn)不正常了，就觸發(fā)自動更換配置文件，reload服務(wù)。 就是這么個(gè)道理

標(biāo)識下線機(jī)制，這個(gè)類似rpc重試機(jī)制，一個(gè)機(jī)器返回5xx，得重試到另外一個(gè)機(jī)器，都失敗了，才返回5xx給客戶端。

問題： 問題1. 如果代碼寫死鏈接的masterip， 這樣切換了，代碼還得發(fā)版上線才能生效，所以代碼不能這么說傻叉寫死一個(gè)IP。

解決方案：需要有一個(gè)類似中間件的組件，來做這個(gè)事。比如mysql就有個(gè)中間件，端口就是127.0.0.1:9981服務(wù)，后面轉(zhuǎn)發(fā)到redis真實(shí)IP 。當(dāng)然故障切換后，這個(gè)中間件得知道m(xù)aster是誰了。這個(gè)也是可以通過下發(fā)配置通知的？

問題：還是客戶端直接訪問的sentinel ? sentinel擔(dān)任起中間件的角色？因?yàn)樗續(xù)aster和slave具體信息

實(shí)際解決方案：就是客戶端連接3個(gè)哨兵的ip:端口，讓哨兵來返回redis的主從節(jié)點(diǎn)，他也幫你連接好了，返回一個(gè)redis實(shí)例給你，所以相當(dāng)于是哨兵是中間件，客戶端（代碼）先連接到哨兵，哨兵返回master，再幫你哦鏈接后redis，返回給你。 這樣就不用怕主從切換后的IP變更了

結(jié)構(gòu)圖：

Redis Cluster 集群方案

哨兵機(jī)制解決的是主從自動切換的痛點(diǎn)。 另外一個(gè)痛點(diǎn)是：redis單機(jī)存儲有限；數(shù)據(jù)單點(diǎn) 場景，比如專輯業(yè)務(wù)的痛點(diǎn)：

• redis數(shù)據(jù)都是幾十G的，如果只有一個(gè)master節(jié)點(diǎn)，那么這個(gè)redis機(jī)器要很大內(nèi)存，這樣的配置很貴
• 同時(shí)，如果真有這么大內(nèi)存的redis機(jī)器，那么全部數(shù)據(jù)都單點(diǎn)存儲，一旦這個(gè)機(jī)器掛了，就影響全部用戶

Redis Cluster就是解決以上兩個(gè)痛點(diǎn)的解決方案：

• 數(shù)據(jù)分片，key按規(guī)則hash到不同的節(jié)點(diǎn)，就算某些節(jié)點(diǎn)掛了，之影響那個(gè)節(jié)點(diǎn)的數(shù)據(jù)，提高高可用性
• 每個(gè)機(jī)器的內(nèi)存都不用太大，甚至集齊N個(gè)4G內(nèi)存的機(jī)器，都能組成一個(gè)大容量集群

到此這篇關(guān)于Redis高可用梳理詳解的文章就介紹到這了,更多相關(guān)Redis高可用內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論