一、是什么？
- 以日志的形式來記錄每個寫操作，將Redis執行過的所有寫指令記錄下來(讀操作不記錄)，只許追加文件但不可以改寫文件，redis啟動之初會讀取該文件重新構建數據，換言之，redis重啟的話就根據日志文件的內容將寫指令從前到后執行一次以完成數據的恢復工作。
優勢
- 每次修改同步：appendfsync always 同步持久化 每次發生數據變更會被立即記錄到磁盤 ，性能較差但數據完整性比較好。
- 每秒同步：appendfsync everysec 異步操作，每秒記錄 如果一秒內宕機，有數據丟失。
- 不同步：appendfsync no 從不同步。
劣勢
- 相同數據集的數據而言AOF文件要遠大於RDB文件，恢復速度慢於RDB。
- AOF運行效率要慢於RDB，每秒同步策略效率較好，不同步效率和RDB相同。
二、AOF介紹
- 可以同時啟用AOF和RDB持久化，不會出現任何問題。
- 在啟動Redis服務時， 如果啟用了AOF，則Redis將加載AOF文件進行數據恢復，這是是具有更好持久性保證的文件。
三、AOF啟動配置
# 開啟AOF持久化，默認：no，開啟改為 yes
appendonly no
# AOF文件的名字，建議使用默認值。
appendfilename "appendonly.aof"
# Redis支持三種不同的備份模式:
# always：同步持久化 每次發生數據變更會被立即記錄到磁盤 性能較差但數據完整性比較好
# everysec：出廠默認推薦，異步操作，每秒記錄 如果一秒內宕機，有數據丟失
# no：不要fsync，只要讓操作系統在需要的時候刷新數據即可。得更快。
# appendfsync always
appendfsync everysec
# appendfsync no
# 重寫時是否可以運用Appendfsync，用默認no即可，保證數據安全性。
no-appendfsync-on-rewrite no
# 設置重寫的基准值
# 指定百分比為0，以禁用自動AOF重寫特性。
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
四、AOF恢復 (RDB同理)
正常恢復
- 將有數據的AOF文件復制一份保存到對應目錄(config get dir)
- 恢復：重啟redis然后重新加載
異常恢復
- 備份被寫壞的AOF文件
- 修復：執行 redis-check-aof --fix appendonly.aof 進行修復。
- 重啟redis然后重新加載
AOF重寫
是什么？
- AOF采用文件追加的方式，文件會越來越大。為避免出現此種情況，新增了重寫機制，當AOF文件的大小超過所設定的閾值時，Redis就會啟動AOF文件的內容壓縮，只保留可以恢復數據的最小指令集，可以使用命令bgrewriteaof。
重寫原理：
- AOF文件因持續增長而過大時，會fork出一條新進程來將文件重寫(也是先寫臨時文件最后再rename)，遍歷新進程的內存中數據，每條記錄有一條的set語句。重寫AOF文件的操作，並沒有讀取舊的AOF文件，而是將整個內存中的數據庫內容用命令的方式重寫了一個新的aof文件，這點和快照有點類似。
觸發機制：
- Redis會記錄上次重寫時的AOF大小。
- 默認配置是：當AOF文件大小是上次rewrite后大小的一倍且文件大於64M時觸發。
五、總結
- AOF文件是一個只進行追加的日志文件。
- Redis 可以在AOF文件體積變得過大時。自動地在后台對AOF進行重寫。
- AOF文件有序的保存了對數據庫執行的所有寫入操作，這些寫入操作以Redis協議的格式保存，因此AOF文件的內容非常容易被人讀懂，對文件進行分析也很輕松。
- 對於相同的數據集來說，AOF文件的體積通常大於RBD文件的體積。
- 根據所使用的的fsync策略，AOF的速度可能慢於RDB。
