上篇我們講到redis的rdb持久化操作，有一個問題就是在1分鐘間隔中突然斷電，造成這段間隔的資料沒有持久化到磁碟中，造成資料丟失。
解決辦法就是用redis的aof(append only file)做日誌持久化。簡單說就是把每一條操作命令都寫到檔案中，下次恢復的時候重新執行這些命令就做到了資料恢復。具體配置還是在redis.conf中：

appendonly yes #是否僅要日誌
appendfsync no # 系統緩衝,統一寫,速度快
appendfsync always # 系統不緩衝,直接寫,慢,丟失資料少
appendfsync everysec #折中,每秒寫1次

appendonly是否開啟aof服務，appendfsync則是將操作命令寫入到檔案的頻率（no表示由系統緩衝決定什麼時候aof，always則是每執行一條命令就寫入日誌檔案中，效率不高，everysec每秒寫一次）。

no-appendfsync-on-rewrite no #正在匯出rdb快照的過程中,要不要停止同步aof

在做rdb的時候停止aof，節省io。那麼你會問，rdb一般持久化很大的資料，比如幾十個G，肯定需要很多時間來做這個操作，停止同步aof，那這個過程的資料不就沒有了？答案是否定的，因為這個過程中所有的操作快取在記憶體的佇列裡, rdb完成後,統一操作。

appendfilename ./appendonly.aof  #檔案路徑

上述aof的基本配置就完成了。我們在配置aof頻率的時候採用折中的方法，沒過一秒aof一次，這樣即使丟資料也只丟失了一秒的資料，相比rdb好了很多。（注意rdb和aof一般都是可以同時開啟的）
但是又有一個問題，比如：

incr number  // 1
incr number //  2
incr number //  3
...

一個key被重複aof了多次，命名就是set number 3一條命令就可以完成的，卻寫入了多次，這樣勢必會造成aof檔案過大，這個時候就需要aof重寫。

auto-AOF-rewrite-percentage 100 當前aof檔案是上次重寫是大N%時重寫
auto-AOF-rewrite-min-size 64mb aof重寫至少要達到的大小

上述就是配置aof重寫的引數。重寫後aof檔案體積會明顯變小，原因就類似上述例子，將一條命令逆化成一條命令。
要做aof重寫測試還是可以用./bin/redis-benchmark來模擬命令。或者直接用beginwriteaof命令來直接重寫。
總結：這兩篇我們大致講了redis的兩種持久化方式rdb和aof，一般我們都是一起使用。rdb持久化間隔時間長，因為要將大量資料持久化到磁碟中，但是恢復速度快，因為都是二進位制檔案。aof安全，因為可以設定命令的寫入日誌檔案的頻率，比如每條命令都寫入，安全性高，但是效率相對低。