1. Redis主從復(fù)制
1.1 Redis主從復(fù)制
Redis主從復(fù)制主要有兩個(gè)角色,主機(jī)(master)對(duì)外提供讀寫(xiě)功能,從機(jī)(slave)對(duì)外只提供讀功能,主機(jī)定期把數(shù)據(jù)同步到從機(jī)上保證數(shù)據(jù)一致性。
Redis主機(jī)數(shù)據(jù)同步到從機(jī)上有兩種方式,一種是全量同步,另一種是增量同步。
主從復(fù)制不會(huì)阻塞master,在數(shù)據(jù)同步時(shí),master還可以繼續(xù)處理客戶(hù)端請(qǐng)求,因?yàn)閞edis會(huì)產(chǎn)生一個(gè)新的進(jìn)程來(lái)解決同步問(wèn)題。
一個(gè)redis也可以是從也可以是主(樹(shù)狀主從),可以減輕主機(jī)壓力。
1.2 Redis主從配置
只需要修改從服務(wù)器上的redis.conf文件:
# slaveof 《masterip》 《masterport》
# 表示當(dāng)前【從服務(wù)器】對(duì)應(yīng)的【主服務(wù)器】的IP是192.168.10.135,端口是6379。
slaveof 192.168.10.135 6379
啟動(dòng)主服務(wù)器 redis-server redis.conf
進(jìn)入從服務(wù)器文件夾,啟動(dòng)從服務(wù)器
查看主服務(wù)器信息:redis-cli -p 6379 info Replication,可以看到有幾個(gè)從服務(wù)器
1.3 實(shí)現(xiàn)原理
redis的主從同步分為兩種,分為全量同步和增量同步。
只有從機(jī)第一次連接上主機(jī)是全量同步。
斷線重連很有可能觸發(fā)全量同步也有可能是增量同步(master判斷runid`是否一致)。
runid
每個(gè)redis服務(wù)器,不論主服務(wù)器還是從服務(wù),都會(huì)有自己的運(yùn)行id。PSYNC runid 這個(gè)命令,runid是指上一次復(fù)制主服務(wù)器的運(yùn)行id,如果沒(méi)有保存這個(gè)id,PSYNC的命令會(huì)使用”P(pán)SYNC ? -1” 這種形式發(fā)送給Master,請(qǐng)求主服務(wù)器進(jìn)行全量復(fù)制。
offset(復(fù)制偏移量)
主服務(wù)器和從服務(wù)器會(huì)分別維護(hù)一個(gè)復(fù)制偏移量,主服務(wù)器每次向從服務(wù)器傳播N個(gè)字節(jié)的數(shù)據(jù)時(shí),就將自己的復(fù)制偏移量的值加上N,從服務(wù)器每次收到主服務(wù)器傳播來(lái)的N個(gè)字節(jié)的數(shù)據(jù)時(shí),就將自己的復(fù)制偏移量值加上N。
復(fù)制積壓緩沖區(qū)
復(fù)制積壓緩沖區(qū)是由主服務(wù)器維護(hù)一個(gè)固定長(zhǎng)度(fixed-size)先進(jìn)先出(FIFO)隊(duì)列,默認(rèn)大小是1MB。它主要的作用就是當(dāng)主服務(wù)器進(jìn)行命令傳播時(shí),不僅將命令發(fā)送給所有從服務(wù)器,還會(huì)將命令入隊(duì)到復(fù)制積壓緩沖區(qū)。如果主服務(wù)器向從服務(wù)器傳播數(shù)據(jù)時(shí)發(fā)生斷線,主服務(wù)器會(huì)將復(fù)制積壓緩沖區(qū)偏移量的所有數(shù)據(jù)都發(fā)送給從服務(wù)器(發(fā)送的是斷線之后的的數(shù)據(jù))。
PSYNC執(zhí)行過(guò)程
1.Slave接受從客戶(hù)端發(fā)送過(guò)來(lái)的SLAVEOF命令。
當(dāng)前服務(wù)器判斷自己是否保存Master runid是否是第一次復(fù)制。
如果是第一次復(fù)制那么當(dāng)前服務(wù)器向Master發(fā)送PSYNC ? -1命令,主動(dòng)請(qǐng)求Master進(jìn)行全量同步。
如果已經(jīng)父之過(guò)Master,那么當(dāng)前從服務(wù)器向Master發(fā)送PSYNC runid offset命令。
Master接收到PSYNC 命令后首先判斷runid是否和本機(jī)的id一致,如果runid和本機(jī)id不一致則返回+FULLRESYNC runid offset命令執(zhí)行全量同步操作,當(dāng)前服務(wù)器會(huì)將runid保存起來(lái),在下次發(fā)送PSUNC時(shí)使用。
如果判斷runid和本機(jī)id一致,Master則會(huì)再次判斷offset偏移量和本機(jī)的偏移量相差有沒(méi)有超過(guò)復(fù)制積壓緩沖區(qū)大小,如果沒(méi)有那么就給Slave發(fā)送CONTINUE,此時(shí)Slave只需要等待Master傳回失去連接期間丟失的命令;
全量同步
Redis的全量同步主要分為三個(gè)階段:
同步快照階段:Master創(chuàng)建并發(fā)送快照給Slave,Slave再入快照并解析。Master同時(shí)將此階段產(chǎn)生的新的命令寫(xiě)入到積壓緩沖區(qū)中。
同步寫(xiě)緩沖階段:Master向Slave同步存儲(chǔ)在緩沖區(qū)的寫(xiě)操作命令。
同步增量階段:Master向SLave同步寫(xiě)操作命令。
增量同步
Redis增量同步主要是指Slave完成初始化開(kāi)始正常工作時(shí),Master發(fā)生的寫(xiě)操作同步到Slave的過(guò)程。
通常情況下,Master沒(méi)執(zhí)行一個(gè)寫(xiě)命令就會(huì)想Slave發(fā)送相同的寫(xiě)命令,然后Slave接受并執(zhí)行。
2. 哨兵(sentinel)機(jī)制
2.1 哨兵機(jī)制介紹
sentinel進(jìn)程是用于監(jiān)控Redis集群中Master主服務(wù)器工作的狀態(tài)。
在Master主服務(wù)器發(fā)生故障的時(shí)候,可以實(shí)現(xiàn)Master和Slave服務(wù)器的切換,保證系統(tǒng)的高可用。
2.2 為什么要有哨兵機(jī)制?
Redis主從復(fù)制的缺點(diǎn):沒(méi)有辦法對(duì)master進(jìn)行動(dòng)態(tài)選舉,需要使用Sentinel機(jī)制完成動(dòng)態(tài)選舉。
2.3 哨兵的作用
監(jiān)控(Monitoring):sentinel會(huì)不斷檢查Master和Slave是否運(yùn)行正常。
提醒(Notification):當(dāng)被監(jiān)控的某個(gè)Redis節(jié)點(diǎn)出現(xiàn)問(wèn)題時(shí), sentinel 可以通過(guò) API向管理員或者其他應(yīng)用程序發(fā)送通知。
自動(dòng)故障轉(zhuǎn)移(Automatic failover):當(dāng)Master不能正常操作時(shí)哨兵會(huì)開(kāi)始一次故障轉(zhuǎn)移。 它會(huì)將失效的Master的其中一個(gè)Slave升級(jí)為新的Master,并讓其他Slave改為復(fù)制新的Master。 當(dāng)客戶(hù)端試圖連接失效的Master時(shí),集群會(huì)向客戶(hù)端顯示新的Master的地址。 Master和Slave切換后,Master的redis.conf、Slave的reids.conf和senisentinel的sentinel.conf配置文件的內(nèi)容都會(huì)相應(yīng)的改變,即,Master主服務(wù)器的redis.conf配置文件中會(huì)多一行slaveof的配置,sentinel.conf的監(jiān)控目標(biāo)會(huì)隨之調(diào)換。
2.4 故障判斷原理分析
每個(gè)sentinel進(jìn)程每秒鐘一次的頻率向整個(gè)集群中Master、Slave以及其它Sentinel進(jìn)程發(fā)送一個(gè)PING命令。
如果一個(gè)實(shí)例(instance)距離最后一次有效回復(fù)PING命令超過(guò)down-after-milliseconds選項(xiàng)所指定的值,這個(gè)實(shí)例會(huì)被sentinel進(jìn)程標(biāo)記為主觀下線(SDOWN)。
如果一個(gè)Master主服務(wù)器被標(biāo)記為主觀下線(SDOWN),則正在監(jiān)視這個(gè)Master主服務(wù)器的所有 Sentinel進(jìn)程要以每秒一次的頻率確認(rèn)Master主服務(wù)器的確進(jìn)入了主觀下線狀態(tài)。
當(dāng)有足夠數(shù)量的 Sentinel進(jìn)程(大于等于配置文件指定的值)在指定的時(shí)間范圍內(nèi)確認(rèn)Master主服務(wù)器進(jìn)入了主觀下線狀態(tài)(SDOWN), 則Master主服務(wù)器會(huì)被標(biāo)記為客觀下線(ODOWN)。
在一般情況下, 每個(gè) Sentinel進(jìn)程會(huì)以每 10 秒一次的頻率向集群中的所有Master主服務(wù)器、Slave從服務(wù)器發(fā)送 INFO 命令。
當(dāng)Master主服務(wù)器被 Sentinel進(jìn)程標(biāo)記為客觀下線(ODOWN)時(shí),Sentinel進(jìn)程向下線的 Master主服務(wù)器的所有 Slave從服務(wù)器發(fā)送 INFO 命令的頻率會(huì)從 10 秒一次改為每秒一次。
若沒(méi)有足夠數(shù)量的 Sentinel進(jìn)程同意 Master主服務(wù)器下線, Master主服務(wù)器的客觀下線狀態(tài)就會(huì)被移除。若 Master主服務(wù)器重新向 Sentinel進(jìn)程發(fā)送 PING 命令返回有效回復(fù),Master主服務(wù)器的主觀下線狀態(tài)就會(huì)被移除。
-
服務(wù)器
+關(guān)注
關(guān)注
13文章
9768瀏覽量
87728 -
Redis
+關(guān)注
關(guān)注
0文章
385瀏覽量
11405
發(fā)布評(píng)論請(qǐng)先 登錄
【經(jīng)驗(yàn)分享】在Omni3576上編譯Redis-8.0.2源碼,并安裝及性能測(cè)試

【幸狐Omni3576邊緣計(jì)算套件試用體驗(yàn)】Redis最新8.0.2版本源碼安裝及性能測(cè)試
利用dockerfile搭建mysql主從集群和redis集群

Redis 再次開(kāi)源!
Java的SPI機(jī)制詳解

Redis實(shí)戰(zhàn)筆記

華為云 Flexus X 加速 Redis 案例實(shí)踐與詳解

Redis Cluster之故障轉(zhuǎn)移

云服務(wù)器 Flexus X 實(shí)例,Docker 集成搭建 Redis 集群

華為云 Flexus 云服務(wù)器 X 實(shí)例:在 openEuler 系統(tǒng)下搭建 MySQL 主從復(fù)制

華為云 Flexus X 輕松實(shí)現(xiàn) Redis 一主多從高效部署

Redis使用重要的兩個(gè)機(jī)制:Reids持久化和主從復(fù)制

評(píng)論