RDB 方式與 AOF 方式的優勢對比

首先我們來看一看官方對于兩種方式的優點描述，并做個對比，然后再看一看兩種方式的缺點描述。

RDB 方式的優點

RDB 是一個非常緊湊的文件,它保存了某個時間點的數據集,非常適用于數據集的備份,比如你可以在每個小時報保存一下過去24小時內的數據,同時每天保存過去30天的數據,這樣即使出了問題你也可以根據需求恢復到不同版本的數據集。

RDB 是一個緊湊的單一文件,很方便傳送到另一個遠端數據中心，非常適用于災難恢復。

RDB 在保存 RDB 文件時父進程唯一需要做的就是 fork 出一個子進程,接下來的工作全部由子進程來做，父進程不需要再做其他 IO 操作，所以 RDB 持久化方式可以最大化 Redis 的性能。

與AOF相比,在恢復大的數據集的時候，RDB 方式會更快一些。

當 Redis 需要保存 dump.rdb 文件時， 服務器執行以下操作:

Redis 調用forks. 同時擁有父進程和子進程。

子進程將數據集寫入到一個臨時 RDB 文件中。

當子進程完成對新 RDB 文件的寫入時，Redis 用新 RDB 文件替換原來的 RDB 文件，并刪除舊的 RDB 文件。

這種工作方式使得 Redis 可以從寫時復制（copy-on-write）機制中獲益。

AOF 方式的優點

使用AOF 會讓你的Redis更加耐久:

你可以使用不同的 fsync 策略：無 fsync、每秒 fsync 、每次寫的時候 fsync .使用默認的每秒 fsync 策略, Redis 的性能依然很好( fsync 是由后臺線程進行處理的,主線程會盡力處理客戶端請求),一旦出現故障，你最多丟失1秒的數據。

AOF文件是一個只進行追加的日志文件,所以不需要寫入seek,即使由于某些原因(磁盤空間已滿，寫的過程中宕機等等)未執行完整的寫入命令,你也也可使用redis-check-aof工具修復這些問題。

Redis 可以在 AOF 文件體積變得過大時，自動地在后臺對 AOF 進行重寫： 重寫后的新 AOF 文件包含了恢復當前數據集所需的最小命令集合。 整個重寫操作是絕對安全的，因為 Redis 在創建新 AOF 文件的過程中，會繼續將命令追加到現有的 AOF 文件里面，即使重寫過程中發生停機，現有的 AOF 文件也不會丟失。 而一旦新 AOF 文件創建完畢，Redis 就會從舊 AOF 文件切換到新 AOF 文件，并開始對新 AOF 文件進行追加操作。

AOF 文件有序地保存了對數據庫執行的所有寫入操作， 這些寫入操作以 Redis 協議的格式保存， 因此 AOF 文件的內容非常容易被人讀懂， 對文件進行分析（parse）也很輕松。 導出（export） AOF 文件也非常簡單： 舉個例子， 如果你不小心執行了 FLUSHALL 命令， 但只要 AOF 文件未被重寫， 那么只要停止服務器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重啟 Redis ， 就可以將數據集恢復到 FLUSHALL 執行之前的狀態。

優點對比總結

RDB 方式可以保存過去一段時間內的數據，并且保存結果是一個單一的文件，可以將文件備份到其他服務器，并且在回復大量數據的時候，RDB 方式的速度會比 AOF 方式的回復速度要快。

AOF 方式默認每秒鐘備份1次，頻率很高，它的操作方式是以追加的方式記錄日志而不是數據，并且它的重寫過程是按順序進行追加，所以它的文件內容非常容易讀懂。可以在某些需要的時候打開 AOF 文件對其編輯，增加或刪除某些記錄，最后再執行恢復操作。

華為云APP

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

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