1.是什么？

以日志的形式來記錄每個寫操作，將redis執(zhí)行過的所有寫指令記錄下來(讀操作不記錄)，只許追加文件但不可以改寫文件，redis啟動之初會讀取該文件重新構建數(shù)據(jù)，換言之，redis重啟的話就根據(jù)日志文件的內(nèi)容將寫指令從前到后執(zhí)行一次以完成數(shù)據(jù)的恢復工作

2.Aof保存的是appendonly.aof文件

3.配置位置

4.AOP啟動、修復、恢復

①正?；謴?/p>

啟動：設置yes,修改默認的appendonly no,改為yes

將有數(shù)據(jù)的aof文件復制一份保存到對應目錄(config get dir)

恢復：重啟redis然后重新加載

②異?；謴?/p>

啟動：設置yes,修改默認的appendonly no,該為yes

備份被寫壞的AOF文件

修復：redis-check-aof ?--fix 進行修復

恢復：重啟redis然后重新加載

5.rewrite

①是什么？

AOF采用文件追加的方式，文件會越來越大為避免出現(xiàn)此種情況，新增了重寫機制，當AOF文件的大小超過所設定的閾值時，redis就會啟動AOF文件的內(nèi)容壓縮，只保留可以恢復數(shù)據(jù)的最小指令集，可以使用bgrewriteaof

②原理

AOF文件持續(xù)增長而過大時，會fork出一條新進程來將文件重寫(也是先寫臨時文件最后再rename)，遍歷新進程的內(nèi)存中的數(shù)據(jù)，每條記錄有一條set語句。重寫aof文件的操作，并沒有讀取舊的aof文件，而是將整個內(nèi)存中的數(shù)據(jù)庫內(nèi)容用命令方式重寫了一個新的aof文件，這點和快照有點類似。

③觸發(fā)機制

redis會記錄上次重寫時的AOF大小，默認配置是當AOF文件大小是上次rewrite后大小的一倍且文件大于64M時觸發(fā)

6.優(yōu)勢

每修改同步：appendfsync always 同步持久化 每次發(fā)生數(shù)據(jù)變更會被立即記錄到磁盤 性能較差但數(shù)據(jù)完整性比較好

每秒同步：appendfsync everysec 異步操作，每秒記錄 如果有一秒內(nèi)宕機，有數(shù)據(jù)丟失

不同步：appendfsync no 從不同步

7.劣勢

相同數(shù)據(jù)集的數(shù)據(jù)而言aof文件要遠大于rdb文件，恢復速度慢于rdb

aof運行效率要慢于rdb，每秒同步策略效率較好，不同步效率和rdb相同

8總結

aof的持久化過程

默認情況下，是沒有redis_aof.conf的配置文件的，所以我們需要復制一份，即執(zhí)行命令cp redis.conf redis_aof.conf，然后我們vim /myredis/redis_aof.conf 進入里面對appendonly no進行修改，改為appendonly yes,然后啟動程序并設置數(shù)據(jù)，命令如下：

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
此時數(shù)據(jù)保存至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 *查看數(shù)據(jù)，發(fā)現(xiàn)沒有數(shù)據(jù)，什么原因呢？是因為我們在寫flushall命令的時候一并寫入到了appendonly.aof文件中，如上所示，于是我們進入到appendonly.aof文件中，用命令dd刪除掉flushall，再次重啟，就可以顯示數(shù)據(jù)，后來我們又用vim appendonly.aof,進入里面瞎寫了一些數(shù)據(jù)，然后重新啟動服務，會發(fā)現(xiàn)
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持久化方式能夠在指定的時間間隔能對你的數(shù)據(jù)進行快照存儲。

AOF持久化方式記錄每次對服務器寫的操作，當服務器重啟的時候會重新執(zhí)行這些命令來恢復原始的數(shù)據(jù)，AOF命令以redis協(xié)議追加保存每次寫的操作到文件末尾，redis還能對AOF文件進行后臺重寫，使得AOF文件的體積還不至于過大。

只做緩存：如果你希望你的數(shù)據(jù)在服務器運行的時候存在，你也可以不使用任何形式的持久化方式。

同時開啟兩種持久化方式：

①在這種情況下，當redis重啟的時候會優(yōu)先載入AOF文件來恢復原始數(shù)據(jù)，因為在通常情況下AOF文件保存的數(shù)據(jù)集要比RDB文件保存的數(shù)據(jù)集要完整。

②RDB的數(shù)據(jù)不實時，同時使用兩者時服務器重啟也只會找AOF文件，那要不要使用AOF呢？作者建議不要，因為RDB更適合用于備份數(shù)據(jù)庫(AOF在不斷變化不好備份)，快速重啟，而且不會有AOF可能潛在的bug，留著作為一個萬一的手段。
————————————————
版權聲明：本文為CSDN博主「kfengqingyangk」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權協(xié)議，轉(zhuǎn)載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/kfengqingyangk/article/details/53454309