redis的四種模式：?jiǎn)卫Ｊ?；主從模式；哨兵模式，集群模?nbsp;

一、主從模式

單例模式雖然操作簡(jiǎn)單，但是不具備高可用

缺點(diǎn)：

• 單點(diǎn)的宕機(jī)引來(lái)的服務(wù)的災(zāi)難、數(shù)據(jù)丟失
• 單點(diǎn)服務(wù)器內(nèi)存瓶頸，無(wú)法無(wú)限縱向擴(kuò)容

解決辦法：

單節(jié)點(diǎn)宕機(jī)，可以由其他節(jié)點(diǎn)暫時(shí)接替，宕機(jī)的慢慢排查，也就是主從模式

 優(yōu)點(diǎn)

有了主從，提高了Redis整體的可用性，當(dāng)主節(jié)點(diǎn)（master）掛了，可以把從節(jié)點(diǎn)（slave）手動(dòng)升級(jí)為主節(jié)點(diǎn)繼續(xù)服務(wù)。 

缺點(diǎn)

master掛了整個(gè)Redis將失去寫操作的能力，僅具備讀操作，需要運(yùn)維半夜爬起來(lái)手動(dòng)升級(jí)，中間的請(qǐng)求失敗數(shù)據(jù)丟失無(wú)法容忍。

解決辦法

可以有一種方式自動(dòng)升級(jí)slave為master      ------【哨兵模式】

1.1主從復(fù)制

從一臺(tái)Redis服務(wù)器的數(shù)據(jù)（主節(jié)點(diǎn)master），復(fù)制到其他Redis服務(wù)器（從節(jié)點(diǎn)slave）。數(shù)據(jù)復(fù)制單向，只能由主節(jié)點(diǎn)到從節(jié)點(diǎn)，master可讀可寫，slave只可讀不可寫；默認(rèn)每臺(tái)Redis服務(wù)器都是主節(jié)點(diǎn)，從節(jié)點(diǎn)需要在配置文件中單獨(dú)配置，才會(huì)從默認(rèn)的主節(jié)點(diǎn)變成從節(jié)點(diǎn)。一個(gè)主節(jié)點(diǎn)可以有0個(gè)或多個(gè)從節(jié)點(diǎn)，但每個(gè)從節(jié)點(diǎn)只能有一個(gè)主節(jié)點(diǎn)。

1.1.1 復(fù)制原理

slave第一次連接master，一定會(huì)執(zhí)行一次全量復(fù)制
全量復(fù)制數(shù)據(jù)量過(guò)大，會(huì)造成很大的網(wǎng)絡(luò)開(kāi)銷，消耗CPU/內(nèi)存/硬盤IO
增量復(fù)制用于處理在主從復(fù)制中因網(wǎng)絡(luò)等數(shù)據(jù)丟失的場(chǎng)景，當(dāng)slave再次連接上master，并且就是原來(lái)的master，如果條件允許，master補(bǔ)發(fā)數(shù)據(jù)給slave，補(bǔ)發(fā)數(shù)據(jù)量小，避免全量復(fù)制的開(kāi)銷（到底能不能復(fù)制還要看offset和buffer的情況）
如果slave再次連上的master是新選舉的master，那么只能進(jìn)行全量復(fù)制
早期的redis只有全量復(fù)制，增量復(fù)制是對(duì)全量復(fù)制的重大優(yōu)化，盡量采用2.8以上版本

1.1.1.1 全量復(fù)制

• slave給master發(fā)一個(gè)sync同步命令
• master通過(guò)bgsave命令fork子進(jìn)程，持久化生成RDB文件
• master通過(guò)網(wǎng)絡(luò)將RDB文件傳給slave
• slave清空老數(shù)據(jù)，載入新的RDB文件，此時(shí)slave阻塞，無(wú)法響應(yīng)客戶端，專心復(fù)制

1.1.1.2 增量復(fù)制

• 主從節(jié)點(diǎn)各自維護(hù)自己的復(fù)制偏移量offset，主節(jié)點(diǎn)寫入命令時(shí)，offset=offset+命令字節(jié)長(zhǎng)度；從節(jié)點(diǎn)收到主節(jié)點(diǎn)命令也會(huì)相應(yīng)增加自己的offset，并同步給主節(jié)點(diǎn)。主節(jié)點(diǎn)同時(shí)維護(hù)自己的offset和從節(jié)點(diǎn)的offset，以此來(lái)判斷主從節(jié)點(diǎn)數(shù)據(jù)是否一致。
• 主節(jié)點(diǎn)指令記錄在本地buffer（緩沖區(qū)），異步將buffer同步給從節(jié)點(diǎn)
• 若網(wǎng)絡(luò)不好，同步速度慢了，buffer滿了就會(huì)從頭開(kāi)始覆蓋前面的內(nèi)容，于是無(wú)法增量復(fù)制，必須全量復(fù)制

 # 主從原理
