Redis AOF 持久化詳解-有解無憂

Redis 是一種記憶體資料庫，將資料保存在記憶體中，讀寫效率要比傳統的將資料保存在磁盤上的資料庫要快很多，但是一旦行程退出，Redis 的資料就會丟失，

為了解決這個問題，Redis 提供了 RDB 和 AOF 兩種持久化方案，將記憶體中的資料保存到磁盤中，避免資料丟失，RDB的介紹在這篇文章中《Redis RDB 持久化詳解》，今天我們來看一下 AOF 相關的原理，

AOF( append only file )持久化以獨立日志的方式記錄每次寫命令，并在 Redis 重啟時在重新執行 AOF 檔案中的命令以達到恢復資料的目的，AOF 的主要作用是解決資料持久化的實時性，

RDB 和 AOF

antirez 在《Redis 持久化解密》一文中講述了 RDB 和 AOF 各自的優缺點：

RDB 是一個緊湊壓縮的二進制檔案，代表 Redis 在某個時間點上的資料備份，非常適合備份，全量復制等場景，比如每6小時執行 bgsave 備份，并把 RDB 檔案拷貝到遠程機器或者檔案系統中，用于災難恢復，
Redis 加載 RDB 恢復資料遠遠快于 AOF 的方式
RDB 方式資料沒辦法做到實時持久化，而 AOF 方式可以做到，

下面，我們就來了解一下 AOF 是如何做到實時持久化的，

AOF 持久化的實作

示意圖

如上圖所示，AOF 持久化功能的實作可以分為命令追加( append )、檔案寫入( write )、檔案同步( sync )、檔案重寫(rewrite)和重啟加載(load)，其流程如下：

所有的寫命令會追加到 AOF 緩沖中，
AOF 緩沖區根據對應的策略向硬碟進行同步操作，
隨著 AOF 檔案越來越大，需要定期對 AOF 檔案進行重寫，達到壓縮的目的，
當 Redis 重啟時，可以加載 AOF 檔案進行資料恢復，

命令追加

當 AOF 持久化功能處于打開狀態時，Redis 在執行完一個寫命令之后，會以協議格式(也就是RESP，即 Redis 客戶端和服務器互動的通信協議 )將被執行的寫命令追加到 Redis 服務端維護的 AOF 緩沖區末尾，

比如說 SET mykey myvalue 這條命令就以如下格式記錄到 AOF 緩沖中，

"*3\r\n$3\r\nSET\r\n$5\r\nmykey\r\n$7\r\nmyvalue\r\n"

Redis 協議格式本文不再贅述，AOF之所以直接采用文本協議格式，是因為所有寫入命令都要進行追加操作，直接采用協議格式，避免了二次處理開銷，

檔案寫入和同步

Redis 每次結束一個事件回圈之前，它都會呼叫 flushAppendOnlyFile 函式，判斷是否需要將 AOF 快取區中的內容寫入和同步到 AOF 檔案中，

flushAppendOnlyFile 函式的行為由 redis.conf 配置中的 appendfsync 選項的值來決定，該選項有三個可選值，分別是 always、 everysec 和 no：

always：Redis 在每個事件回圈都要將 AOF 緩沖區中的所有內容寫入到 AOF 檔案，并且同步 AOF 檔案，所以 always 的效率是 appendfsync 選項三個值當中最差的一個，但從安全性來說，也是最安全的，當發生故障停機時，AOF 持久化也只會丟失一個事件回圈中所產生的命令資料，
everysec：Redis 在每個事件回圈都要將 AOF 緩沖區中的所有內容寫入到 AOF 檔案中，并且每隔一秒就要在子執行緒中對 AOF 檔案進行一次同步，從效率上看，該模式足夠快，當發生故障停機時，只會丟失一秒鐘的命令資料，
no：Redis 在每一個事件回圈都要將 AOF 緩沖區中的所有內容寫入到 AOF 檔案，而 AOF 檔案的同步由作業系統控制，這種模式下速度最快，但是同步的時間間隔較長，出現故障時可能會丟失較多資料，

Linux 系統下 write 操作會觸發延遲寫( delayed write )機制，Linux 在內核提供頁快取區用來提供硬碟 IO 性能， write 操作在寫入系統緩沖區之后直接回傳，同步硬碟操作依賴于系統調度機制，例如：緩沖區頁空間寫滿或者達到特定時間周期，同步檔案之前，如果此時系統故障宕機，緩沖區內資料將丟失，

