深入理解redis的持久化

Redis提供的持久化機制

Redis是一種面向“key-value”型別資料的分散式NoSQL資料庫系統，具有高效能、持久儲存、適應高併發應用場景等優勢。它雖然起步較晚，但發展卻十分迅速。 


一、Redis持久化是如何工作的？

    什麼是持久化？簡單來講就是將資料放到斷電後資料不會丟失的裝置中，也就是我們通常理解的硬碟上。

首先我們來看一下資料庫在進行寫操作時到底做了哪些事，主要有下面五個過程：

(1)客戶端向服務端傳送寫操作（資料在客戶端的記憶體中）。

(2)資料庫服務端接收到寫請求的資料（資料在服務端的記憶體中）。

(3)服務端呼叫write這個系統呼叫，將資料往磁碟上寫（資料在系統記憶體的緩衝區中）。

(4)作業系統將緩衝區中的資料轉移到磁碟控制器上（資料在磁碟快取中）。

(5)磁碟控制器將資料寫到磁碟的物理介質中（資料真正落到磁碟上）。

1、故障分析:

寫操作大致有上面5個流程，下面我們結合上面的5個流程看一下各種級別的故障： 

(1)當資料庫系統故障時，這時候系統核心還是完好的。那麼此時只要我們執行完了第3步，那麼資料就是安全的，因為後續作業系統會來完成後面幾步，保證資料最終會落到磁碟上。

(2)當系統斷電時，這時候上面5項中提到的所有快取都會失效，並且資料庫和作業系統都會停止工作。所以只有當資料在完成第5步後，才能保證在斷電後資料不丟失。

透過上面5步的瞭解，可能我們會希望搞清下面一些問題： 

(1)資料庫多長時間呼叫一次write，將資料寫到核心緩衝區？

(2)核心多長時間會將系統緩衝區中的資料寫到磁碟控制器？

(3)磁碟控制器又在什麼時候把快取中的資料寫到物理介質上？

對於第一個問題，通常資料庫層面會進行全面控制。

而對第二個問題，作業系統有其預設的策略，但是我們也可以透過POSIX API提供的fsync系列命令強制作業系統將資料從核心區寫到磁碟控制器上。

對於第三個問題，好像資料庫已經無法觸及，但實際上，大多數情況下磁碟快取是被設定關閉的，或者是隻開啟為讀快取，也就是說寫操作不會進行快取，直接寫到磁碟。

建議的做法是僅僅當你的磁碟裝置有備用電池時才開啟寫快取。


2、資料損壞 

    所謂資料損壞，就是資料無法恢復，上面我們講的都是如何保證資料是確實寫到磁碟上去，但是寫到磁碟上可能並不意味著資料不會損壞。比如我們可能一次寫請求會進行兩次不同的寫操作，當意外發生時，可能會導致一次寫操作安全完成，但是另一次還沒有進行。如果資料庫的資料檔案結構組織不合理，可能就會導致資料完全不能恢復的狀況出現。 

這裡通常也有三種策略來組織資料，以防止資料檔案損壞到無法恢復的情況：

(1)第一種是最粗糙的處理，就是不透過資料的組織形式保證資料的可恢復性。而是透過配置資料同步備份的方式，在資料檔案損壞後透過資料備份來進行恢復。實際上MongoDB在不開啟操作日誌，透過配置Replica Sets時就是這種情況。

(2)另一種是在上面基礎上新增一個操作日誌，每次操作時記一下操作的行為，這樣我們可以透過操作日誌來進行資料恢復。因為操作日誌是順序追加的方式寫的，所以不會出現操作日誌也無法恢復的情況。這也類似於MongoDB開啟了操作日誌的情況。

(3)更保險的做法是資料庫不進行舊資料的修改，只是以追加方式去完成寫操作，這樣資料本身就是一份日誌，這樣就永遠不會出現資料無法恢復的情況了。實際上CouchDB就是此做法的優秀範例。

二 、Redis提供了RDB持久化和AOF持久化

1、RDB機制的優勢和劣勢

RDB持久化是指在指定的時間間隔內將記憶體中的資料集快照寫入磁碟。

也是預設的持久化方式，這種方式是就是將記憶體中資料以快照的方式寫入到二進位制檔案中,預設的檔名為dump.rdb。

A、優勢

(1)一旦採用該方式，那麼你的整個Redis資料庫將只包含一個檔案，這樣非常方便進行備份。比如你可能打算沒1天歸檔一些資料。

(2)方便備份，我們可以很容易的將一個一個RDB檔案移動到其他的儲存介質上

(3)RDB 在恢復大資料集時的速度比 AOF 的恢復速度要快。

(4)RDB 可以最大化 Redis 的效能：父程式在儲存 RDB 檔案時唯一要做的就是 fork 出一個子程式，然後這個子程式就會處理接下來的所有儲存工作，父程式無須執行任何磁碟 I/O 操作。

B、劣勢

(1)如果你需要儘量避免在伺服器故障時丟失資料，那麼 RDB 不適合你。 雖然 Redis 允許你設定不同的儲存點（save point）來控制儲存 RDB 檔案的頻率， 但是， 因為RDB 檔案需要儲存整個資料集的狀態， 所以它並不是一個輕鬆的操作。 因此你可能會至少 5 分鐘才儲存一次 RDB 檔案。 在這種情況下， 一旦發生故障停機， 你就可能會丟失好幾分鐘的資料。

