RDB和AOF持久化對比

Redis提供了RDB持久化和AOF持久化，本篇文章中將會對這兩種機制進行一些對比

RDB機制的優(yōu)勢和略施

RDB持久化是指在指定的時間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照寫入磁盤。 也是默認的持久化方式，這種方式是就是將內(nèi)存中數(shù)據(jù)以快照的方式寫入到二進制文件中,默認的文件名為dump.rdb。

可以通過配置設置自動做快照持久化的方式。我們可以配置redis在n秒內(nèi)如果超過m個key被修改就自動做快照，下面是默認的快照保存配置

save 900 1 #900秒內(nèi)如果超過1個key被修改，則發(fā)起快照保存save 300 10 #300秒內(nèi)容如超過10個key被修改，則發(fā)起快照保存save 60 10000

RDB文件保存過程

• redis調(diào)用fork,現(xiàn)在有了子進程和父進程。
• 父進程繼續(xù)處理client請求，子進程負責將內(nèi)存內(nèi)容寫入到臨時文件。由于os的寫時復制機制（copy on write)父子進程會共享相同的物理頁面，當父進程處理寫請求時os會為父進程要修改的頁面創(chuàng)建副本，而不是寫共享的頁面。所以子進程的地址空間內(nèi)的數(shù) 據(jù)是fork時刻整個數(shù)據(jù)庫的一個快照。
• 當子進程將快照寫入臨時文件完畢后，用臨時文件替換原來的快照文件，然后子進程退出。

client 也可以使用save或者bgsave命令通知redis做一次快照持久化。save操作是在主線程中保存快照的，由于redis是用一個主線程來處理所有 client的請求，這種方式會阻塞所有client請求。所以不推薦使用。

另一點需要注意的是，每次快照持久化都是將內(nèi)存數(shù)據(jù)完整寫入到磁盤一次，并不 是增量的只同步臟數(shù)據(jù)。如果數(shù)據(jù)量大的話，而且寫操作比較多，必然會引起大量的磁盤io操作，可能會嚴重影響性能。

優(yōu)勢

• 一旦采用該方式，那么你的整個Redis數(shù)據(jù)庫將只包含一個文件，這樣非常方便進行備份。比如你可能打算沒1天歸檔一些數(shù)據(jù)。
• 方便備份，我們可以很容易的將一個一個RDB文件移動到其他的存儲介質上
• RDB 在恢復大數(shù)據(jù)集時的速度比 AOF 的恢復速度要快。
• RDB 可以最大化 Redis 的性能：父進程在保存 RDB 文件時唯一要做的就是 fork 出一個子進程，然后這個子進程就會處理接下來的所有保存工作，父進程無須執(zhí)行任何磁盤 I/O 操作。

劣勢

• 如果你需要盡量避免在服務器故障時丟失數(shù)據(jù)，那么 RDB 不適合你。 雖然 Redis 允許你設置不同的保存點（save point）來控制保存 RDB 文件的頻率， 但是， 因為RDB 文件需要保存整個數(shù)據(jù)集的狀態(tài)， 所以它并不是一個輕松的操作。 因此你可能會至少 5 分鐘才保存一次 RDB 文件。 在這種情況下， 一旦發(fā)生故障停機， 你就可能會丟失好幾分鐘的數(shù)據(jù)。
• 每次保存 RDB 的時候，Redis 都要 fork() 出一個子進程，并由子進程來進行實際的持久化工作。 在數(shù)據(jù)集比較龐大時， fork() 可能會非常耗時，造成服務器在某某毫秒內(nèi)停止處理客戶端； 如果數(shù)據(jù)集非常巨大，并且 CPU 時間非常緊張的話，那么這種停止時間甚至可能會長達整整一秒。 雖然 AOF 重寫也需要進行 fork() ，但無論 AOF 重寫的執(zhí)行間隔有多長，數(shù)據(jù)的耐久性都不會有任何損失。

AOF文件保存過程

redis會將每一個收到的寫命令都通過write函數(shù)追加到文件中(默認是 appendonly.aof)。

當redis重啟時會通過重新執(zhí)行文件中保存的寫命令來在內(nèi)存中重建整個數(shù)據(jù)庫的內(nèi)容。當然由于os會在內(nèi)核中緩存 write做的修改，所以可能不是立即寫到磁盤上。這樣aof方式的持久化也還是有可能會丟失部分修改。不過我們可以通過配置文件告訴redis我們想要 通過fsync函數(shù)強制os寫入到磁盤的時機。有三種方式如下（默認是：每秒fsync一次）

appendonly yes //啟用aof持久化方式 # appendfsync always //每次收到寫命令就立即強制寫入磁盤，最慢的，但是保證完全的持久化，不推薦使用 appendfsync everysec //每秒鐘強制寫入磁盤一次，在性能和持久化方面做了很好的折中，推薦 # appendfsync no //完全依賴os，性能最好,持久化沒保證