而 fsync 針對單個檔案操作，對其進行強制硬碟同步， fsync 將阻塞直到寫入磁盤完成后回傳，保證了資料持久化，

appendfsync的三個值代表著三種不同的呼叫 fsync的策略，呼叫 fsync周期越頻繁，讀寫效率就越差，但是相應的安全性越高，發生宕機時丟失的資料越少，

有關 Linux 的I/O和各個系統呼叫的作用如下圖所示，具體內容可以查看《聊聊 Linux I/O》一文，

示意圖

AOF 資料恢復

AOF 檔案里邊包含了重建 Redis 資料所需的所有寫命令，所以 Redis 只要讀入并重新執行一遍 AOF 檔案里邊保存的寫命令，就可以還原 Redis 關閉之前的狀態，

示意圖

Redis 讀取 AOF 檔案并且還原資料庫狀態的詳細步驟如下：

創建一個不帶網路連接的的偽客戶端( fake client)，因為 Redis 的命令只能在客戶端背景關系中執行，而載入 AOF 檔案時所使用的的命令直接來源于 AOF 檔案而不是網路連接，所以服務器使用了一個沒有網路連接的偽客戶端來執行 AOF 檔案保存的寫命令，偽客戶端執行命令的效果和帶網路連接的客戶端執行命令的效果完全一樣的，
從 AOF 檔案中分析并取出一條寫命令，
使用偽客戶端執行被讀出的寫命令，
一直執行步驟 2 和步驟3，直到 AOF 檔案中的所有寫命令都被處理完畢為止，

當完成以上步驟之后，AOF 檔案所保存的資料庫狀態就會被完整還原出來，

AOF 重寫

因為 AOF 持久化是通過保存被執行的寫命令來記錄 Redis 狀態的，所以隨著 Redis 長時間運行，AOF 檔案中的內容會越來越多，檔案的體積也會越來越大，如果不加以控制的話，體積過大的 AOF 檔案很可能對 Redis 甚至宿主計算機造成影響，

為了解決 AOF 檔案體積膨脹的問題，Redis 提供了 AOF 檔案重寫( rewrite) 功能，通過該功能，Redis 可以創建一個新的 AOF 檔案來替代現有的 AOF 檔案，新舊兩個 AOF 檔案所保存的 Redis 狀態相同，但是新的 AOF 檔案不會包含任何浪費空間的榮譽命令，所以新 AOF 檔案的體積通常比舊 AOF 檔案的體積要小得很多，

示意圖

如上圖所示，重寫前要記錄名為 list的鍵的狀態，AOF 檔案要保存五條命令，而重寫后，則只需要保存一條命令，

AOF 檔案重寫并不需要對現有的 AOF 檔案進行任何讀取、分析或者寫入操作，而是通過讀取服務器當前的資料庫狀態來實作的，首先從資料庫中讀取鍵現在的值，然后用一條命令去記錄鍵值對，代替之前記錄這個鍵值對的多條命令，這就是 AOF 重寫功能的實作原理，

在實際程序中，為了避免在執行命令時造成客戶端輸入緩沖區溢位，AOF 重寫在處理串列、哈希表、集合和有序集合這四種可能會帶有多個元素的鍵時，會先檢查鍵所包含的元素數量，如果數量超過 REDISAOFREWRITEITEMSPER_CMD ( 一般為64 )常量，則使用多條命令記錄該鍵的值，而不是一條命令，

rewrite的觸發機制主要有一下三個：

手動呼叫 bgrewriteaof 命令，如果當前有正在運行的 rewrite 子行程，則本次rewrite 會推遲執行，否則，直接觸發一次 rewrite，
通過配置指令手動開啟 AOF 功能，如果沒有 RDB 子行程的情況下，會觸發一次 rewrite，將當前資料庫中的資料寫入 rewrite 檔案，
在 Redis 定時器中，如果有需要退出執行的 rewrite 并且沒有正在運行的 RDB 或者 rewrite 子行程時，觸發一次或者 AOF 檔案大小已經到達配置的 rewrite 條件也會自動觸發一次，