Redis提供的持久化機制（RDB和AOF）

標籤：pen   export   訊號   幾分鐘   一致性   避免   選擇   out   大數   

Redis提供的持久化機制

Redis是一種高效能的資料庫，可以選擇持久化，也可以選擇不持久化。

如果要儲存，就會存在資料同步的問題，可以簡單認為一份資料放在記憶體中（快照），一份資料放在磁碟上，Redis提供了很靈活的持久化辦法：

 

 

Redis提供了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

RDB檔案儲存過程

• redis調用fork,現在有了子進程和父進程。
• 父進程繼續處理client請求，子進程負責將記憶體內容寫入到臨時檔案。由於os的寫時複製機制（copy on write)父子進程會共用相同的物理頁面，當父進程處理寫請求時os會為父進程要修改的頁面棄置站台，而不是寫共用的頁面。所以子進程的地址空間內的數 據是fork時刻整個資料庫的一個快照。
• 當子進程將快照寫入臨時檔案完畢後，用臨時檔案替換原來的快照檔案，然後子進程退出。

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

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

優勢

• 一旦採用該方式，那麼你的整個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 的。

抉擇

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

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

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

 

5.1、

1).RDB持久化

　　該機制是指在指定的時間間隔內將記憶體中的資料集快照寫入磁碟。 比如每隔15分鐘有資料變化將記憶體中的資料與磁碟同步。

　　redis預設配置中就採用了該方法，如下所示：

　　# after 900 sec (15 min) if at least 1 key changed      15分種內如果有1個以上的內容發生了變化就執行儲存

　　# after 300 sec (5 min) if at least 10 keys changed    5分種內如果有10個以上的內容發生了變化就執行儲存

　　# after 60 sec if at least 10000 keys changed          1分種內如果有10000 個以上的內容發生了變化就執行儲存

2). AOF持久化:
　　該機制將以日誌的形式記錄伺服器所處理的每一個寫操作，在Redis伺服器啟動之初會讀取該檔案來重新構建資料庫，以保證啟動後資料庫中的資料是完整的。
3). 無持久化：
　　我們可以通過配置的方式禁用Redis伺服器的持久化功能，這樣我們就可以將Redis視為一個功能加強版的memcached了。
4). 同時應用AOF和RDB。

5.2、RDB機制的優勢和劣勢：

優勢->
　　1). 一旦採用該方式，那麼你的整個Redis資料庫將只包含一個檔案，這對於檔案備份而言是非常完美的。

　　　　　　比如，你可能打算每個小時歸檔一次最近24小時的資料，同時還要每天歸檔一次最近30天的資料。

　　　　　　   通過這樣的備份策略，一旦系統出現災難性故障，我們可以非常容易的進行恢複。
　　2). 對於災難恢複而言，RDB是非常不錯的選擇。

　　　　　　因為我們可以非常輕鬆的將一個單獨的檔案壓縮後再轉移到其它儲存介質上。
　　3). 效能最大化。

　　　　　　對於Redis的服務進程而言，在開始持久化時，它唯一需要做的只是fork出子進程，之後再由子進程完成這些持久化的工作，

　　　　　　這樣就可以極大的避免服務進程執行IO操作了。
　　4). 相比於AOF機制，如果資料集很大，RDB的啟動效率會更高。

劣勢->
　　1). 如果你想保證資料的高可用性，即最大限度的避免資料丟失，那麼RDB將不是一個很好的選擇。

　　　　　　因為系統一旦在定時持久化之前出現宕機現象，此前沒有來得及寫入磁碟的資料都將丟失。
　　2). 由於RDB是通過fork子進程來協助完成資料持久化工作的，因此，如果當資料集較大時，可能會導致整個伺服器停止服務幾百毫秒，甚至是1秒鐘。

5.3、AOF機制的優勢和劣勢：

優勢->
　　1). 該機制可以帶來更高的資料安全性，即資料持久性。

　　　　Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。

　　　　事實上，每秒同步也是非同步完成的，其效率也是非常高的，所差的是一旦系統出現宕機現象，那麼這一秒鐘之內修改的資料將會丟失。

　　　　而每修改同步，我們可以將其視為同步持久化，即每次發生的資料變化都會被立即記錄到磁碟中。

　　　　可以預見，這種方式在效率上是最低的。

　　　　至於無同步，無需多言，我想大家都能正確的理解它。
　　2). 由於該機制對記錄檔的寫入操作採用的是append模式，因此在寫入過程中即使出現宕機現象，也不會破壞記錄檔中已經存在的內容。

　　　　　　然而如果我們本次操作只是寫入了一半資料就出現了系統崩潰問題，不用擔心，

