主從同步

• 當(dāng)我們將Redis用于線上環(huán)境，單機肯定是不行的，即使不做集群，我們也應(yīng)該做主從，有了主從，當(dāng)主節(jié)點（master）掛掉時候，讓運維將從節(jié)點（slave）接管，服務(wù)可以繼續(xù)，否則主節(jié)點宕機后重啟恢復(fù)數(shù)據(jù)的一段時間很長，期間無法提供服務(wù)。
• 討論主從同步之前，我們必須先了解一下先到分布式系統(tǒng)理論的基礎(chǔ)-------CAP理論

CAP原理

• CAp原理好比分布式領(lǐng)域的基礎(chǔ)定律，他分別制定如下三個方面
  • C：Consistent，一致性
  • A：Availability，可用性
  • P：Partition tolerance，分區(qū)容錯性
• 分布式系統(tǒng)中我們的機器一般都不可能在同一個機房，因為如果斷電，那就圖團滅了，這就意味著我們需要部署多機房，甚至不同地域，通過網(wǎng)絡(luò)進行通訊，這個網(wǎng)絡(luò)就有斷開的風(fēng)險，這種網(wǎng)絡(luò)斷開的場景就叫網(wǎng)絡(luò)分區(qū)
• 我們通過下圖演示，網(wǎng)絡(luò)分區(qū)時候，兩個分布式節(jié)點之間無法通訊，對一個節(jié)點操作無法同步，所有數(shù)據(jù)一致性無法保證
• 此時要保證分布式節(jié)點數(shù)據(jù)一致，我們只能犧牲可用性，我們先暫停對外服務(wù)，等節(jié)點恢復(fù)，同步完在說。

• 如上圖說明，我們可以總結(jié)CAP原理：當(dāng)網(wǎng)絡(luò)分區(qū)發(fā)生時候，一致性和可用性兩難全。

最終一致性

• Redis主從數(shù)據(jù)是異步同步的，所有分布式Redis系統(tǒng)并不滿足一致性，Client端修改Redis之后會立刻返回，然后主動從網(wǎng)絡(luò)異步同步，所以計算主從網(wǎng)絡(luò)斷開，還是可以對外服務(wù)，所以Redis此時滿足可用性。
• Redis保證最終一致性：從節(jié)點通過異步同步，經(jīng)一段時間后追趕上主節(jié)點，最終主從一直，即使網(wǎng)絡(luò)斷開時候不一致，等恢復(fù)在同步還是最終可以一致。

主從同步與從從同步

• Redis可能有多個從節(jié)點，并不是每個從節(jié)點都和主節(jié)點通訊同步數(shù)據(jù)，因為這樣會導(dǎo)致主節(jié)點壓力過大，從節(jié)點直接直接進行數(shù)據(jù)同步，也可以達到最終一致性，減少主節(jié)點的負擔(dān)。

增量同步

• Redis同步的是指令流，主節(jié)點將對自己狀態(tài)修改的指令記錄在內(nèi)存buffer，異步將buffer中指令同步從節(jié)點，從節(jié)點一邊執(zhí)行同步的指令流來達到主節(jié)點一樣的狀態(tài)，一邊向主節(jié)點反饋自己同步到哪里的偏移量。
• 因為內(nèi)存buffer優(yōu)先，Redis主節(jié)點不能將所有記錄同時放buffer中。Redis內(nèi)存buffer是一個定長換線數(shù)組，容量滿了就覆蓋之前的內(nèi)容。
  
• 問題：如果網(wǎng)絡(luò)不好，從節(jié)點無法段時間同步buffer中數(shù)據(jù)，網(wǎng)絡(luò)恢復(fù)后buffer中可能已經(jīng)被覆蓋了好幾遍了，那么將會丟失很多數(shù)據(jù)，無法通過同步buffer指令進行同步，這個時候，需要用到更加復(fù)雜的同步機制----快照同步。

快照同步

• 快照同步恒耗時，好資源

在主節(jié)點執(zhí)行bgsave，將當(dāng)前內(nèi)存數(shù)據(jù)load到磁盤快照文件

將快照文件通過網(wǎng)絡(luò)傳輸?shù)綇墓?jié)點

從節(jié)點接收快照文件后，先清空內(nèi)存，然后立即執(zhí)行一次全量加載

加載完快照后繼續(xù)增量同步buffer數(shù)據(jù)。

• 問題： 整個快照同步過程，主節(jié)點的增量信息還是通過復(fù)制buffer，如果快照同步時間太久，導(dǎo)致buffer的復(fù)制還是被覆蓋，這樣會導(dǎo)致快照同步完成后還是無法增量復(fù)制，就會再次發(fā)起快照同步，依次死循環(huán)。
  
• 解決方法，將buffer的大小配置一個合理的大小，避免快照復(fù)制的死循環(huán)。

無盤復(fù)制

• 因為bgsave的時候，進行恒耗時的文件IO，在非SSD磁盤存儲時候，快照同步會對系統(tǒng)負載產(chǎn)生較大影響。
• Redis同步方法還有另一個方式，無盤復(fù)制：
  • 在生成快照的時候就是遍歷主節(jié)點的一個過程，主節(jié)點一邊遍歷內(nèi)存，一邊將序列化后的內(nèi)容直接通過socket發(fā)送到從節(jié)點，從節(jié)點將接受到內(nèi)容存儲到磁盤文件，在進行一次性加載。

更變態(tài)的方式

• Redis的主從復(fù)制是異步，我們可以通過wait指令，讓異步變同步，確保強一致性。如下

新docker-redis:0>wait 1 10 "0"

• wait命令提供兩個參數(shù)，第一個需要同步的從節(jié)點數(shù)量N，第二個時間T，毫秒為單位，如下含義
  • wait指令之前的所有操作同步到N個節(jié)點，最多等待時間t，如果t=0，表示無線等待直到完成。
  • 如果出現(xiàn)網(wǎng)絡(luò)分區(qū)，wait第二個參數(shù)時間t=0，主從同步無法繼續(xù)進行，wati指令永遠阻塞，Redis喪失可用性。

上一篇：Redis存儲優(yōu)化–小對象壓縮

下一篇：Redis服務(wù)信息–Info指令

總結(jié)

以上是生活随笔為你收集整理的Redis高可用基石--主从同步的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。