關於redis的數據持久化問題

RDB

RDB持久化是把當前進程數據生成快照保存到硬盤的過程，觸發機制有手動和自動。

RDB是一個壓縮的二進制文件按，是某一個時間點上的數據快照，適合備份、全量複製，比較適用於災難恢復。redis加載RDB恢復數據遠遠快於AOF的方式。

RDB沒有辦法作到實時持久化（秒級），bgsave每次運行執行fork建立子進程，屬於重量級操做，頻繁執行成本高。流程以下：

• 手動觸發

一、save：redis 127.0.0.1:6379> SAVE 

阻塞當前的redis服務器，直到RBD完成位置，對於內存較大的實例影響時間較長

二、bgsave：redis 127.0.0.1:6379> BGSAVE 

redis進程執行fork建立子進程，RDB持久化有子進程負責，完成後自動結束，阻塞只發生在fork階段，時間極短

複製代碼

• 自動觸發

一、使用save的相關配置，如：「save m n 」，表示M秒內數據集存在N次修正，會自動觸發

二、執行debug reload命令從新加載redis時，會觸發

三、默認狀況下執行shotdown時，若是沒有開啓AOF，會觸發
複製代碼

AOF

AOF以獨立日誌的方式記錄每一次的些命令，重啓時執行AOF文件，主要解決數據持久化的實時性。流程以下：

重寫機制

隨着命令不斷寫入AOF，文件會愈來愈大，redis引入AOF重寫機制壓縮文件。AOF文件重寫是把redis進程內的數據轉化爲寫命令同步到新的AOF文件的過程。

文件變小的緣由

• 進程內超時的數據再也不寫入文件

• 舊的AOF文件內無效的命令，新生成的文件只保留最終寫入數據的命令

• 多條命令合併爲一個命令

數據從新加載

AOF和RDB均可以用於服務器重啓時的數據恢復。其持久化文件加載流程以下：

文件的校驗

• 當加載損壞的AOF文件時，會拒絕啓動。

• 當加載錯誤格式的AOF文件時，會先備份，而後進行自動修復。

• 當機器忽然掉電致使文件不完整，redis會兼容這種狀況（aof-load-truncated）