RDB是一種持久化方式，可以透過儲存資料庫中的鍵值對來記錄資料庫的狀態。 AOF 是一種持久化方式，它透過記錄Redis伺服器所執行的寫入命令來保存資料庫狀態。
例如對於以下指令：
RDB 持久化方式就是將str1,str2,str3 這三個鍵值對儲存到RDB檔案中，而AOF 持久化則是將執行的set,sadd,lpush 三個指令儲存到AOF 檔案中。
在redis.conf 設定檔的 APPEND ONLY MODE 下：
appendonly：預設值為no，也就是說redis 預設使用的是rdb方式持久化，如果想要開啟AOF 持久化方式，需要將appendonly 修改為yes。
②、appendfilename ：aof檔名，預設是"appendonly.aof"
③、appendfsync：aof持久化策略的設定；
no表示不執行fsync，由作業系統保證資料同步到磁碟，速度最快，但較不安全； always表示每次寫入都會執行fsync，以保證資料同步fsync，以保證資料同步fsync，以保證資料都執行fsync，以保證資料同步使用到磁碟，效率很低；一秒執行一次fsync的選項"everysec"可能會導致資料在這1秒內遺失。通常選擇 everysec ，兼顧安全性和效率。 ④、no-appendfsync-on-rewrite：在aof重寫或寫入rdb檔案的時候，會執行大量IO，此時對於everysec和always的aof模式來說，執行fsync會造成阻塞過長時間，no-appendfsync-on-rewrite欄位設定為預設為no。如果對延遲要求很高的應用，這個欄位可以設定為yes，否則還是設定為no，這樣對持久化特性來說這是更安全的選擇。 設定為yes表示rewrite期間對新寫入操作不fsync,暫時存在記憶體中,等rewrite完成後再寫入，預設為no，建議yes。 Linux的預設fsync策略是30秒。可能遺失30秒資料。預設值為no。 auto-aof-rewrite-percentage的預設值是100。 aof自動重寫配置，噹噹前aof檔案大小超過上一次重寫的aof檔案大小的百分之多少進行重寫，即當aof檔案成長到一定大小的時候，Redis能夠調用bgrewriteaof對日誌檔案進行重寫。當AOF檔案的大小達到上次進行日誌重寫時的兩倍（設定為100）時，將自動啟動新的日誌重寫過程。 auto-aof-rewrite-min-size設定為64MB。為了避免在達到了約定百分比時仍需要進行重寫，可以設定最小的aof檔案大小。 ⑦、aof-load-truncated：aof檔案可能在尾部是不完整的，當redis啟動的時候，aof檔案的資料被載入記憶體。重啟可能發生在redis所在的主機作業系統宕機後，尤其在ext4檔案系統沒有加上data=ordered選項，出現這種現象 redis宕機或異常終止不會造成尾部不完整現象，可以選擇讓redis退出，或導入盡可能多的數據。一旦選擇了yes選項，在截斷的aof檔案被匯入時，將自動向客戶端發送日誌並進行載入。若答案是否定的，使用者需手動執行redis-check-aof指令以修復AOF檔。預設值為 yes。 3、開啟 AOF 將 redis.conf 的 appendonly 設定改為 yes 即可。 AOF 儲存檔案的位置和RDB 儲存檔案的位置一樣，都是透過redis.conf 設定檔的dir 設定：
1 |
|
也就是說AOF 檔案重寫並不是對原始檔案進行重新整理，而是直接讀取伺服器現有的鍵值對，然後用一條命令去代替先前記錄這個鍵值對的多個命令，產生一個新的檔案後去替換原來的AOF 檔。
AOF 檔案重寫觸發機制：透過redis.conf 設定檔中的auto-aof-rewrite-percentage：預設值為100，以及auto-aof-rewrite-min-size：64mb 設定，也就是說預設Redis會記錄上次重寫時的AOF大小，預設設定是當AOF檔案大小是上次rewrite後大小的一倍且檔案大於64M時觸發。
這裡再提一下，我們知道Redis 是單執行緒工作，如果重寫AOF 需要更長的時間，那麼在重寫AOF 期間，Redis將長時間無法處理其他的命令，這顯然是不能忍受的。 Redis為了克服這個問題，解決方法是將AOF 重寫程式放到子程式中進行，這樣有兩個好處：
①、子進程進行AOF 重寫期間，伺服器進程（父進程）可以繼續處理其他指令。 使用子程序而不是線程，可以避免使用鎖的情況下，並保證資料的安全性，因為子程序帶有父程序的資料副本。 使用子程序解決了上面的問題，但是新問題也產生了：因為子進程在進行AOF 重寫期間，伺服器進程依然在處理其它命令，這新的命令有可能也對資料庫進行了修改操作，使得目前資料庫狀態和重寫後的AOF 檔案狀態不一致。 為了解決這個資料狀態不一致的問題，Redis 伺服器設定了一個AOF 重寫緩衝區，這個緩衝區是在建立子程序後開始使用，當Redis伺服器執行一個寫入指令之後，就會將這個寫入指令也會傳送到AOF 重寫緩衝區。當子進程完成 AOF 重寫之後，就會給父進程發送一個訊號，父進程接收此訊號後，就會呼叫函數將 AOF 重寫緩衝區的內容都寫到新的 AOF 檔案中。 這樣將 AOF 重寫對伺服器造成的影響降到了最低。 6、AOF的優缺點 優點： ①、AOF 持久化的方法提供了多種的同步頻率，即使使用預設的同步頻率每秒同步一次，Redis 最多也就會遺失1 秒的資料而已。 ②、AOF 檔案使用 Redis 指令追加的形式來構造，因此，即使 Redis 只能向 AOF 檔案寫入指令的片斷，使用 redis-check-aof 工具也很容易修正 AOF 檔案。 AOF檔案的格式很容易閱讀，這使得使用者可以更靈活地處理它們。例如，如果我們不小心錯用了 FLUSHALL 指令，在重寫還沒進行時，我們可以手動將最後的 FLUSHALL 指令去掉，然後再使用 AOF 來恢復資料。 缺點： ①、對於具有相同資料的的 Redis，AOF 檔案通常會比 RDF 檔案體積更大。 AOF預設的每秒同步一次頻率雖然提供了多種同步頻率選項，但效能依然較高。在 Redis 負載較高時，RDB提供了比AOF更好的效能保證。 ③、RDB 使用快照的形式來持久化整個 Redis 數據，而 AOF 只是將每次執行的命令追加到 AOF 文件中，因此從理論上說，RDB 比 AOF 方式更健壯。根據官方文件指出，AOF 存在著一些 RDB 沒有的 BUG。 那麼對於 AOF 和 RDB 兩種持久化方式，我們該如何選擇呢？ 如果可以忍受一小段時間內資料的遺失，毫無疑問使用RDB 是最好的，定時產生RDB 快照（snapshot）非常便於進行資料庫備份， 並且RDB 還原資料集的速度也要比AOF 恢復的速度要快，使用RDB 還可以避免AOF 一些隱藏的bug；否則就使用AOF 重寫。但一般情況下建議不要單獨使用某一種持久化機制，而是應該兩種一起用，在這種情況下,當redis重啟的時候會優先載入AOF檔來恢復原始的數據，因為在通常情況下AOF檔案保存的資料集比RDB檔案保存的資料集要完整。或許在未來，Redis官方會將兩種持久化方式合併成持久化模式。以上是Redis中AOF持久化的範例分析的詳細內容。更多資訊請關注PHP中文網其他相關文章！
