Redis超詳細(xì)講解高可用主從復(fù)制基礎(chǔ)與哨兵模式方案
高可用基礎(chǔ)---主從復(fù)制
Redis的復(fù)制功能是支持將多個數(shù)據(jù)庫之間進(jìn)行數(shù)據(jù)同步,主數(shù)據(jù)庫可以進(jìn)行讀寫操作。當(dāng)主數(shù)據(jù)庫數(shù)據(jù)發(fā)生改變時會自動同步到從數(shù)據(jù)庫,從數(shù)據(jù)庫一般是只讀的,會接收注數(shù)據(jù)庫同步過來的數(shù)據(jù)。
一個主數(shù)據(jù)庫可以有多個從數(shù)據(jù)庫,而一個從數(shù)據(jù)庫只能有一個主數(shù)據(jù)庫,默認(rèn)情況下,每臺服務(wù)器都是主節(jié)點,可以通過配置來設(shè)置Redis節(jié)點稱為從數(shù)據(jù)庫。

主從復(fù)制的原理
- 當(dāng)啟動一個從節(jié)點時,它會發(fā)送一個 PSYNC 命令(分為全量復(fù)制和部分復(fù)制)給主節(jié)點;
- 如果是從節(jié)點初次連接到主節(jié)點,那么會觸發(fā)一次全量復(fù)制。此時主節(jié)點會啟動一個后臺線程,開始生成一份 RDB 快照文件;
- 同時還會將從客戶端 client 新收到的所有寫命令緩存在內(nèi)存中。RDB 文件生成完畢后, 主節(jié)點會將RDB文件發(fā)送給從節(jié)點,從節(jié)點會先將RDB文件寫入本地磁盤,然后再從本地磁盤加載到內(nèi)存中;
- 接著主節(jié)點會將內(nèi)存中緩存的寫命令發(fā)送到從節(jié)點,從節(jié)點同步這些數(shù)據(jù);
- 如果從節(jié)點跟主節(jié)點之間網(wǎng)絡(luò)出現(xiàn)故障,連接斷開了,會自動重連,連接之后主節(jié)點僅會將部分缺失的數(shù)據(jù)同步給從節(jié)點。
主從復(fù)制配置
默認(rèn)情況下,每個節(jié)點都是主節(jié)點,只需要配置從節(jié)點。可以通過復(fù)制Redis.conf配置文件,修改主要信息,例如:端口號、pid名稱、log文件名稱、dump.rdb名稱等,可以修改配置,配置就永久有效,也可以通過命令形式做處理。
命令:info replication:查看當(dāng)前庫信息

命令:slaveof ip port :在從服務(wù)器上執(zhí)行名,給定主服務(wù)器的端口和IP
命令:Slave no one :可以讓從節(jié)點恢復(fù)為主機(jī)
示例
啟動三個Redis服務(wù),給定端口6380、6381、6382。給定6380為主節(jié)點
1、創(chuàng)建Redis實例
nohup redis-server --port 6380 >> /usr/local/redis/data/log/6380.log 2>&1 & nohup redis-server --port 6381 >> /usr/local/redis/data/log/6381.log 2>&1 & nohup redis-server --port 6382 >> /usr/local/redis/data/log/6382.log 2>&1 & [root@redis ~]# ps -ef |grep redis root 16421 16314 0 03:01 pts/1 00:00:00 redis-server *:6380 root 16427 16314 0 03:01 pts/1 00:00:00 redis-server *:6381 root 16431 16314 0 03:01 pts/1 00:00:00 redis-server *:6382
2、連接數(shù)據(jù)庫并設(shè)置主從復(fù)制
Gong-Dezhe-MBP:log gongdezhe$ redis-cli -p 6380 127.0.0.1:6380> ? Gong-Dezhe-MBP:~ gongdezhe$ redis-cli -p 6381 127.0.0.1:6381> slaveof 127.0.0.1 6380 OK ? Gong-Dezhe-MBP:~ gongdezhe$ redis-cli -p 6382 127.0.0.1:6382> slaveof 127.0.0.1 6380 OK
主從配置完成后,主節(jié)點信息:

從節(jié)點信息:

數(shù)據(jù)同步測試:


