如前面介紹的，aof方式是將執行過的寫指令記錄下來，在資料恢復時按照從前到後的順序再將指令都執行一遍，就這麼簡單。
預設的aof持久化策略是每秒鐘fsync一次（fsync是指把快取中的寫指令記錄到磁碟中），因為在這種情況下，redis仍然可以保持很好的處理效能，即使redis故障，也只會丟失最近1秒鐘的資料。
如果在追加日誌時，恰好遇到磁碟空間滿、inode滿或斷電等情況導致日誌寫入不完整，也沒有關係，redis提供了redis-check-aof工具，可以用來進行日誌修復。
因為採用了追加方式，如果不做任何處理的話，aof檔案會變得越來越大，為此，redis提供了aof檔案重寫（rewrite）機制，即當aof檔案的大小超過所設定的閾值時，redis就會啟動aof檔案的內容壓縮，只保留可以恢復資料的最小指令集。舉個例子或許更形象，假如我們呼叫了100次incr指令，在aof檔案中就要儲存100條指令，但這明顯是很低效的，完全可以把這100條指令合併成一條set指令，這就是重寫機制的原理。
在進行aof重寫時，仍然是採用先寫臨時檔案，全部完成後再替換的流程，所以斷電、磁碟滿等問題都不會影響aof檔案的可用性，這點大家可以放心。
aof方式的另乙個好處，我們通過乙個「場景再現」來說明。某同學在操作redis時，不小心執行了flushall，導致redis記憶體中的資料全部被清空了，這是很悲劇的事情。不過這也不是世界末日，只要redis配置了aof持久化方式，且aof檔案還沒有被重寫（rewrite），我們就可以用最快的速度暫停redis並編輯aof檔案，將最後一行的flushall命令刪除，然後重啟redis，就可以恢復redis的所有資料到flushall之前的狀態了。是不是很神奇，這就是aof持久化方式的好處之一。但是如果aof檔案已經被重寫了，那就無法通過這種方法來恢復資料了。
雖然優點多多，但aof方式也同樣存在缺陷，比如在同樣資料規模的情況下，aof檔案要比rdb檔案的體積大。而且，aof方式的恢復速度也要慢於rdb方式。
如果你直接執行bgrewriteaof命令，那麼redis會生成乙個全新的aof檔案，其中便包括了可以恢復現有資料的最少的命令集。
如果運氣比較差，aof檔案出現了被寫壞的情況，也不必過分擔憂，redis並不會貿然載入這個有問題的aof檔案，而是報錯退出。這時可以通過以下步驟來修復出錯的檔案：
1.備份被寫壞的aof檔案
2.執行redis-check-aof –fix進行修復
3.用diff -u來看下兩個檔案的差異，確認問題點
4.重啟redis，載入修復後的aof檔案
redis持久化 AOF持久化
1.aof持久化原理 aof持久化會將被執行的寫命令寫到aof檔案的末尾。在恢復的時候，redis只要從頭到尾重新執行一次aof檔案包含的所有寫命令 2.配置選項 固態硬碟禁用always選項，在某些情況頻繁讀寫會大大降低固態硬碟的壽命 4.aof檔案的重寫和壓縮 aof檔案裡面記錄了所有的命令而不...
redis持久化之AOF持久化
aof與rdb持久化通過儲存資料庫中的鍵值對來記錄資料庫狀態不同，aof持久化是通過儲存redis伺服器所執行的寫命令來記錄資料庫狀態的。被寫入aof檔案的所有命令都是以redis的命令請求協議格式儲存的。當aof持久化功能處於開啟狀態，伺服器在執行完乙個寫命令之後，會以協議格式將被執行的寫命令追加...
Redis的持久化 AOF
redis的aof持久化策略是將傳送到redis服務端的每一條命令都記錄下來，並且儲存到硬碟中的aof檔案中，類似打日誌檔案，來一條命令就記錄一條。aof設定 aof測試 當客戶端向伺服器傳送一些redis命令時，redis會將所執行的命令記錄到aof檔案中，如下所示 當redis伺服器重啟後，會將...