redis——舊版復制

Redis 的復制功能分為同步（sync）和命令傳播（command propagate）兩個操作：

同步操作用于將從服務器的數據庫狀態更新至主服務器當前所處的數據庫狀態。

命令傳播操作用于在主服務器的數據庫狀態被修改， 導致主從服務器的數據庫狀態出現不一致時， 讓主從服務器的數據庫重新回到一致狀態。

同步

當客戶端向從服務器發送?SLAVEOF?命令， 要求從服務器復制主服務器時， 從服務器首先需要執行同步操作， 也即是， 將從服務器的數據庫狀態更新至主服務器當前所處的數據庫狀態。

從服務器對主服務器的同步操作需要通過向主服務器發送?SYNC?命令來完成， 以下是?SYNC?命令的執行步驟：

從服務器向主服務器發送?SYNC?命令。

收到?SYNC?命令的主服務器執行?BGSAVE?命令， 在后臺生成一個 RDB 文件， 并使用一個緩沖區記錄從現在開始執行的所有寫命令。

當主服務器的?BGSAVE?命令執行完畢時， 主服務器會將?BGSAVE?命令生成的 RDB 文件發送給從服務器， 從服務器接收并載入這個 RDB 文件， 將自己的數據庫狀態更新至主服務器執行?BGSAVE?命令時的數據庫狀態。

主服務器將記錄在緩沖區里面的所有寫命令發送給從服務器， 從服務器執行這些寫命令， 將自己的數據庫狀態更新至主服務器數據庫當前所處的狀態。

。

命令傳播

在同步操作執行完畢之后， 主從服務器兩者的數據庫將達到一致狀態， 但這種一致并不是一成不變的 —— 每當主服務器執行客戶端發送的寫命令時， 主服務器的數據庫就有可能會被修改， 并導致主從服務器狀態不再一致。

舉個例子， 假設一個主服務器和一個從服務器剛剛完成同步操作， 它們的數據庫都保存了相同的五個鍵?k1?至?k5

如果這時， 客戶端向主服務器發送命令?DEL?k3?， 那么主服務器在執行完這個?DEL?命令之后， 主從服務器的數據庫將出現不一致： 主服務器的數據庫已經不再包含鍵?k3?， 但這個鍵卻仍然包含在從服務器的數據庫里面

為了讓主從服務器再次回到一致狀態， 主服務器需要對從服務器執行命令傳播操作： 主服務器會將自己執行的寫命令 —— 也即是造成主從服務器不一致的那條寫命令 —— 發送給從服務器執行， 當從服務器執行了相同的寫命令之后， 主從服務器將再次回到一致狀態。

缺陷

。

其中可以明顯看出重新連接主服務器之后，SYNC命令創建包含k1-k10089的RDB文件。而事實上只需要再同步斷線后的k10087-k10089即可。SYNC的“全同步”對于從服務來說是不必要的。

SYNC命令非常消耗資源，原因有三點：

1）主服務器執行BGSAVE命令生成RDB文件，這個生成過程會大量消耗主服務器資源（CPU、內存和磁盤I/O資源）

2）主服務器需要將自己生成的RBD文件發送給從從服務器，這個發送操作會消耗主從服務器大量的網絡資源（帶寬與流量）

3）接收到RDB文件你的從服務器需要載入RDB文件，載入期間從服務器會因為阻塞而導致沒辦法處理命令請求。

Redis 數據庫

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。