(2)每次儲存 RDB 的時候，Redis 都要 fork() 出一個子程式，並由子程式來進行實際的持久化工作。 在資料集比較龐大時， fork() 可能會非常耗時，造成伺服器在某某毫秒內停止處理客戶端； 如果資料集非常巨大，並且 CPU 時間非常緊張的話，那麼這種停止時間甚至可能會長達整整一秒。 雖然 AOF 重寫也需要進行 fork() ，但無論 AOF 重寫的執行間隔有多長，資料的耐久性都不會有任何損失。

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

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

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

   save 60 10000

2、RDB檔案儲存過程

(1)redis呼叫fork,現在有了子程式和父程式。

(2)父程式繼續處理client請求，子程式負責將記憶體內容寫入到臨時檔案。由於os的寫時複製機制（copy on write)父子程式會共享相同的物理頁面，當父程式處理寫請求時os會為父程式要修改的頁面建立副本，而不是寫共享的頁面。所以子程式的地址空間內的數 據是fork時刻整個資料庫的一個快照。

(3)當子程式將快照寫入臨時檔案完畢後，用臨時檔案替換原來的快照檔案，然後子程式退出。

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

另一點需要注意的是，每次快照持久化都是將記憶體資料完整寫入到磁碟一次，並不 是增量的只同步髒資料。如果資料量大的話，而且寫操作比較多，必然會引起大量的磁碟io操作，可能會嚴重影響效能。

3、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將使用與快照類似的方式將記憶體中的資料 以命令的方式儲存到臨時檔案中，最後替換原來的檔案。具體過程如下

(1)redis呼叫fork ，現在有父子兩個程式

(2)子程式根據記憶體中的資料庫快照，往臨時檔案中寫入重建資料庫狀態的命令

父程式繼續處理client請求，除了把寫命令寫入到原來的aof檔案中。同時把收到的寫命令快取起來。這樣就能保證如果子程式重寫失敗的話並不會出問題。

當子程式把快照內容寫入已命令方式寫到臨時檔案中後，子程式發訊號通知父程式。然後父程式把快取的寫命令也寫入到臨時檔案。

(3)現在父程式可以使用臨時檔案替換老的aof檔案，並重新命名，後面收到的寫命令也開始往新的aof檔案中追加。

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

A、優勢

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

(2)AOF 檔案是一個只進行追加操作的日誌檔案（append only log）， 因此對 AOF 檔案的寫入不需要進行 seek ， 即使日誌因為某些原因而包含了未寫入完整的命令（比如寫入時磁碟已滿，寫入中途停機，等等）， redis-check-aof 工具也可以輕易地修復這種問題。
    (3)Redis 可以在 AOF 檔案體積變得過大時，自動地在後臺對 AOF 進行重寫： 重寫後的新 AOF 檔案包含了恢復當前資料集所需的最小命令集合。 整個重寫操作是絕對安全的，因為 Redis 在建立新 AOF 檔案的過程中，會繼續將命令追加到現有的 AOF 檔案裡面，即使重寫過程中發生停機，現有的 AOF 檔案也不會丟失。 而一旦新 AOF 檔案建立完畢，Redis 就會從舊 AOF 檔案切換到新 AOF 檔案，並開始對新 AOF 檔案進行追加操作。

(4)AOF 檔案有序地儲存了對資料庫執行的所有寫入操作， 這些寫入操作以 Redis 協議的格式儲存， 因此 AOF 檔案的內容非常容易被人讀懂， 對檔案進行分析（parse）也很輕鬆。 匯出（export） AOF 檔案也非常簡單： 舉個例子， 如果你不小心執行了 FLUSHALL 命令， 但只要 AOF 檔案未被重寫， 那麼只要停止伺服器， 移除 AOF 檔案末尾的 FLUSHALL 命令， 並重啟 Redis ， 就可以將資料集恢復到 FLUSHALL 執行之前的狀態。

B、劣勢

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

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

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

3、抉擇

一般來說， 如果想達到足以媲美 PostgreSQL 的資料安全性， 你應該同時使用兩種持久化功能。

如果你非常關心你的資料， 但仍然可以承受數分鐘以內的資料丟失， 那麼你可以只使用 RDB 持久化。

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

4、如果 AOF 檔案出錯了，怎麼辦？

伺服器可能在程式正在對 AOF 檔案進行寫入時停機， 如果停機造成了 AOF 檔案出錯（corrupt）， 那麼 Redis 在重啟時會拒絕載入這個 AOF 檔案， 從而確保資料的一致性不會被破壞。

當發生這種情況時， 可以用以下方法來修復出錯的 AOF 檔案：

(1)為現有的 AOF 檔案建立一個備份。

(2)使用 Redis 附帶的 redis-check-aof 程式，對原來的 AOF 檔案進行修復。

$ redis-check-aof --fix

(3)[可選]使用 diff -u 對比修復後的 AOF 檔案和原始 AOF 檔案的備份，檢視兩個檔案之間的不同之處。

重啟 Redis 伺服器，等待伺服器載入修復後的 AOF 檔案，並進行資料恢復。

作者：SEian.G（苦練七十二變，笑對八十一難）