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 重寫在處理列表、哈希表、集合和有序集合這四種可能會帶有多個元素的鍵時，會先檢查鍵所包含的元素數量，若是數量超過 REDIS_AOF_REWRITE_ITEMS_PER_CMD ( 通常爲64 )常量，則使用多條命令記錄該鍵的值，而不是一條命令。

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

• 手動調用 bgrewriteaof 命令，若是當前有正在運行的 rewrite 子進程，則本次rewrite 會推遲執行，不然，直接觸發一次 rewrite。
• 經過配置指令手動開啓 AOF 功能，若是沒有 RDB 子進程的狀況下，會觸發一次 rewrite，將當前數據庫中的數據寫入 rewrite 文件。
• 在 Redis 定時器中，若是有須要退出執行的 rewrite 而且沒有正在運行的 RDB 或者 rewrite 子進程時，觸發一次或者 AOF 文件大小已經到達配置的 rewrite 條件也會自動觸發一次。

AOF 後臺重寫

AOF 重寫函數會進行大量的寫入操做，調用該函數的線程將被長時間阻塞，因此 Redis 在子進程中執行 AOF 重寫操做。

• 子進程進行 AOF 重寫期間，Redis 進程能夠繼續處理客戶端命令請求。
• 子進程帶有父進程的內存數據拷貝副本，在不適用鎖的狀況下，也能夠保證數據的安全性。

可是，在子進程進行 AOF 重啓期間，Redis接收客戶端命令，會對現有數據庫狀態進行修改，從而致使數據當前狀態和 重寫後的 AOF 文件所保存的數據庫狀態不一致。

爲此，Redis 設置了一個 AOF 重寫緩衝區，這個緩衝區在服務器建立子進程以後開始使用，當 Redis 執行完一個寫命令以後，它會同時將這個寫命令發送給 AOF 緩衝區和 AOF 重寫緩衝區。

當子進程完成 AOF 重寫工做以後，它會向父進程發送一個信號，父進程在接收到該信號以後，會調用一個信號處理函數，並執行如下工做：

• 將 AOF 重寫緩衝區中的全部內容寫入到新的 AOF 文件中，保證新 AOF 文件保存的數據庫狀態和服務器當前狀態一致。
• 對新的 AOF 文件進行更名，原子地覆蓋現有 AOF 文件，完成新舊文件的替換
• 繼續處理客戶端請求命令。

在整個 AOF 後臺重寫過程當中，只有信號處理函數執行時會對 Redis 主進程形成阻塞，在其餘時候，AOF 後臺重寫都不會阻塞主進程。

後記

後續將會繼續學習 Redis 複製和集羣相關的知識，但願你們持久關注。

我的博客地址: remcarpediem