文章 Redis 快照持久化學習筆記 介紹 Redis 快照持久化的功能，除了快照持久化外，Redis 還提供了 AOF（Append Only File）持久化功能。與快照持久化通過直接儲存 Redis 的鍵值對資料不同，AOF 持久化是通過儲存 Redis 執行的寫命令來記錄 Redis 的記憶體資料。

AOF 持久化的原理

理論上說，只要我們儲存了所有可能修改 Redis 記憶體資料的命令（也就是寫命令），那麼根據這些儲存的寫命令，我們可以重新恢復 Redis 的記憶體狀態。AOF 持久化正是利用這個原理來實現資料的持久化與資料的恢復的。
Redis AOF 持久化原理如圖 1 與圖 2 所示。

圖1：Redis 將寫命令儲存到 AOF 檔案中

圖2：Redis 利用 AOF 檔案還原記憶體資料

AOF 配置

為了開啟 AOF 持久化的功能，我們只需要將 redis.conf 配置檔案中的appendonly配置選項設定為yes即可。涉及 AOF 持久化的幾個常用配置如下所示：

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec

• appendonly：是否開啟 AOF 持久化功能
• appendfilename：AOF 檔名稱
• appendfsync：同步頻率，可選配置如表1所示

表 1：appendfsync 選項及同步頻率

AOF 檔案的生成過程具體包括命令追加，檔案寫入，檔案同步三個步驟。
Redis 開啟 AOF 持久化功能後，Redis 在執行完一個寫命令後，都會將執行的寫命令追回到 Redis 內部的緩衝區的末尾。這個過程是命令的追加過程。
接下來，緩衝區的寫命令會被寫入到 AOF 檔案，這一過程是檔案寫入過程。對於作業系統來說，呼叫write

AOF 檔案

前面我們提到，AOF 持久化是通過 AOF 檔案來實現的，那麼 AOF 裡面是如何儲存 Redis 的寫命令的呢？
假設我們對一個空的 Redis 資料庫執行以下命令：

set msg hello
set site leehao.me

執行後，Redis 資料庫儲存了鍵 msg 與 site 的資料。開啟儲存的 AOF 檔案appendonly.aof（AOF 檔案的路徑和名稱由 redis.conf 配置，具體可以參考上面 AOF 配置的描述），可以看到其內容為：

*2
$6
SELECT
$1
0
*3
$3
set
$3
msg
$5
hello
*3
$3
set
$4
site
$9
leehao.me

appendonly.aof以 Redis 協議格式 RESP 來儲存寫命令。由於 RESP 協議中包含了換行符，所以上面展示的 AOF 檔案時遇到換行符時進行了換行。在 AOF 檔案裡面，除了用於指定資料庫的 SELECT 命令是自動新增的之外，其他都是我們通過客戶端傳送的命令。
appendonly.aof儲存的命令會在 Redis 下次重啟時使用來還原 Redis 資料庫。

重寫 / 壓縮 AOF 檔案

由於 Redis 會不斷地將被執行的命令記錄到 AOF 檔案裡面，所以隨著 Redis 不斷執行，AOF 檔案的體積會越來越大。另外，如果 AOF 檔案的體積很大，那麼還原操作所需要的時間也會非常地長。
為了解決 AOF 檔案越來越大的問題，使用者可以向 Redis 傳送 BGREWRITEAOF 命令，這個命令會移除 AOF 檔案中冗餘的命令來重寫 AOF 檔案，使 AOF 檔案的體積變得儘可能地小。
BGREWRITEAOF 的工作原理和快照持久化命令 BGSAVE 的工作原理類似，Redis 會建立一個子程序來負責對 AOF 檔案進行重寫。
值得注意的是，進行 AOF 檔案重寫時，如果原來的 AOF 檔案體積已經非常大，那麼重寫 AOF 並刪除舊 AOF 檔案的過程將會對 Redis 的效能造成較大的影響。
為此，Redis 提供auto-aof-rewrite-percentage和auto-aof-rewrite-min-size兩個配置選項來對 AOF 重寫進行配置。auto-aof-rewrite-percentage和auto-aof-rewrite-min-size兩個配置選項的含義可以參考 redis.conf 配置中的詳細說明，具體來說，auto-aof-rewrite-percentage配置當 AOF 檔案需要比舊 AOF 檔案增大多少時才進行 AOF 重寫，而auto-aof-rewrite-min-size則配置當 AOF 檔案需要達到多大體積時才進行 AOF 重寫。只有這兩個配置的條件都達到時，才會進行 AOF 重寫。

AOF 的優點

• AOF 持久化的方法提供了多種的同步頻率，即使使用預設的同步頻率每秒同步一次，Redis 最多也就丟失 1 秒的資料而已。
• AOF 檔案使用 Redis 命令追加的形式來構造，因此，即使 Redis 只能向 AOF 檔案寫入命令的片斷，使用 redis-check-aof 工具也很容易修正 AOF 檔案。
• AOF 檔案的格式可讀性較強，這也為使用者提供了更靈活的處理方式。例如，如果我們不小心錯用了 FLUSHALL 命令，在重寫還沒進行時，我們可以手工將最後的 FLUSHALL 命令去掉，然後再使用 AOF 來恢復資料。

AOF 的缺點

• 對於具有相同資料的的 Redis，AOF 檔案通常會比 RDF 檔案體積更大。
• 雖然 AOF 提供了多種同步的頻率，預設情況下，每秒同步一次的頻率也具有較高的效能。但在 Redis 的負載較高時，RDB 比 AOF 具好更好的效能保證。
• RDB 使用快照的形式來持久化整個 Redis 資料，而 AOF 只是將每次執行的命令追加到 AOF 檔案中，因此從理論上說，RDB 比 AOF 方式更健壯。官方文件也指出，AOF 的確也存在一些 BUG，這些 BUG 在 RDB 沒有存在。

參考資料