Redis主從復制的原理是什么

今天就跟大家聊聊有關Redis主從復制的原理是什么，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

主從復制的作用

• 為數據提供多個副本，實現高可用

• 實現讀寫分離（主節點負責寫數據，從節點負責讀數據，主節點定期把數據同步到從節點保證數據的一致性）

主從復制的方式

• 命令slaveof。
  優點：無需重啟。缺點：不便于管理

  
  

• // 命令行使用slaveof ip port // 使用命令后自身數據會被清空，但取消slave只是停止復制，并不清空

• 修改配置。
  優點：統一配置。缺點：需要重啟

  
  

• // 配置文件中配置slaveof ip portslave-read-only yes //只允許從節點進行讀操作

全量復制

用于初次復制或其它無法進行部分復制的情況，將主節點中的所有數據都發送給從節點，是一個非常重型的操作，當數據量較大時，會對主從節點和網絡造成很大的開銷

全量復制過程：

1. Redis內部會發出一個同步命令，剛開始是Psync命令，Psync ? -1表示要求master主機同步數據

2. 主機會向從機發送run_id和offset，因為slave并沒有對應的 offset，所以是全量復制

3. 從機slave會保存主機master的基本信息

4. 主節點收到全量復制的命令后，執行bgsave（異步執行），在后臺生成RDB文件（快照），并使用一個緩沖區（稱為復制緩沖區）記錄從現在開始執行的所有寫命令

5. 主機發送RDB文件給從機

6. 發送緩沖區數據

7. 刷新舊的數據。從節點在載入主節點的數據之前要先將老數據清除

8. 加載RDB文件將數據庫狀態更新至主節點執行bgsave時的數據庫狀態和緩沖區數據的加載。

全量復制開銷

• 主節點需要bgsave

• RDB文件網絡傳輸占用網絡io

• 從節點要清空數據

• 從節點加載RDB

• 全量復制會觸發從節點AOF重寫

部分復制

部分復制是Redis 2.8以后出現的，用于處理在主從復制中因網絡閃斷等原因造成的數據丟失場景，當從節點再次連上主節點后，如果條件允許，主節點會補發丟失數據給從節點。因為補發的數據遠遠小于全量數據，可以有效避免全量復制的過高開銷，需要注意的是，如果網絡中斷時間過長，造成主節點沒有能夠完整地保存中斷期間執行的寫命令，則無法進行部分復制，仍使用全量復制

部分復制過程：

1. 如果網絡抖動（連接斷開 connection lost）

2. 主機master 還是會寫 repl_back_buffer（復制緩沖區）

3. 從機slave 會繼續嘗試連接主機

4. 從機slave 會把自己當前 run_id 和偏移量傳輸給主機 master，并且執行 pysnc 命令同步

5. 如果master發現你的偏移量是在緩沖區的范圍內，就會返回 continue命令

6. 同步了offset的部分數據，所以部分復制的基礎就是偏移量 offset。

服務器運行ID(run_id)：每個Redis節點(無論主從)，在啟動時都會自動生成一個隨機ID(每次啟動都不一樣)，由40個隨機的十六進制字符組成；run_id用來唯一識別一個Redis節點。 通過info server命令，可以查看節點的run_id。

開發運維常見的問題

1. 讀寫分離

• 復制數據存在延遲（如果從節點發生阻塞）

• 從節點可能發生故障

2. 主從配置不一致

• 例如maxmemory不一致，可能會造成丟失數據

• 例如數據結構優化參數不一致：造成主從內存不一致

3. 規避全量復制

• 第一次全量復制不可避免，所以分片的maxmemory減小，同時選擇在低峰（夜間）時，做全量復制。

• 復制積壓緩沖區不足 增大復制緩沖區配置rel_backlog_size

例如：如果網絡中斷的平均時間是60s，而主節點平均每秒產生的寫命令(特定協議格式)所占的字節數為100KB，則復制積壓緩沖區的平均需求為6MB，保險起見，可以設置為12MB，來保證絕大多數斷線情況都可以使用部分復制。

4. 復制風暴 master節點重啟，master節點生成一份rdb文件，但是要給所有從節點發送rdb文件。對cpu，內存，帶寬都造成很大的壓力

看完上述內容，你們對Redis主從復制的原理是什么有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。