RDB（Redis DataBase）

在指定的時間間隔內將記憶體中的資料集快照寫入磁碟，也就是行話講的Snapshot快照，它恢復時是將快照檔案直接讀入到記憶體裡。 Redis會單獨建立（fork）一個子程序來進行持久化，會先將資料寫入到一個臨時檔案中，待持久化過程都結束了，再用這個臨時檔案替換上次持久化好的檔案。 整個過程中，主程序是不進行任何IO操作的，這就確保了極高的效能。 如果需要進行大規模資料的恢復，且對於資料恢復的完整性不是非常敏感，那RDB方式要比AOF方式更加高效。 RDB的缺點是最後一次持久化後的資料可能丟失。

fork

fork的作用是複製一個與當前程序一樣的程序。新程序的所有資料（變數、環境變數、程式計數器等）數值都和原程序一致，但是是一個全進的程序，並作為原程序的子程序。

dump.rdb檔案

RDB儲存的是dump.rdb檔案。

配置檔案

redis.conf中搜索SNAPSHOTTING，即使該功能模組的配置。 save <seconds> <changes>，在seconds秒內發生changes次改變，則進行資料儲存。 預設：一分鐘改了10次，5分鐘改了10次，15分鐘改了一次，都會出發RDB快照。 注意：進行shutdown時，會自動儲存一次dump.rdb，最後的更改是保留的。

資料恢復

拷貝出dump.rdb到遠端備份機，需要恢復時，拷貝回來，覆蓋dump.rdb，啟動服務即可恢復。

觸發RDB快照

（1）配置檔案中預設的快照配置【冷拷貝後重新使用（遠端備份機）】 （2）使用save

恢復資料

（1）將備份檔案（dump.rdb）移動到redis安裝目錄並啟動服務即可。 （2）config get dir，獲取目錄

優勢

（1）適合大規模的資料恢復 （2）對資料完整性和一致性要求不高

劣勢

（1）在一定間隔時間做一次備份，所以如果Redis意外down掉的話，就會丟失最後一次快照後的所有修改。 （2）Fork的時候，記憶體中的資料被克隆了一份，2倍的膨脹性需要考慮。

如何停止RDB

redis-cli config set save ""，通過設定空串，進行停止RDB。

RDB總結

AOF（Append Only File）

以日誌的形式來記錄每個寫操作，將Redis執行過的所有寫指令記錄下來（讀操作不記錄），只許追加檔案但不可以改寫檔案，redis啟動之初會讀取該檔案重構資料，換言之，redis重啟的話就根據日誌檔案的內容將寫指令從前到後執行一次已完成資料的恢復工作。

配置開啟AOP

appendonly

在redis.conf中，找到appendonly no（預設關閉）改為appendonly yes。

appendfilename

AOF模式的檔名。

共存

RDB和AOF是可以共存的，Redis會先載入AOF，若AOF檔案出錯，則Redis服務啟動失敗。

AOF檔案修復

使用命令redis-check-aof --fix appendonly.aof，進行檔案修復，在嘗試啟動（工程上請先備份）。

ReWrite

AOF採用檔案追加方式，檔案會越來越大，為避免出現此種情況，新增了重寫機制，當AOF檔案的大小超過所設定的閾值時，Redis會啟動AOF檔案的內容壓縮，只保留可以恢復資料的最小指令集，可以使用bgrewriteaof。

重寫原理

AOF檔案持續增長而過大時，會fork出一條新程序來將檔案重寫（也是先寫臨時檔案最後在rename），遍歷新程序的記憶體中的資料，每條記錄有一條set語句。重寫AOF檔案額時候，並沒有讀取舊的aof檔案 ，而是將整個記憶體中的資料庫內容用命令的方式重寫了一個新的aof檔案，這點和快照有點類似。

觸發機制

Redis會記錄上次重寫時的AOF大小，預設配置是當AOF檔案大小是上次rewrite後大小的一倍且檔案大於64M時觸發。在redis.conf中有如下預設配置：

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

優勢

每修改同步：appendfsync always 同步持久化，效能差但完整性好。 每秒同步：appendfsync everysec 非同步操作，每秒記錄。 不同步：appendfsync no

劣勢

（1）相同資料集的資料而言AOF檔案要遠大於RDB檔案，恢復速度慢於RDB。 （2）AOF執行效率要慢於RDB，每秒同步策略效率較好，不同步效率和RDB相同。

AOF總結

總結

（1）RDB持久化方式能夠在指定的時間間隔內對你的資料進行快照儲存。 （2）AOF持久化方式記錄每次對伺服器寫的操作，當伺服器重啟的時候會重新執行這些命令來回復原始的資料，AOF命令以Redis協議追加儲存每次寫的操作到檔案末尾。 （3）Redis還能對AOF檔案進行後臺重寫，使得AOF檔案的體積不至於過大。

場景

只做快取：如果你只希望你的資料在伺服器執行的時候存在，你也可以不適用任何持久化方式。 同時開始兩種持久化方式： 在這種情況下，當redis重啟的時候回優先載入AOF檔案來恢復原始的資料，因為在通常情況下AOF檔案儲存的資料要比RDB檔案儲存的資料集更完整。 RDB的資料不實時，同時使用兩者時，伺服器重啟也只會找AOF檔案。

要不要只使用AOF

不要，因為RDB更適合用於備份資料庫（AOF在不斷變化不好備份），快速重啟，而且不會有AOF可能潛在的BUG，留著以防萬一（只是損失一段時間的資料）。

效能建議