AOF定義：以日志的形式記錄每個操作，將Redis執行過的所有指令全部記錄下來（讀操作不記錄），只許追加文件但不可以修改文件，
Redis啟動時會讀取AOF配置文件重構數據，換句話說，就是Redis重啟就會根據日志內容從頭到尾執行一次來完成數據的恢復工作。
注:
一.RDB與AOF同時開啟 默認只加載AOF的配置文件恢復數據
二.相同數據集，AOF文件要遠大於RDB文件，恢復速度慢於RDB
三.AOF運行效率慢於RDB,但是同步策略效率好，不同步效率和RDB相同
在5.x版本中，AOF文件做了優化，內容為：頭部為RDB文件，尾部為增量寫的命令：
aof-use-rdb-preamble yes
1.RDB持久化(以快照的方式) 策略（默認）：
save 900 1 （15分鍾變更一次） save 300 10 （5分鍾變更10次） save 60 10000 （1分鍾變更1萬次）
2.RDB默認配置文件名稱：
dbfilename dump.rdb
3.表示是否開啟AOF持久化：
appendonly yes(默認no,關閉)
4.AOF持久化配置文件的名稱：
appendfilename "appendonly.aof"
5.AOF持久化策略(默認everysec)：
appendfsync always (同步持久化，每次發生數據變更會被立即記錄到磁盤，性能差但數據完整性比較好) appendfsync everysec (異步操作，每秒記錄，如果一秒鍾內宕機，有數據丟失) appendfsync no （將緩存回寫的策略交給系統，don't fsync, just let the OS flush the data when it wants ）
6.AOF配置文件損壞修復方法：
進入redis安裝路徑 執行:
redis-check-aof --fix AOF配置文件名稱
7.AOF的Rewrite(重寫) ：
定義：AOF采用文件追加的方式持久化數據，所以文件會越來越大，為了避免這種情況發生，增加了重寫機制
當AOF文件的大小超過了配置所設置的闕值時，Redis就會啟動AOF文件壓縮，只保留可以恢復數據的最小指令集，可以使用命令bgrewriteaof
原理：當AOF增長過大時，會fork出一條新的進程將文件重寫(也是先寫臨時文件最后rename)，遍歷新進程的內存數據，每條記錄有一條set語句。
重寫AOF文件並沒有操作舊的AOF文件，而是將整個內存中的數據內容用命令的方式重寫了一個新的aof文件（有點類似快照）
重寫觸發機制：Redis會記錄上次重寫時的AOF文件大小，默認配置時當AOF文件大小是上次rewrite后大小的一倍且文件大於64M時觸發
auto-aof-rewrite-percentage 100 （一倍） auto-aof-rewrite-min-size 64mb
8.RDB與AOF的選擇：
做備份：當數據量大，且對恢復速度有要求，並且數據的一致性要求不高的話，可以只使用RDB
只做緩存：不用開啟任何的持久化方式
兩者都開啟的建議：RDB數據不實時，同時使用兩者時服務器只會找AOF文件，可不可以只使用AOF?建議不要，因為RDB更適合備份數據庫(AOF在不斷變化，不好備份)，快速重啟，而且不會有AOF可能潛在的BUG,留作萬一的手段。
9.優化：
1. 因為RDB文件只用作后備用途，建議只在從節點上持久化RDB文件，而且只要15分鍾備份一次就夠了（只保留save 900 1這條規則）。
2. 如果開啟AOF，好處是在最惡劣的情況下也只會丟失不超過兩秒的數據，啟動腳本簡單，load自己的AOF文件就可以了。
代價：
（1） 帶來了持續的IO
（2）重寫過程中產生的新數據寫到新文件造成的阻塞幾乎是不可避免的。
3.只要硬盤許可，應該盡量減少AOF重寫的頻率，AOF重寫的默認基礎大小為64M太小了，可以改成5G以上，默認超過原大小100%這個配置可以改成適當的數值。
4.如果不開啟AOF,僅靠主從模式實現高可用性能也可以，能省掉一大筆IO，也減少了重寫時帶來的系統波動，
代價：
（1）主從同時宕掉，會丟失十幾分鍾的數據。
（2）啟動腳本要比較兩個主/從中的RDB文件，載入較新的那個