### **一、AOF持久化** AOF（append only file）持久化：以獨立日志的方式記錄每次寫命令，刪除操作，查詢操作不會記錄，以文本的方式記錄，可以打開文件看到詳細的操作記錄， 重啟時再重新執行AOF文件中的命令達到恢復數據的目的。AOF的主要作用 是解決了數據持久化的實時性，目前已經是Redis持久化的主流方式。 **1、工作流程** 1、所有的寫入命令追加到aof\_buf緩沖區中。 2、AOF會根據對應的策略向磁盤做同步操作。由appendfsync參數決定。 3、定期對AOF文件進行重寫。重寫策略由auto-aof-rewrite-percentage，auto-aof-rewrite-min-size兩個參數決定。 ``` appendfsync參數有如下取值： no: don't fsync, just let the OS flush the data when it wants. Faster. 只調用系統write操作，不對AOF文件做fsync操作，同步硬盤操作由操作系統負責，通常同步周期最長為30s。 always: fsync after every write to the append only log. Slow, Safest. 命令寫入到aof\_buf后，會調用系統fsync操作同步到文件中。 everysec: fsync only one time every second. Compromise. 只調用系統write操作，fsync同步文件操作由專門進程每秒調用一次。 默認值為everysec，也是建議值。 ``` **2、觸發機制** 1）手動觸發：直接調用bgrewriteaof命令 2）自動觸發：與auto-aof-rewrite-percentage，auto-aof-rewrite-min-size兩個參數有關。 觸發條件：aof\_current\_size >?auto-aof-rewrite-min-size 并且 (aof\_current\_size? - aof\_base\_size) /?aof\_base\_size >=?auto-aof-rewrite-percentage。其中，aof\_current\_size是當前AOF文件大小，aof\_base\_size 是上一次重寫后AOF文件的大小，這兩部分的信息可從info Persistence處獲取。 **3、重寫與還原** **重寫流程：** ? ?? ?1）執行AOF重寫請求。如果當前進程正在執行bgsave操作，重寫命令會等待bgsave執行完后再執行。 ? ?? ?2）父進程執行fork創建子進程。 ? ?? ?3） fork操作完成后，主進程會繼續響應其它命令。所有修改命令依然會寫入到aof\_buf中，并根據appendfsync策略持久化到AOF文件中。 ? ?? ?4）因fork操作運用的是寫時復制技術，所以子進程只能共享fork操作時的內存數據，對于fork操作后，生成的數據，主進程會單獨開辟一塊aof\_rewrite\_buf保存。 ? ?? ?5）子進程根據內存快照，按照命令合并規則寫入到新的AOF文件中。每次批量寫入磁盤的數據量由aof-rewrite-incremental-fsync參數控制，默認為32M，避免單次刷盤數據過多造成硬盤阻塞。 ? ?? ?6） 新AOF文件寫入完成后，子進程發送信號給父進程，父進程更新統計信息。 ? ?? ?7） 父進程將aof\_rewrite\_buf（AOF重寫緩沖區）的數據寫入到新的AOF文件中。 ? ?? ?8） 使用新AOF文件替換老文件，完成AOF重寫 **4、優缺點** 1）優點 * 該機制可以帶來更高的數據安全性，即數據持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步 * 由于該機制對日志文件的寫入操作采用的是append模式，因此在寫入過程中即使出現宕機現象，也不會破壞日志文件中已經存在的內容 * AOF包含一個格式清晰、易于理解的日志文件用于記錄所有的修改操作。 2）缺點 * 對于相同數量的數據集而言，AOF文件通常要大于RDB文件。RDB 在恢復大數據集時的速度比 AOF 的恢復速度要快 * AOF常用的持久化策略是everysec，在這種策略下，fsync同步文件操作由專門線程每秒調用一次。當系統磁盤較忙時，會造成Redis主線程阻塞。 **5、配置** appendfsync always???? #每次有數據修改發生時都會寫入AOF文件。 appendfsync everysec? #每秒鐘同步一次，該策略為AOF的缺省策略。 appendfsync no????????? #從不同步。高效但是數據不會被持久化