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相同
八、小總結
