redis提供了兩種持久化機制，rdb和aof。

關於aof的原理，類似於預寫日誌，不再解釋。其中幾個選項如下：

appendfsync always：總是寫入aof檔案，並完成磁碟同步
appendfsync everysec：每一秒寫入aof檔案，並完成磁碟同步

appendfsync no：寫入aof檔案，不等待磁碟同步。

可見，從持久化角度講，always是最安全的。從效率上講，no是最快的。而redis預設設定進行了折中，選擇了everysec。合情合理。

bgrewriteaof機制，在一個子程序中進行aof的重寫，從而不阻塞主程序對其餘命令的處理，同時解決了aof檔案過大問題。

現在問題出現了，同時在執行bgrewriteaof操作和主程序寫aof檔案的操作，兩者都會操作磁碟，而bgrewriteaof往往會涉及大量磁碟操作，這樣就會造成主程序在寫aof檔案的時候出現阻塞的情形，現在no-appendfsync-on-rewrite引數出場了。如果該引數設定為no，是最安全的方式，不會丟失資料，但是要忍受阻塞的問題。如果設定為yes呢？這就相當於將appendfsync設定為no，這說明並沒有執行磁碟操作，只是寫入了緩衝區，因此這樣並不會造成阻塞（因為沒有競爭磁碟），但是如果這個時候redis掛掉，就會丟失資料。丟失多少資料呢？在linux的作業系統的預設設定下，最多會丟失30s的資料。

因此，如果應用系統無法忍受延遲，而可以容忍少量的資料丟失，則設定為yes。如果應用系統無法忍受資料丟失，則設定為no。