redis持久化之AOF(Append Only File)及其總結

1.是什麼。

以日誌的形式來記錄每個寫操作，將redis執行過的所有寫指令記錄下來(讀操作不記錄)，只許追加檔案但不可以改寫檔案，redis啟動之初會讀取該檔案重新構建資料，換言之，redis重啟的話就根據記錄檔的內容將寫指令從前到後執行一次以完成資料的恢複工作

2.Aof儲存的是appendonly.aof檔案

3.配置位置

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 6379127.0.0.1:6379> keys *(empty list or set)127.0.0.1:6379> set k1 v1 OK127.0.0.1:6379> set k2 v2OK127.0.0.1:6379> set k3 v3OK127.0.0.1:6379> FLUSHALLOK127.0.0.1:6379> SHUTDOWNnot connected> exit

此時資料儲存至appendonly.aof檔案，然後我們開啟另外一個新的terminal視窗，用cat appendonly.aof命令如下：

root@ubuntu:/usr/local/bin# cat appendonly.aof *2$6SELECT$10*3$3set$2k1$2v1*3$3set$2k2$2v2*3$3set$2k3$2v3*1$8FLUSHALL

然後我們再次重啟服務，用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 6379Could not connect to Redis at 127.0.0.1:6379: Connection refusednot 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=41This will shrink the AOF from 151 bytes, with 41 bytes, to 110 bytesContinue? [y/N]: ySuccessfully truncated AOF

於是，我們重新啟動

root@ubuntu:/usr/local/bin# redis-server /myredis/redis_aof.conf root@ubuntu:/usr/local/bin# redis-cli -p 6379127.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，留著作為一個萬一的手段。