Redis高可用梳理詳解
為什么要有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)文章希望大家以后多多支持腳本之家！
相關(guān)文章
Redis配置ACL訪問控制列表的實(shí)現(xiàn)
配置Redis的ACL（訪問控制列表）涉及創(chuàng)建和管理用戶、設(shè)置用戶的權(quán)限,并確保用戶只能執(zhí)行被允許的命令和訪問被允許的鍵,本文將詳細(xì)介紹通過配置文件和動態(tài)命令來配置Redis的ACL,感興趣的可以了解一下2025-10-10
Redis Caffeine多級緩存框架的實(shí)現(xiàn)
本文主要介紹了Redis Caffeine多級緩存框架的實(shí)現(xiàn),文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2026-04-04
redis設(shè)置密碼并修改查看的幾種實(shí)現(xiàn)過程
這篇文章主要介紹了redis設(shè)置密碼并修改查看的幾種實(shí)現(xiàn)過程,具有很好的參考價(jià)值,希望對大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2026-06-06
有很多基于Redis實(shí)現(xiàn)的分布式鎖方案或者庫，但是有些庫并沒有解決分布式環(huán)境下的一些問題陷阱，這篇文章主要介紹了Redis分布式鎖存在的問題,需要的朋友可以參考下2022-12-12
這篇文章主要介紹了Redis客戶端及服務(wù)端的安裝教程,本文給大家介紹的非常詳細(xì)，對大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值，需要的朋友可以參考下2020-11-11
簡單粗暴的Redis數(shù)據(jù)備份和恢復(fù)方法
這里我們來講解一個(gè)簡單粗暴的Redis數(shù)據(jù)備份和恢復(fù)方法,有一個(gè)在不同主機(jī)上遷移Redis數(shù)據(jù)的示例,還有一個(gè)備份腳本實(shí)現(xiàn)的關(guān)鍵點(diǎn)提示,一起來看一下:2016-06-06
redis列表類型_動力節(jié)點(diǎn)Java學(xué)院整理
這篇文章主要為大家詳細(xì)介紹了redis列表類型的相關(guān)資料，具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下2017-08-08
這篇文章主要為大家介紹了redis?key鍵過期刪除策略及淘汰機(jī)制探究,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2023-11-11
這篇文章主要介紹了redis中的常用5大數(shù)據(jù)類型,具有很好的參考價(jià)值,希望對大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2024-04-04
如何使用redis中的zset實(shí)現(xiàn)滑動窗口限流
滑動窗口限流是一種常見的流量控制方法，它限制了在一定時(shí)間窗口內(nèi)的請求數(shù)量，下面是使用Redis ZSet實(shí)現(xiàn)滑動窗口限流的一個(gè)簡單示例,需要的朋友可以參考下2023-09-09