高可用方案---哨兵模式sentinel
搭建好的主從復(fù)制方案可以達(dá)到數(shù)據(jù)同步目的,但是當(dāng)主服務(wù)器宕機(jī)后,需要手動將一個從服務(wù)器切換為主服務(wù)器,這個過程需要人工干預(yù),同時切換會導(dǎo)致Redis的寫入功能不可用。需要一種能夠自動完成master故障發(fā)現(xiàn)并能夠?qū)⒁粋€Slave切換為master,這個時候需要哨兵sentinel模式,哨兵模式可以自動切換主從節(jié)點。
哨兵模式簡介
sentinel是官方提供的高可用方案,其原理是哨兵通過發(fā)送命令,等待Redis服務(wù)器響應(yīng),從而監(jiān)控運行的多個Redis實例。同時 sentinel是一個分布式系統(tǒng),可以在一個架構(gòu)中運行多個Sentinel進(jìn)程。所以監(jiān)控同一個Master的Sentinel會自動連接,組成一個分布式的Sentinel網(wǎng)絡(luò),互相通信并交換彼此關(guān)于被監(jiān)視服務(wù)器信息。

sentinel工作過程:
- 通過向主服務(wù)器和從服務(wù)器發(fā)送ping命令,讓服務(wù)器返回運行狀態(tài)。
- 當(dāng)哨兵監(jiān)測到master宕機(jī),會自動將一個slave切換成master,然后通過發(fā)布訂閱模式通知其他的從服務(wù)器,修改配置文件,讓它們切換主機(jī)。
關(guān)于sentinel的三個定時任務(wù):
- 每1秒每個sentinel對其他sentinel和redis節(jié)點執(zhí)行ping操作,心跳檢測。
- 每10秒每個sentinel會對master和slave執(zhí)行info命令,目的是發(fā)現(xiàn)slave結(jié)點,確定主從關(guān)系。
- 每2秒每個sentinel通過master節(jié)點的channel交換信息(pub/sub)。master節(jié)點上有一個發(fā)布訂閱的頻道(sentinel:hello)。sentinel節(jié)點通過sentinel:hello頻道進(jìn)行信息交換(對節(jié)點的"看法"和自身的信息),達(dá)成共識。
哨兵工作原理
- 每個Sentinel以每秒鐘一次的頻率向它所知道的Master,Slave以及其他 Sentinel實例發(fā)送一個 PING命令。
- 如果一個實例距離最后一次有效回復(fù) PING 命令的時間超過指定值, 則這個實例會被 Sentine 標(biāo)記為主觀下線。
- 如果一個Master被標(biāo)記為主觀下線,則正在監(jiān)視這個Master的所有 Sentinel要以每秒一次的頻率確認(rèn)Master是否真正進(jìn)入主觀下線狀態(tài)。
- 當(dāng)有足夠數(shù)量的 Sentinel(大于等于配置文件指定值)在指定的時間范圍內(nèi)確認(rèn)Master的確進(jìn)入了主觀下線狀態(tài), 則Master會被標(biāo)記為客觀下線 。若沒有足夠數(shù)量的 Sentinel同意 Master 已經(jīng)下線, Master 的客觀下線狀態(tài)就會被解除。若 Master重新向 Sentinel 的 PING 命令返回有效回復(fù), Master 的主觀下線狀態(tài)就會被移除。
- 哨兵節(jié)點會選舉出哨兵 leader,負(fù)責(zé)故障轉(zhuǎn)移的工作。
- 哨兵 leader 會推選出某個表現(xiàn)良好的從節(jié)點成為新的主節(jié)點,然后通知其他從節(jié)點更新主節(jié)點信息。
然而一個哨兵進(jìn)程對Redis服務(wù)器進(jìn)行監(jiān)控,可能會出現(xiàn)問題,為此,我們可以使用多個哨兵進(jìn)行監(jiān)控,各個哨兵之間還會進(jìn)行監(jiān)控,這樣就形成了多哨兵模式。

哨兵故障修復(fù)原理
1.主觀下線:
當(dāng)主服務(wù)器發(fā)生故障時,此時一個sentinel發(fā)現(xiàn)了故障,系統(tǒng)并不會馬上進(jìn)行failover過程(這個現(xiàn)象稱為主觀下線),它會向網(wǎng)絡(luò)中的其他Sentinel進(jìn)行確認(rèn)。
2.客觀下線:
接著其他Sentinel也陸續(xù)發(fā)現(xiàn)故障,這個時候其中一個Sentinel就會發(fā)起投票。一定數(shù)量的哨兵(在配置文件中指定)確認(rèn)Master被標(biāo)記為主觀下線,此時將Master標(biāo)記為客觀下線。
3.sentinel的leader選舉:
要想完成故障切換(將故障master剔除,并將一個slave提升為master)就必須先選舉一個leader。最先發(fā)現(xiàn)故障的sentinel向其他哨兵發(fā)起請求成為leader,其他哨兵在沒有同意別的哨兵的leader請求時,就會把票投給該sentinel。當(dāng)半數(shù)以上的sentinel投票通過后就認(rèn)定該sentinel為leader。接下來的故障切換有該leader完成。
4.master選舉:
leader選好后將故障master剔除,從slave中挑選一個成為master。遵照的原則如下:
- slave的優(yōu)先級
- slave從master那同步的數(shù)據(jù)量,那個slave多就優(yōu)先。
5.新Master再通過發(fā)布訂閱模式通知所有sentinel更新監(jiān)控主機(jī)信息。
6.故障的主服務(wù)器修復(fù)后將成為從服務(wù)器繼續(xù)工作。
示例:故障發(fā)生時:

故障切換:

Master重新上線后:

sentinel.conf配置講解
配置哨兵配置文件 sentinel.conf
#Sentinel monitor <name> <ip> <port> <quorum>
- name :redis主服務(wù)名稱,可以自行命名,但是在一個sentinel網(wǎng)絡(luò)中,一個redis主服務(wù)只能有一個名稱;
- ip和port :redis主服務(wù)的IP地址和端口號.
- quorum :表示要將這個主服務(wù)器判斷為失效并下線至少需要2個sentinel同意
- protected-mode :關(guān)閉保護(hù)模式(默認(rèn)情況下,redis node和sentinel的protected-mode都是yes,在搭建集群時,若想從遠(yuǎn)程連接redis集群,需要將redis node和sentinel的protected-mode修改為no,若只修改redis node,從遠(yuǎn)程連接sentinel后,依然是無法正常使用的,且sentinel的配置文件中沒有protected-mode配置項,需要手工添加。依據(jù)redis文檔的說明,若protected-mode設(shè)置為no后,需要增加密碼證或是IP限制等保護(hù)機(jī)制,否則是極度危險的。)




哨兵模式的優(yōu)點
- 哨兵集群、基于主從復(fù)制模式,所有的主從復(fù)制優(yōu)點,它會有
- 主從可以切換,故障可以轉(zhuǎn)移,系統(tǒng)的可用性會更好
- 哨兵模式就是主從模式的升級,手動轉(zhuǎn)自動,更加健壯
哨兵模式的缺點
- Redis不好在線擴(kuò)展,集群容量一旦到達(dá)上限,在線擴(kuò)容十分麻煩
- 實現(xiàn)哨兵模式的配置很麻煩,里面有很多選擇
到此這篇關(guān)于Redis超詳細(xì)講解高可用主從復(fù)制基礎(chǔ)與哨兵模式方案的文章就介紹到這了,更多相關(guān)Redis 高可用內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
Redis數(shù)據(jù)庫的使用場景介紹(避免誤用Redis)
這篇文章主要介紹了Redis數(shù)據(jù)庫的使用場景介紹(避免誤用Redis),本文用簡要的語言總結(jié)了Redis數(shù)據(jù)庫的適應(yīng)場合,人而避免錯誤的使用它而產(chǎn)生昂貴的維護(hù)代價,需要的朋友可以參考下2015-03-03
redis數(shù)據(jù)結(jié)構(gòu)之壓縮列表
這篇文章主要介紹了redis數(shù)據(jù)結(jié)構(gòu)之壓縮列表,壓縮列表是列表list和hash數(shù)據(jù)結(jié)構(gòu)的底層實現(xiàn)之一,是redis為了節(jié)約內(nèi)存而開發(fā)的,由一系列特殊編碼的連續(xù)內(nèi)存塊組成的順序型數(shù)據(jù)結(jié)構(gòu),下面詳細(xì)內(nèi)容需要的小伙伴可以參考一下2022-03-03
Redis內(nèi)存空間占用及避免數(shù)據(jù)丟失的方法
在現(xiàn)代的互聯(lián)網(wǎng)應(yīng)用中,Redis作為一種高性能的內(nèi)存數(shù)據(jù)庫,被廣泛應(yīng)用于緩存、會話管理和消息隊列等場景,然而,Redis的內(nèi)存資源是有限的,過多的內(nèi)存占用可能會導(dǎo)致數(shù)據(jù)丟失所以本文將給大家介紹一下Redis內(nèi)存空間占用及避免數(shù)據(jù)丟失的方法2023-08-08
深入了解Redis連接數(shù)問題的現(xiàn)象和解法
一般情況?Redis?連接數(shù)問題并不常見,但是當(dāng)你業(yè)務(wù)服務(wù)增加、對?Redis?的依賴持續(xù)增強的過程中,可能會遇到很多?Redis?的問題,這個時候,Redis?連接數(shù)可能就成了一個常見的問題,在本章節(jié),希望能夠帶大家了解Redis連接數(shù)問題的現(xiàn)象和解法,需要的朋友可以參考下2023-12-12
Redis 通過 RDB 方式進(jìn)行數(shù)據(jù)備份與還原的方法
這篇文章主要介紹了Redis 通過 RDB 方式進(jìn)行數(shù)據(jù)備份與還原,本文給大家介紹的非常詳細(xì),對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值,需要的朋友可以參考下2021-03-03

