redis的四種模式：單例模式；主從模式；哨兵模式，集群模式 

一、主從模式

單例模式雖然操作簡單，但是不具備高可用

缺點：

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

解決辦法：

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

 優(yōu)點

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

缺點

master掛了整個Redis將失去寫操作的能力，僅具備讀操作，需要運維半夜爬起來手動升級，中間的請求失敗數(shù)據(jù)丟失無法容忍。

解決辦法

可以有一種方式自動升級slave為master      ------【哨兵模式】

1.1主從復(fù)制

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

1.1.1 復(fù)制原理

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

1.1.1.1 全量復(fù)制

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

1.1.1.2 增量復(fù)制

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

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

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

1.2 讀寫分離 ;  

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

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

1.3 主要作用

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

二、主從的搭建具體操作         

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

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

最新評論