aof 的方式也同時帶來了另一個問題。持久化文件會變的越來越大。例如我們調(diào)用incr test命令100次，文件中必須保存全部的100條命令，其實有99條都是多余的。因為要恢復數(shù)據(jù)庫的狀態(tài)其實文件中保存一條set test 100就夠了。

為了壓縮aof的持久化文件。redis提供了bgrewriteaof命令。收到此命令redis將使用與快照類似的方式將內(nèi)存中的數(shù)據(jù) 以命令的方式保存到臨時文件中，最后替換原來的文件。具體過程如下

• redis調(diào)用fork ，現(xiàn)在有父子兩個進程
• 子進程根據(jù)內(nèi)存中的數(shù)據(jù)庫快照，往臨時文件中寫入重建數(shù)據(jù)庫狀態(tài)的命令
• 父進程繼續(xù)處理client請求，除了把寫命令寫入到原來的aof文件中。同時把收到的寫命令緩存起來。這樣就能保證如果子進程重寫失敗的話并不會出問題。
• 當子進程把快照內(nèi)容寫入已命令方式寫到臨時文件中后，子進程發(fā)信號通知父進程。然后父進程把緩存的寫命令也寫入到臨時文件。
• 現(xiàn)在父進程可以使用臨時文件替換老的aof文件，并重命名，后面收到的寫命令也開始往新的aof文件中追加。

需要注意到是重寫aof文件的操作，并沒有讀取舊的aof文件，而是將整個內(nèi)存中的數(shù)據(jù)庫內(nèi)容用命令的方式重寫了一個新的aof文件,這點和快照有點類似。

優(yōu)勢

• 使用 AOF 持久化會讓 Redis 變得非常耐久（much more durable）：你可以設置不同的 fsync 策略，比如無 fsync ，每秒鐘一次 fsync ，或者每次執(zhí)行寫入命令時 fsync 。 AOF 的默認策略為每秒鐘 fsync 一次，在這種配置下，Redis 仍然可以保持良好的性能，并且就算發(fā)生故障停機，也最多只會丟失一秒鐘的數(shù)據(jù)（ fsync 會在后臺線程執(zhí)行，所以主線程可以繼續(xù)努力地處理命令請求）。

• AOF 文件是一個只進行追加操作的日志文件（append only log）， 因此對 AOF 文件的寫入不需要進行 seek ， 即使日志因為某些原因而包含了未寫入完整的命令（比如寫入時磁盤已滿，寫入中途停機，等等）， redis-check-aof 工具也可以輕易地修復這種問題。
  Redis 可以在 AOF 文件體積變得過大時，自動地在后臺對 AOF 進行重寫： 重寫后的新 AOF 文件包含了恢復當前數(shù)據(jù)集所需的最小命令集合。 整個重寫操作是絕對安全的，因為 Redis 在創(chuàng)建新 AOF 文件的過程中，會繼續(xù)將命令追加到現(xiàn)有的 AOF 文件里面，即使重寫過程中發(fā)生停機，現(xiàn)有的 AOF 文件也不會丟失。 而一旦新 AOF 文件創(chuàng)建完畢，Redis 就會從舊 AOF 文件切換到新 AOF 文件，并開始對新 AOF 文件進行追加操作。

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

劣勢

• 對于相同的數(shù)據(jù)集來說，AOF 文件的體積通常要大于 RDB 文件的體積。

• 根據(jù)所使用的 fsync 策略，AOF 的速度可能會慢于 RDB 。 在一般情況下， 每秒 fsync 的性能依然非常高， 而關閉 fsync 可以讓 AOF 的速度和 RDB 一樣快， 即使在高負荷之下也是如此。 不過在處理巨大的寫入載入時，RDB 可以提供更有保證的最大延遲時間（latency）。

• AOF 在過去曾經(jīng)發(fā)生過這樣的 bug ： 因為個別命令的原因，導致 AOF 文件在重新載入時，無法將數(shù)據(jù)集恢復成保存時的原樣。 （舉個例子，阻塞命令 BRPOPLPUSH 就曾經(jīng)引起過這樣的 bug 。） 測試套件里為這種情況添加了測試： 它們會自動生成隨機的、復雜的數(shù)據(jù)集， 并通過重新載入這些數(shù)據(jù)來確保一切正常。 雖然這種 bug 在 AOF 文件中并不常見， 但是對比來說， RDB 幾乎是不可能出現(xiàn)這種 bug 的。

抉擇

一般來說， 如果想達到足以媲美 PostgreSQL 的數(shù)據(jù)安全性， 你應該同時使用兩種持久化功能。

如果你非常關心你的數(shù)據(jù)， 但仍然可以承受數(shù)分鐘以內(nèi)的數(shù)據(jù)丟失， 那么你可以只使用 RDB 持久化。

其余情況我個人喜好選擇AOF

總結

以上是生活随笔為你收集整理的RBD和AOF持久化对比的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。