主從同步

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

CAP原理

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

• 如上圖說明，我們可以總結CAP原理：當網絡分區發生時候，一致性和可用性兩難全。

最終一致性

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

主從同步與從從同步

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

增量同步

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

快照同步

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

在主節點執行bgsave，將當前內存數據load到磁盤快照文件

將快照文件通過網絡傳輸到從節點

從節點接收快照文件后，先清空內存，然后立即執行一次全量加載

加載完快照后繼續增量同步buffer數據。

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

無盤復制

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

更變態的方式

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

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

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

上一篇：Redis存儲優化–小對象壓縮

下一篇：Redis服務信息–Info指令

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。