AOF檔案： 上面已經多次講過，RDB的快照定時dump機制無法保證很好的資料永續性。如果我們的應用確實非常關注此點，我們可以考慮使用Redis中的AOF機制。對於Redis伺服器而言，其預設的機制是RDB，如果需要使用AOF，則需要修改配置檔案中的以下條目： 將appendonly no改為appendonly yes 從現在起，Redis在每一次接收到資料修改的命令之後，都會將其追加到AOF檔案中。在Redis下一次重新啟動時，需要載入AOF檔案中的資訊來構建最新的資料到記憶體中。 redis.conf：（修改配置的配置檔案） APPEND ONLY MODE: appendonly no --改為yes，redis啟動時會載入AOF appendfilename "appendonly.aof" --aof檔案的名稱，預設不變即可 #appendfsync always #每次有資料修改發生時都會寫入AOF檔案。 appendfsync everysec #每秒鐘同步一次，該策略為AOF的預設策略。 #appendfsync no #從不同步。高效但是資料不會被持久化。 no-appendfsync-on-rewrite no --在預設情況下，當aof進行重寫時，aof的同步資訊不是關閉的。在這種情況下，子程序rewrite（bgrewriteaof命令可進行aof檔案非同步重寫）在寫磁碟，在rewrite的過程中 子程序對主程序造成了磁碟阻塞（disk io衝突），導致了報警資訊的產生。 --但是這個引數修改成 yes之後 ，又會有安全上的問題。因為這時候並沒有執行磁碟操作，只是將命令寫入了緩衝區。當rewrite的過程中 要是redis服務down掉的話 丟失的資料 就不是之前appendfsync 定下的策略。而是整個 rewrite 過程中的所有資料。 auto-aof-rewrite-percentage 100 --重啟後，如果aof檔案當前大小比重啟時增長了百分之100就觸發重寫aof，做整合 auto-aof-rewrite-min-size 64mb --重啟後，如果aof檔案大小達到了64m就觸發重寫，做整合 aof-load-truncated yes --如果aof檔案是被清空了的，重啟時是否過載。有時候會有異常被清空，但是如果人家真的是想清空的，那也是得裝載，所以預設為yes就好。 開始測試：

第一步：按照上面把配置檔案redis.conf修改好，然後啟動redis服務和客戶端（分兩個終端） cd /usr/local/redis ./bin/redis-server redis.conf cd/usr/local/redis ./bin/redis-cli 第二步：在客戶端新建一個key，然後新開終端進/var/redis裡面看是否產生了aof檔案，產生了即AOF持久化生效 set strkey aa 可以看到命令已經存進來了。第一個命令是選擇資料庫，預設為資料庫0。第二條命令就是set strkey aa，其中 *3 表示的是命令由三部分組成。 第三步：重啟伺服器，看key是否還存在 keys * 第四步：設定一個String型別的key，值為2，然後重複incr key命令，看aof檔案內容。 命令如下： set key1 1 incr key incr key .. .. aof內容如下： 可以發現，重複的命令會重複地寫進aof檔案裡面，此時如果我們進行重寫，結果會程式設計什麼樣呢？ 第五步：在客戶端執行bgrewriteaof命令，可進行後臺程序重寫aof。重寫後看看aof檔案內容。 可發現：最後省去所有命令，將key1的最後值賦給key1，即命令set key1 最後值 所以：上面的關於重寫的命令auto-aof-rewrite-percentage，auto-aof-rewrite-min-size都是問了檔案達到了一定的大小就進行重寫，就是對aof檔案進行整合：將多餘的命令都省去，直接改為賦值。