Redis中兩種持久化機制RDB和AOF

rdb其實就是把資料以快照的形式儲存在磁碟上。什麼是快照呢，你可以理解成把當前時刻的資料拍成一張**儲存下來。既然rdb機制是通過把某個時刻的所有資料生成乙個快照來儲存，那麼就應該有一種觸發機制，是實現這個過程。對於rdb來說，提供了三種機制：s**e、bgs**e、自動化。我們分別來看一下：

127.0.0.1:6379>set k1 v1
ok127.0.0.1:6379>set k2 v2
ok127.0.0.1:6379>s**e
ok127.0.0.1:6379>

該命令會阻塞當前redis伺服器，執行s**e命令期間，redis不能處理其他命令，直到rdb過程完成為止。具體流程如下：

注：執行完成時候如果存在老的rdb檔案，就把新的替代掉舊的。我們的客戶端可能都是幾萬或者是幾十萬，這種方式顯然不可取。

127.0.0.1:6379>set k1 v1
ok127.0.0.1:6379>set k2 v2
ok127.0.0.1:6379>bgs**e
background s**ing started
127.0.0.1:6379>

執行該命令時，redis會在後台非同步進行快照操作，快照同時還可以響應客戶端請求。具體流程如下：

具體操作是redis程序執行fork操作建立子程序，rdb持久化過程由子程序負責，完成後自動結束。阻塞只發生在fork階段，一般時間很短。基本上 redis 內部所有的rdb操作都是採用 bgs**e 命令。

自動觸發是由我們的配置檔案來完成的。在redis.conf配置檔案中，裡面有如下配置，我們可以去設定：

①s**e：這裡是用來配置觸發 redis的 rdb 持久化條件，也就是什麼時候將記憶體中的資料儲存到硬碟。比如「s**e m n」。表示m秒內資料集存在n次修改時，自動觸發bgs**e。

預設如下配置：

#表示900 秒內如果至少有 1 個 key 的值變化，則儲存s**e 900 1#表示300 秒內如果至少有 10 個 key 的值變化，則儲存s**e 300 10#表示60 秒內如果至少有 10000 個 key 的值變化，則儲存s**e 60 10000

不需要持久化，那麼你可以注釋掉所有的 s**e 行來停用儲存功能。

②stop-writes-on-bgs**e-error：預設值為yes。當啟用了rdb且最後一次後台儲存資料失敗，redis是否停止接收資料。這會讓使用者意識到資料沒有正確持久化到磁碟上，否則沒有人會注意到災難（disaster）發生了。如果redis重啟了，那麼又可以重新開始接收資料了

③rdbcompression；預設值是yes。對於儲存到磁碟中的快照，可以設定是否進行壓縮儲存。

④rdbchecksum：預設值是yes。在儲存快照後，我們還可以讓redis使用crc64演算法來進行資料校驗，但是這樣做會增加大約10%的效能消耗，如果希望獲取到最大的效能提公升，可以關閉此功能。

⑤dbfilename：設定快照的檔名，預設是 dump.rdb

⑥dir：設定快照檔案的存放路徑，這個配置項一定是個目錄，而不能是檔名。

redis會將每乙個收到的寫命令都通過write函式追加到檔案中。通俗的理解就是日誌記錄。每當有乙個寫命令過來時，就直接儲存在我們的aof檔案中。

aof的方式也同時帶來了另乙個問題。持久化檔案會變的越來越大。為了壓縮aof的持久化檔案。redis提供了bgrewriteaof命令。將記憶體中的資料以命令的方式儲存到臨時檔案中，同時會fork出一條新程序來將檔案重寫。

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

對於aof來說，提供了三種機制：我們分別來看一下：