主從複製的方式
- 命令slaveof。
優點：無需重啓。缺點：不便於管理
// 命令行使用
slaveof ip port // 使用命令後自身數據會被清空，但取消slave只是停止複製，並不清空
- 修改配置。
優點：統一配置。缺點：需要重啓
// 配置文件中配置
slaveof ip port
slave-read-only yes //只允許從節點進行讀操作
全量複製
用於初次複製或其它無法進行部分複製的情況，將主節點中的所有數據都發送給從節點，是一個非常重型的操作，當數據量較大時，會對主從節點和網絡造成很大的開銷
Redis全量複製過程
全量複製過程：
- Redis內部會發出一個同步命令，剛開始是Psync命令，Psync ? -1表示要求master主機同步數據
- 主機會向從機發送run_id和offset，因爲slave並沒有對應的 offset，所以是全量複製
- 從機slave會保存主機master的基本信息
- 主節點收到全量複製的命令後，執行bgsave（異步執行），在後臺生成RDB文件（快照），並使用一個緩衝區（稱爲複製緩衝區）記錄從現在開始執行的所有寫命令
- 主機發送RDB文件給從機
- 發送緩衝區數據
- 刷新舊的數據。從節點在載入主節點的數據之前要先將老數據清除
- 加載RDB文件將數據庫狀態更新至主節點執行bgsave時的數據庫狀態和緩衝區數據的加載。
全量複製開銷
- 主節點需要bgsave
- RDB文件網絡傳輸佔用網絡io
- 從節點要清空數據
- 從節點加載RDB
- 全量複製會觸發從節點AOF重寫
部分複製
部分複製是Redis 2.8以後出現的，用於處理在主從複製中因網絡閃斷等原因造成的數據丟失場景，當從節點再次連上主節點後，如果條件允許，主節點會補發丟失數據給從節點。因爲補發的數據遠遠小於全量數據，可以有效避免全量複製的過高開銷，需要注意的是，如果網絡中斷時間過長，造成主節點沒有能夠完整地保存中斷期間執行的寫命令，則無法進行部分複製，仍使用全量複製
Redis部分複製過程
部分複製過程：
- 如果網絡抖動（連接斷開 connection lost）
- 主機master 還是會寫 repl_back_buffer（複製緩衝區）
- 從機slave 會繼續嘗試連接主機
- 從機slave 會把自己當前 run_id 和偏移量傳輸給主機 master，並且執行 pysnc 命令同步
- 如果master發現你的偏移量是在緩衝區的範圍內，就會返回 continue命令
- 同步了offset的部分數據，所以部分複製的基礎就是偏移量 offset。
服務器運行ID(run_id)：每個Redis節點(無論主從)，在啓動時都會自動生成一個隨機ID(每次啓動都不一樣)，由40個隨機的十六進制字符組成；run_id用來唯一識別一個Redis節點。 通過info server命令，可以查看節點的run_id。
Redis大概主從同步是怎麼實現的？
全量同步：
master服務器會開啓一個後臺進程用於將redis中的數據生成一個rdb文件，與此同時，服務器會緩存所有接收到的來自客戶端的寫命令（包含增、刪、改），當後臺保存進程
處理完畢後，會將該rdb文件傳遞給slave服務器，而slave服務器會將rdb文件保存在磁盤並通過讀取該文件將數據加載到內存，在此之後master服務器會將在此期間緩存的
命令通過redis傳輸協議發送給slave服務器，然後slave服務器將這些命令依次作用於自己本地的數據集上最終達到數據的一致性。
部分同步：
從redis 2.8版本以前，並不支持部分同步，當主從服務器之間的連接斷掉之後，master服務器和slave服務器之間都是進行全量數據同步，但是從redis 2.8開
始，即使主從連接中途斷掉，也不需要進行全量同步，因爲從這個版本開始融入了部分同步的概念。部分同步的實現依賴於在master服務器內存中給每個slave服務器維護了
一份同步日誌和同步標識，每個slave服務器在跟master服務器進行同步時都會攜帶自己的同步標識和上次同步的最後位置。當主從連接斷掉之後，slave服務器隔斷時間
（默認1s）主動嘗試和master服務器進行連接，如果從服務器攜帶的偏移量標識還在master服務器上的同步備份日誌中，那麼就從slave發送的偏移量開始繼續上次的同步
操作，如果slave發送的偏移量已經不再master的同步備份日誌中（可能由於主從之間斷掉的時間比較長或者在斷掉的短暫時間內master服務器接收到大量的寫操作），則
必須進行一次全量更新。在部分同步過程中，master會將本地記錄的同步備份日誌中記錄的指令依次發送給slave服務器從而達到數據一致。
無磁盤複製
|
1 2 3 4 |
|