　　　　　　在Redis下一次啟動之前，我們可以通過redis-check-aof工具來協助我們解決資料一致性的問題。
　　3). 如果日誌過大，Redis可以自動啟用rewrite機制。即Redis以append模式不斷的將修改資料寫入到老的磁碟檔案中，

同時Redis還會建立一個新的檔案用於記錄此期間有哪些修改命令被執行。因此在進行rewrite切換時可以更好的保證資料安全性。
　　4). AOF包含一個格式清晰、易於理解的記錄檔用於記錄所有的修改操作。事實上，我們也可以通過該檔案完成資料的重建。

AOF的劣勢有哪些呢？
　　1). 對於相同數量的資料集而言，AOF檔案通常要大於RDB檔案。
　　2). 根據同步策略的不同，AOF在運行效率上往往會慢於RDB。總之，每秒同步策略的效率是比較高的，同步禁用策略的效率和RDB一樣高效。

5.4、其它

5.4.1. Snapshotting:
預設情況下，Redis會將資料集的快照dump到dump.rdb檔案中。此外，我們也可以通過設定檔來修改Redis伺服器dump快照的頻率，在開啟6379.conf檔案之後，我們搜尋save，可以看到下面的配置資訊：
save 900 1 #在900秒(15分鐘)之後，如果至少有1個key發生變化，則dump記憶體快照。
save 300 10 #在300秒(5分鐘)之後，如果至少有10個key發生變化，則dump記憶體快照。
save 60 10000 #在60秒(1分鐘)之後，如果至少有10000個key發生變化，則dump記憶體快照。

5.4.2. Dump快照的機制：
1). Redis先fork子進程。
2). 子進程將快照資料寫入到臨時RDB檔案中。
3). 當子進程完成資料寫入操作後，再用臨時檔案替換老的檔案。

5.4.3. AOF檔案：
上面已經多次講過，RDB的快照定時dump機制無法保證很好的資料持久性。如果我們的應用確實非常關注此點，我們可以考慮使用Redis中的AOF機制。對於Redis伺服器而言，其預設的機制是RDB，如果需要使用AOF，則需要修改設定檔中的以下條目：
將appendonly no改為appendonly yes
從現在起，Redis在每一次接收到資料修改的命令之後，都會將其追加到AOF檔案中。在Redis下一次重新啟動時，需要載入AOF檔案中的資訊來構建最新的資料到記憶體中。

5.4.5. AOF的配置：
在Redis的設定檔中存在三種同步方式，它們分別是：
appendfsync always #每次有資料修改發生時都會寫入AOF檔案。
appendfsync everysec #每秒鐘同步一次，該策略為AOF的預設策略。
appendfsync no #從不同步。高效但是資料不會被持久化。

5.4.6. 如何修複壞損的AOF檔案：
1). 將現有已經壞損的AOF檔案額外拷貝出來一份。
2). 執行"redis-check-aof --fix <filename>"命令來修複壞損的AOF檔案。
3). 用修複後的AOF檔案重新啟動Redis伺服器。

5.4.7. Redis的資料備份：
在Redis中我們可以通過copy的方式線上備份正在啟動並執行Redis資料檔案。這是因為RDB檔案一旦被產生之後就不會再被修改。Redis每次都是將最新的資料dump到一個臨時檔案中，之後在利用rename函數原子性的將臨時檔案改名為原有的資料檔案名。因此我們可以說，在任意時刻copy資料檔案都是安全的和一致的。鑒於此，我們就可以通過建立cron job的方式定時備份Redis的資料檔案，並將備份檔案copy到安全的磁碟介質中。

5.5、立即寫入

//立即儲存，同步儲存    public static void syncSave() throws Exception{        Jedis jedis=new Jedis("127.0.0.1",6379);        for (int i = 0; i <1000; i++) {            jedis.set("key"+i, "Hello"+i);            System.out.println("設定key"+i+"的資料到redis");            Thread.sleep(2);        }        //執行儲存，會在伺服器下產生一個dump.rdb資料庫檔案        jedis.save();        jedis.close();        System.out.println("寫入完成");    }

運行結果：

這裡的save方法是同步的，沒有寫入完成前不執行後面的代碼。

5.6、非同步寫入

    //非同步儲存    public static void asyncSave() throws Exception{        Jedis jedis=new Jedis("127.0.0.1",6379);        for (int i = 0; i <1000; i++) {            jedis.set("key"+i, "Hello"+i);            System.out.println("設定key"+i+"的資料到redis");            Thread.sleep(2);        }        //執行非同步儲存，會在伺服器下產生一個dump.rdb資料庫檔案        jedis.bgsave();        jedis.close();        System.out.println("寫入完成");    }

如果資料量非常大，要儲存的內容很多，建議使用bgsave，如果內容少則可以使用save方法。關於各方式的比較源自網友的部落格。

  

Redis提供的持久化機制（RDB和AOF）