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。