AOF（Append Only File）

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

AOF 持久化流程

可以在 redis.conf 中組態檔名稱預設為 appendonly.aof 檔案中開啟，AOF 檔案的儲存路徑，同 RDB 的路徑一致。

AOF 和 RDB 同時開啟，系統預設取 AOF 的資料（資料不會存在丟失）。

AOF 的備份機制和效能雖然和 RDB 不同，但是備份和恢復的操作同 RDB 一樣，都是拷貝備份檔案，需要恢復時再拷貝到 Redis 工作目錄下，啟動系統即載入。
正常恢復
- 修改預設的 appendonly no，改為 yes。
- 將有資料的 aof 檔案複製一份儲存到對應目錄 (檢視目錄：config get dir)。
- 恢復：重啟 redis 然後重新載入。
異常恢復
- 修改預設的 appendonly no，改為 yes。
- 如遇到 AOF 檔案損壞，通過 /usr/local/bin/ redis-check-aof–fix appendonly.aof 進行恢復。
- 備份被寫壞的 AOF 檔案。
- 恢復：重啟 redis，然後重新載入。

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

AOF 檔案持續增長而過大時，會 fork 出一條新程序來將檔案重寫 (也是先寫臨時檔案最後再 rename)，redis4.0 版本後的重寫，是指把 rdb 的快照，以二進位制的形式附在新的 aof 頭部，作為已有的歷史資料，替換掉原來的流水賬操作。

no-appendfsync-on-rewrite：

如果 no-appendfsync-on-rewrite=yes ，不寫入 aof 檔案只寫入快取，使用者請求不會阻塞，但是在這段時間如果宕機會丟失這段時間的快取資料。（降低資料安全性，提高效能）
如果 no-appendfsync-on-rewrite=no，還是會把資料往磁碟裡刷，但是遇到重寫操作，可能會發生阻塞。（資料安全，但是效能降低）

Redis 會記錄上次重寫時的 AOF 大小，預設設定是當 AOF 檔案大小是上次 rewrite 後大小的一倍且檔案大於 64M 時觸發。

重寫雖然可以節約大量磁碟空間，減少恢復時間。但是每次重寫還是有一定的負擔的，因此設定 Redis 要滿足一定條件才會進行重寫。

auto-aof-rewrite-percentage：設定重寫的基準值，檔案達到 100% 時開始重寫（檔案是原來重寫後檔案的 2 倍時觸發）。
auto-aof-rewrite-min-size：設定重寫的基準值，最小檔案 64MB。達到這個值開始重寫。
系統載入時或者上次重寫完畢時，Redis 會記錄此時 AOF 大小，設為 base_size,
如果 Redis 的 AOF 當前大小 >= base_size +base_size*100% (預設) 且當前大小 >=64mb (預設) 的情況下，Redis 會對 AOF 進行重寫。
例如：檔案達到 70MB 開始重寫，降到 50MB，下次什麼時候開始重寫？100MB

bgrewriteaof 觸發重寫，判斷是否當前有 bgsave 或 bgrewriteaof 在執行，如果有，則等待該命令結束後再繼續執行；
主程序 fork 出子程序執行重寫操作，保證主程序不會阻塞；
子程序遍歷 redis 記憶體中資料到臨時檔案，使用者端的寫請求同時寫入 aof_buf 緩衝區和 aof_rewrite_buf 重寫緩衝區，保證原 AOF 檔案完整以及新 AOF 檔案生成期間的新的資料修改動作不會丟失；
子程序寫完新的 AOF 檔案後，向主程序發訊號，父程序更新統計資訊。主程序把 aof_rewrite_buf 中的資料寫入到新的 AOF 檔案；
使用新的 AOF 檔案覆蓋舊的 AOF 檔案，完成 AOF 重寫。

備份機制更穩健，丟失資料概率更低。

可讀的紀錄檔文字，通過操作 AOF 穩健，可以處理誤操作。