為什么要有Redis高可用？

痛點：

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

高可用的手段

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

一下按幾個層次來簡單解析一下：

持久化：

解決的痛點：數(shù)據(jù)落盤，不會因為redis掛了內(nèi)存數(shù)據(jù)都丟了

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

好處：

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

壞處：

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

主從同步

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

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

好處：

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

壞處：

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

哨兵模式（Sentinel）

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

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

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

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

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

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

標識下線機制，這個類似rpc重試機制，一個機器返回5xx，得重試到另外一個機器，都失敗了，才返回5xx給客戶端。

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

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

問題：還是客戶端直接訪問的sentinel ? sentinel擔任起中間件的角色？因為它知道m(xù)aster和slave具體信息

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

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

Redis Cluster 集群方案

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

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

Redis Cluster就是解決以上兩個痛點的解決方案：

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

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

最新評論