Redis 持久化機制

標籤：

 

Redis有兩種儲存方式，預設是snapshot方式，實現方法是定時將記憶體的快照(snapshot)持久化到硬碟，這種方法缺點是持久化之後如果出現crash則會丟失一段資料。因此在完美主義者的推動下作者增加了aof方式。aof即append only mode，在寫入記憶體資料的同時將操作命令儲存到記錄檔，在一個並發更改上萬的系統中，命令日誌是一個非常龐大的資料，管理維護成本非常高，恢複重建時間會非常長，這樣導致失去aof高可用性本意。另外更重要的是Redis是一個記憶體資料結構模型，所有的優勢都是建立在對記憶體複雜資料結構高效的原子操作上，這樣就看出aof是一個非常不協調的部分。

其實aof目的主要是資料可靠性及高可用性，在Redis中有另外一種方法來達到目的：Replication。由於Redis的高效能，複製基本沒有延遲。這樣達到了防止單點故障及實現了高可用。

 比較好的做法：關閉Master持久化功能，讓資料僅僅在第10個slave伺服器節點啟動並執行時候開啟aof。 

AOF重寫

你可以會想，每一條寫命令都產生一條日誌，那麼AOF檔案是不是會很大？

答案是肯定的，AOF檔案會越來越大，所以Redis又提供了一個功能，叫做AOF rewrite。其功能就是重建一份AOF檔案，新的AOF檔案中一條記錄的操作只會有一次，而不像一份老檔案那樣，可能記錄了對同一個值的多次操作。

其產生過程和RDB類似，也是fork一個進程，直接遍曆資料，寫入新的AOF臨時檔案。在寫入新檔案的過程中，所有的寫動作記錄還是會寫到原來老的AOF檔案中，同時還會記錄在記憶體緩衝區中。當重完操作完成後，會將所有緩衝區中的日誌一次性寫入到臨時檔案中。然後調用原子性的rename命令用新的AOF檔案取代老的AOF檔案。

從上面的流程我們能夠看到，RDB和AOF操作都是順序IO操作，效能都很高。而同時在通過RDB檔案或者AOF日誌進行資料庫恢複的時候，也是順序的讀取資料載入到記憶體中。所以也不會造成磁碟的隨機讀。

AOF可靠性設定

AOF是一個寫檔案操作，其目的是將動作記錄寫到磁碟上，所以它也同樣會遇到我們上面說的寫操作的5個流程。那麼寫AOF的操作安全性又有多高呢。實際上這是可以設定的，在Redis中對AOF調用write(2)寫入後，何時再調用fsync將其寫到磁碟上，通過appendfsync選項來控制，下面有配置方法

RDB和AOF持久化對比RDB機制的優勢和略施

RDB持久化是指在指定的時間間隔內將記憶體中的資料集快照寫入磁碟。 也是預設的持久化方式，這種方式是就是將記憶體中資料以快照的方式寫入到二進位檔案中,預設的檔案名稱為dump.rdb。

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

   save 900 1  #900秒內如果超過1個key被修改，則發起快照儲存   save 300 10 #300秒內容如超過10個key被修改，則發起快照儲存   save 60 10000

優勢

• 一旦採用該方式，那麼你的整個Redis資料庫將只包含一個檔案，這樣非常方便進行備份。比如你可能打算沒1天歸檔一些資料。
• 方便備份，我們可以很容易的將一個一個RDB檔案移動到其他的儲存介質上
• RDB 在恢複大資料集時的速度比 AOF 的恢複速度要快。
• RDB 可以最大化 Redis 的效能：父進程在儲存 RDB 檔案時唯一要做的就是 fork 出一個子進程，然後這個子進程就會處理接下來的所有儲存工作，父進程無須執行任何磁碟 I/O 操作。

劣勢

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

 

AOF檔案儲存過程

redis會將每一個收到的寫命令都通過write函數追加到檔案中(預設是 appendonly.aof)。

當redis重啟時會通過重新執行檔案中儲存的寫命令來在記憶體中重建整個資料庫的內容。當然由於os會在核心中緩衝 write做的修改，所以可能不是立即寫到磁碟上。這樣aof方式的持久化也還是有可能會丟失部分修改。不過我們可以通過設定檔告訴redis我們想要 通過fsync函數強制os寫入到磁碟的時機。有三種方式如下（預設是：每秒fsync一次）

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

aof 的方式也同時帶來了另一個問題。持久化檔案會變的越來越大。例如我們調用incr test命令100次，檔案中必須儲存全部的100條命令，其實有99條都是多餘的。因為要恢複資料庫的狀態其實檔案中儲存一條set test 100就夠了。

為了壓縮aof的持久化檔案。redis提供了bgrewriteaof命令。收到此命令redis將使用與快照類似的方式將記憶體中的資料 以命令的方式儲存到臨時檔案中，最後替換原來的檔案。具體過程如下

• redis調用fork ，現在有父子兩個進程
• 子進程根據記憶體中的資料庫快照集，往臨時檔案中寫入重建資料庫狀態的命令
• 父進程繼續處理client請求，除了把寫命令寫入到原來的aof檔案中。同時把收到的寫命令緩衝起來。這樣就能保證如果子進程重寫失敗的話並不會出問題。
• 當子進程把快照內容寫入已命令方式寫到臨時檔案中後，子進程發訊號通知父進程。然後父進程把緩衝的寫命令也寫入到臨時檔案。
• 現在父進程可以使用臨時檔案替換老的aof檔案，並重新命名，後面收到的寫命令也開始往新的aof檔案中追加。

需要注意到是重寫aof檔案的操作，並沒有讀取舊的aof檔案，而是將整個記憶體中的資料庫內容用命令的方式重寫了一個新的aof檔案,這點和快照有點類似。

優勢

• 使用 AOF 持久化會讓 Redis 變得非常耐久（much more durable）：你可以設定不同的 fsync 策略，比如無 fsync ，每秒鐘一次 fsync ，或者每次執行寫入命令時 fsync 。 AOF 的預設策略為每秒鐘 fsync 一次，在這種配置下，Redis 仍然可以保持良好的效能，並且就算髮生故障停機，也最多隻會丟失一秒鐘的資料（ fsync 會在後台線程執行，所以主線程可以繼續努力地處理命令請求）。

• AOF 檔案是一個只進行追加操作的記錄檔（append only log）， 因此對 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 執行之前的狀態。

劣勢

• 對於相同的資料集來說，AOF 檔案的體積通常要大於 RDB 檔案的體積。

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

• AOF 在過去曾經發生過這樣的 bug ： 因為個別命令的原因，導致 AOF 檔案在重新載入時，無法將資料集恢複成儲存時的原樣。 （舉個例子，阻塞命令 BRPOPLPUSH 就曾經引起過這樣的 bug 。） 測試套件裡為這種情況添加了測試： 它們會自動產生隨機的、複雜的資料集， 並通過重新載入這些資料來確保一切正常。 雖然這種 bug 在 AOF 檔案中並不常見， 但是對比來說， RDB 幾乎是不可能出現這種 bug 的。

抉擇

請看文章開頭的內容，根據業務的需要 進行合理的使用

 

-----------------------------------------------------------------------------------------------

 

Redis 持久化機制