上一篇中，我們說了Redis持久化中的RDB。今天，我們詳細學習一下AOF持久化機制的實戰。

一、如何配置AOF持久化機制

預設情況下，redis是不開啟AOF持久化的。我們需要手動將配置檔案中的appendonly改成yes，表示開啟AOF持久化機制。在生產環境中，一般來說都會開啟AOF，除非是說隨便丟個幾分鐘的資料也無所謂。

開啟AOF持久化機制之後，redis每次接收到一條寫命令，就會寫入日誌檔案中，當然是先寫入os cache，然後每隔一定時間再fsync一下。而且即使AOF和RDB都開啟了，redis重啟的時候，也是優先通過AOF進行資料恢復的，因為aof資料比較完整。

對於AOF的fsync策略，有三種策略可以選擇：

（1）always：每次寫入一條資料，立即將這個資料對應的寫日誌fsync到磁碟上去，效能非常非常差，吞吐量很低; 確保說redis裡的資料一條都不丟，那就只能這樣了。

（2）everysec： 每秒將os cache中的資料fsync到磁碟，這個最常用的，生產環境一般都這麼配置，效能很高，QPS還是可以上萬的。（預設）

（3）no：僅僅redis負責將資料寫入os cache就撒手不管了，然後後面os自己會時不時有自己的策略將資料刷入磁碟，不可控了。

二、實戰

1、驗證AOF持久化已經在起作用了。

（1）我們先刪除dump.rdb和appendonly.aof檔案。寫入k1，然後通過kill -9殺死程序。

（2）可以看到重新生成了appendonly.aof檔案，此時我們重啟redis服務，看k1的值是否被持久化。（可以看到k1的值被持久化，而該值就是從AOF檔案恢復回來的。）

2、驗證redis啟動時，是從AOF檔案恢復持久化資料，而非dump.rdb。

（1）我們在設定一個k2的值，然後通過redis-cli SHUTDOWN停掉redis程序。

（2）重啟redis服務，此時dump.rdb和appendonly.aof都記錄了k2的值，無法看出redis重啟是否是從aof中恢復的。那麼我們再寫入k3，然後通過kill -9殺死redis程序。（我們知道用kill方式殺死程序，持久化資料是不會被寫進dump.rdb中的）

（3）重啟redis服務，看下k3是否被持久化，若被持久化，則可驗證redis啟動時，從aof檔案中恢復資料。