1.是什么？
以日志的形式來記錄每個寫操作，將redis執行過的所有寫指令記錄下來(讀操作不記錄)，只許追加文件但不可以改寫文件，redis啟動之初會讀取該文件重新構建數據，換言之，redis重啟的話就根據日志文件的內容將寫指令從前到后執行一次以完成數據的恢復工作
2.Aof保存的是appendonly.aof文件
3.開啟AOF的配置位置
4.AOP啟動、修復、恢復
①正常恢復
啟動：設置yes,修改默認的appendonly no,改為yes
將有數據的aof文件復制一份保存到對應目錄(config get dir)
恢復：重啟redis然后重新加載
②異常恢復
啟動：設置yes,修改默認的appendonly no,該為yes
備份被寫壞的AOF文件
修復：redis-check-aof --fix 進行修復
恢復：重啟redis然后重新加載
5.rewrite
①是什么？
AOF采用文件追加的方式，文件會越來越大為避免出現此種情況，新增了重寫機制，當AOF文件的大小超過所設定的閾值時，redis就會啟動AOF文件的內容壓縮，只保留可以恢復數據的最小指令集，可以使用bgrewriteaof
②原理
AOF文件持續增長而過大時，會fork出一條新進程來將文件重寫(也是先寫臨時文件最后再rename)，遍歷新進程的內存中的數據，每條記錄有一條set語句。重寫aof文件的操作，並沒有讀取舊的aof文件，而是將整個內存中的數據庫內容用命令方式重寫了一個新的aof文件，這點和快照有點類似。
③觸發機制
redis會記錄上次重寫時的AOF大小，默認配置是當AOF文件大小是上次rewrite后大小的一倍且文件大於64M時觸發。
6.優勢
每修改同步：appendfsync always 同步持久化 每次發生數據變更會被立即記錄到磁盤 性能較差但數據完整性比較好
每秒同步：appendfsync everysec 異步操作，每秒記錄 如果有一秒內宕機，有數據丟失
不同步：appendfsync no 從不同步
7.劣勢
相同數據集的數據而言aof文件要遠大於rdb文件，恢復速度慢於rdb
aof運行效率要慢於rdb，每秒同步策略效率較好，不同步效率和rdb相同
8.總結
aof的持久化過程
默認情況下，是沒有redis_aof.conf的配置文件的，所以我們需要復制一份，即執行命令cp redis.conf redis_aof.conf，然后我們vim /myredis/redis_aof.conf 進入里面對appendonly no進行修改，改為appendonly yes,然后啟動程序並設置數據，命令如下：
root@ubuntu:/usr/local/bin# redis-server /myredis/redis_aof.conf root@ubuntu:/usr/local/bin# redis-cli -p 6379 127.0.0.1:6379> keys * (empty list or set) 127.0.0.1:6379> set k1 v1 OK 127.0.0.1:6379> set k2 v2 OK 127.0.0.1:6379> set k3 v3 OK 127.0.0.1:6379> FLUSHALL OK 127.0.0.1:6379> SHUTDOWN not connected> exit
此時數據保存至appendonly.aof文件，然后我們打開另外一個新的terminal窗口，用cat appendonly.aof命令如下：
root@ubuntu:/usr/local/bin# cat appendonly.aof *2 $6 SELECT $1 0 *3 $3 set $2 k1 $2 v1 *3 $3 set $2 k2 $2 v2 *3 $3 set $2 k3 $2 v3 *1 $8 FLUSHALL
然后我們再次重啟服務，用keys *查看數據，發現沒有數據，什么原因呢？是因為我們在寫flushall命令的時候一並寫入到了appendonly.aof文件中，如上所示，於是我們進入到appendonly.aof文件中，用命令dd刪除掉flushall，再次重啟，就可以顯示數據，后來我們又用vim appendonly.aof,進入里面瞎寫了一些數據，然后重新啟動服務，會發現
root@ubuntu:/usr/local/bin# redis-server /myredis/redis_aof.conf root@ubuntu:/usr/local/bin# redis-cli -p 6379 Could not connect to Redis at 127.0.0.1:6379: Connection refused not connected>
那是因為剛剛在 appendonly.aof中亂加入一些字符，所以一啟動就報錯，這說明了先啟動aof配置文件(因為dump.rdb沒有進行更改)，同時也說明了兩者可以共存。那么該如何進行修復呢？
root@ubuntu:/usr/local/bin# redis-check-aof --fix appendonly.aof 0x 6e: Expected prefix 'a', got: '*' AOF analyzed: size=151, ok_up_to=110, diff=41 This will shrink the AOF from 151 bytes, with 41 bytes, to 110 bytes Continue? [y/N]: y Successfully truncated AOF
於是，我們重新啟動
root@ubuntu:/usr/local/bin# redis-server /myredis/redis_aof.conf root@ubuntu:/usr/local/bin# redis-cli -p 6379 127.0.0.1:6379> keys * 1) "k3" 2) "k2" 3) "k1"
總結：
RDB持久化方式能夠在指定的時間間隔能對你的數據進行快照存儲。
AOF持久化方式記錄每次對服務器寫的操作，當服務器重啟的時候會重新執行這些命令來恢復原始的數據，AOF命令以redis協議追加保存每次寫的操作到文件末尾，redis還能對AOF文件進行后台重寫，使得AOF文件的體積還不至於過大。
只做緩存：如果你希望你的數據在服務器運行的時候存在，你也可以不使用任何形式的持久化方式。
同時開啟兩種持久化方式：
①在這種情況下，當redis重啟的時候會優先載入AOF文件來恢復原始數據，因為在通常情況下AOF文件保存的數據集要比RDB文件保存的數據集要完整。
②RDB的數據不實時，同時使用兩者時服務器重啟也只會找AOF文件，那要不要使用AOF呢？作者建議不要，因為RDB更適合用於備份數據庫(AOF在不斷變化不好備份)，快速重啟，而且不會有AOF可能潛在的bug，留着作為一個萬一的手段。