AOF（Append Only File）

一、是什麼

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

二、Aof儲存的是appendonly.aof檔案

三、配置位置

四、AOF啟動/修復/恢復

1.正常恢復

1）啟動：設定Yes

修改預設的appendonly no，改為yes

2）將有資料的aof檔案複製一份儲存到對應目錄(config get dir)

3）恢復：重啟redis然後重新載入

2.異常恢復

1）啟動：設定Yes

修改預設的appendonly no，改為yes

2）備份被寫壞的AOF檔案

3）修復：

Redis-check-aof --fix進行修復

4）恢復：重啟redis然後重新載入

五、Rewrite

1.是什麼：

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

2.重寫原理

AOF檔案持續增長而過大時，會fork出一條新程序來將檔案重寫(也是先寫臨時檔案最後再rename)，遍歷新程序的記憶體中資料，每條記錄有一條的Set語句。重寫aof檔案的操作，並沒有讀取舊的aof檔案，而是將整個記憶體中的資料庫內容用命令的方式重寫了一個新的aof檔案，這點和快照有點類似

3.觸發機制

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

六、優勢

1.每修改同步：appendfsync always   同步持久化 每次發生資料變更會被立即記錄到磁碟  效能較差但資料完整性比較好

2.每秒同步：appendfsync everysec    非同步操作，每秒記錄   如果一秒內宕機，有資料丟失

3.不同步：appendfsync no   從不同步

七、劣勢

1.相同資料集的資料而言aof檔案要遠大於rdb檔案，恢復速度慢於rdb

2.Aof執行效率要慢於rdb,每秒同步策略效率較好，不同步效率和rdb相同

八、小總結