1. 副本庫(kù)通過(guò)slaveof 127.0.0.1 6379命令,連接主庫(kù),并發(fā)送SYNC給主庫(kù) 
2. 主庫(kù)收到SYNC,會(huì)立即觸發(fā)BGSAVE,后臺(tái)保存RDB,發(fā)送給副本庫(kù)
3. 副本庫(kù)接收后會(huì)應(yīng)用RDB快照
4. 主庫(kù)會(huì)陸續(xù)將中間產(chǎn)生的新的操作,保存并發(fā)送給副本庫(kù)
5. 到此,我們主復(fù)制集就正常工作了
6. 再此以后,主庫(kù)只要發(fā)生新的操作,都會(huì)以命令傳播的形式自動(dòng)發(fā)送給副本庫(kù).
7. 所有復(fù)制相關(guān)信息,從info信息中都可以查到.即使重啟任何節(jié)點(diǎn),他的主從關(guān)系依然都在.
8. 如果發(fā)生主從關(guān)系斷開(kāi)時(shí),從庫(kù)數(shù)據(jù)沒(méi)有任何損壞,在下次重連之后,從庫(kù)發(fā)送PSYNC給主庫(kù)
9. 主庫(kù)只會(huì)將從庫(kù)缺失部分的數(shù)據(jù)同步給從庫(kù)應(yīng)用,達(dá)到快速恢復(fù)主從的目的

# 主庫(kù)是否要開(kāi)啟持久化（一般情況要開(kāi)啟）
如果不開(kāi)有可能，主庫(kù)重啟操作，造成所有主從數(shù)據(jù)丟失！

1.2 讀寫分離 ;  

大部分情況都是讀操作，將讀操作放在從節(jié)點(diǎn)，寫操作放在主節(jié)點(diǎn)，減緩服務(wù)器壓力；同時(shí)一些執(zhí)行耗時(shí)比較久的操作也可以放在一臺(tái)從節(jié)點(diǎn)完成，例如keys、sort。（什么時(shí)候連主節(jié)點(diǎn)寫，什么時(shí)候連從節(jié)點(diǎn)讀，由客戶端自己控制）

最低配：一主二從，當(dāng)主節(jié)點(diǎn)宕機(jī)后，其中一個(gè)從節(jié)點(diǎn)升級(jí)為主節(jié)點(diǎn)，還能剩一個(gè)從節(jié)點(diǎn)。

1.3 主要作用

• 數(shù)據(jù)冗余：熱備份，持久化另一種方式
• 故障恢復(fù)：master宕機(jī)，快速升級(jí)slave為master
• 讀寫分離：master寫，slave，提高服務(wù)器負(fù)載能力，同時(shí)可以根據(jù)需求添加slave
• 負(fù)載均衡：配合讀寫分離，讀多寫少場(chǎng)景，多個(gè)slave分擔(dān)負(fù)載，大大提高并發(fā)
• 高可用基石：是實(shí)現(xiàn)哨兵和集群的基礎(chǔ)
   

二、主從的搭建具體操作         

# 前置條件1 ：至少需要兩臺(tái)機(jī)器--》在一臺(tái)機(jī)器運(yùn)行兩個(gè)redis實(shí)例
# 前置條件2：輔助配置（主從數(shù)據(jù)一致性配置）
min-slaves-to-write 1
min-slaves-max-lag 3
#那么在從服務(wù)器的數(shù)量少于1個(gè)，或者三個(gè)從服務(wù)器的延遲（lag）值都大于或等于3秒時(shí)，主服務(wù)器將拒絕執(zhí)行寫命令
# 方式一：
# 1 6380是從，6379是主
# 2 啟動(dòng)器兩臺(tái)實(shí)例
# 3 搭建主從關(guān)系
	-在從庫(kù)上：slaveof ip port
  slaveof 127.0.0.1 6379
# 4 斷開(kāi)主從關(guān)系
	-在從庫(kù)上：slaveof no one
# 方式二：配置文件方式
# 在從庫(kù)的配置文件中：
slaveof 127.0.0.1 6379
slave-read-only yes
# 使用info查看主從關(guān)系

到此這篇關(guān)于redis主從復(fù)制的原理及實(shí)現(xiàn)的文章就介紹到這了,更多相關(guān)redis主從復(fù)制內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論