一、AOF(Append Only File):持久性記錄服務器接收到的每個寫操作。然后可以在服務器啟動時再次重播這些操作，從而重建原始數據集。命令使用與 Redis 協議本身相同的格式進行記錄；注意：AOF文件只會記錄Redis的寫操作命令，因為讀命令對數據的恢復沒有任何意義1、AOF文件說明:*2表示當前命令有2個部分，每部分都是由$+數字開頭，后面緊跟著具體的命令、鍵或值。數字表示這部分中的命令、鍵或值一共有多少字節。例如，$6 SELECT表示這部分有 6 個字節，也就是SELECT命令。
2、AOF日志的生成過程:Redis成功執行寫操作指令，然后將寫的指令按照自定義格式追加到aof_buf緩沖區，這是第一個緩沖區；Redis主進程將aof_buf緩沖區的數據寫入到內核緩沖區，這是第二個緩沖區；根據AOF同步策略適時地將內核緩沖區的數據同步到磁盤，過程結束。①命令傳播：Redis 將執行完的命令、命令的參數、命令的參數個數等信息發送到 AOF程序中。
AOF日志寫入是在Redis成功執行命令之后才進行的，可避免記錄錯誤指令情況，同時不會阻塞當前寫操作。這樣做的風險，如果在寫AOF日志時宕機，會導致指令和相關參數丟失，這種情況一般是寫回磁盤的時機有關，寫回磁盤的頻率越高，發生數據丟失的可能性就越小；另一個風險就是有可能阻塞下一個操作，這個和寫文件方式和時機有關，如果Redis每次成功執行指令之后都力圖將當前指令同步到AOF文件，開銷必然很大。
因此Redis引入了緩沖區的概念，緩沖區對應了文件的寫入方式（不求一步到位，允許循序漸進地寫入），而何時將緩沖區的內容徹底同步到文件就涉及到了AOF的同步策略（寫回磁盤的時機）。②命令追加：在AOF開啟的情況下，Redis會將成功執行的寫指令以上文我們講過的協議格式追加到Redis的aof_buf緩沖區。aof_buf 緩沖區保存著所有等待寫入到AOF 文件的協議文本。
③文件寫入：Redis的主服務進程本質上是一個死循環，循環中有負責接受客戶端的請求，并向客戶端發送回執的邏輯。在AOF功能開啟的情況下，文件事件會將成功執行之后的寫命令追加到aof_buf緩沖區，在主服務進程死循環的最后，會調用flushAppendOnlyFile函數，該函數會將aof_buf中的數據寫入到內核緩沖區，然后判斷是否應該進行同步。而是否進行同步則是由Redis配置中的appendOnlyFile選項來決定的
用戶調用write函數將數據寫入到文件時，操作系統內核會將數據首先保存在內存緩沖區中，等到緩沖區的空間被填滿或者到達一定的時機之后，內核會將數據同步到磁盤。這種同步過于依賴于操作系統內核，操作系統提供了fsync和fdatasync兩個同步函數，可以強制內核立即將緩沖區內的數據同步到磁盤。偽代碼void eventLoop {
while(true){
// ...
// 文件事件，接受命令請求，返回客戶端回執
// 根據aof功能是否開啟，決定是否將寫命令追加到aof_buf緩沖區
handleFileEvents();
// 將aof_buf數據寫入內核緩沖區
// 判斷是否需要將數據同步到磁盤
flushAppendOnlyFile();
// ...
}
};
④文件同步:redis.conf配置文件中appendOnlyFile的選項有三個值可選，對應三種AOF同步策略。
1)No同步時機由內核決定; 寫命令執行完先把日志寫入AOF文件的內核緩沖區，待系統緩存已滿或定期保存機制觸發或Redis或AOF關閉 才同步到磁盤,這個同步是阻塞的。寫入操作也是阻塞的。這個階段宕機由系統內核及運行環境確定，不確定性較大。
2)Everysec每一秒鐘同步一次。也是寫道內核緩存區，間隔1秒同步到磁盤，有子線程執行不會阻塞。
實際運行中該模式對fsync或fdatasync的調用并不是每秒一次，而是和調用flushAppendOnlyFile函數時Redis所處的狀態有關。
flushAppendOnlyFile 函數被調用時， 可能會出現以下四種情況：
子線程正在執行同步，同步的執行時間未超過 2 秒，那么程序直接返回，如宕機，損失數據在2秒內的數據。 子線程正在執行同步，同步已經執行超過 2 秒(超時)，程序執行寫入操作 ，但不執行新的同步操作 。這時的寫入操作必須等待子線程先完成原本的同步操作 ，因此這里的寫入操作會比平時阻塞更長時間，此時宕機，損失數據超過兩秒。
子線程沒有在執行同步，上次成功執行同步距今不超過1秒，那么程序執行寫入，但不執行同步
子線程沒有在執行同步，上次成功執行同步距今已經超過1秒，那么程序執行寫入和同步 3)Always每執行一個命令同步一次。同步操作是由 Redis 主進程執行的，所以在同步執行期間，主進程會被阻塞，不能接受命令請求。
二、AOF文件的載入和數據還原:AOF文件中包含了能夠重建數據庫的所有寫命令，因此將所有命令讀入并依次執行即可還原Redis之前的數據狀態。1、創建一個不帶網絡連接的偽客戶端（fake client），偽客戶端執行命令的效果， 和帶網絡連接的客戶端執行命令的效果完全相同；
2、讀取AOF所保存的文本，并根據內容還原出命令、命令的參數以及命令的個數；
3、根據指令、指令的參數等信息，使用偽客戶端執行命令。
4、執行 2 和 3 ，直到AOF文件中的所有命令執行完畢。
三、AOF重寫:AOF的作用是幫我們還原Redis的數據狀態，其中包含了所有的寫操作，但是正常情況下客戶端會對同一個KEY進行多次不同的寫操作;這樣被頻繁操作的鍵有很多的話，AOF文件的體積就會急速膨脹。
AOF文件的體積受操作系統大小的限制，本身就不能無限增長；體積過于龐大的AOF文件會影響指令的寫入速度，阻塞時間延長；AOF文件的體積越大，Redis數據恢復所需的時間也就越長。
Redis提供了rewrite的AOF重寫功能來精簡AOF文件體積
四、AOF重寫的實現原理:AOF文件的生成是讀取Redis當前的數據狀態來重新生成的.重寫過程是由子進程執行bgrewriteaof來完成的。這樣處理的最大好處是：AOF重寫期間，不影響主進程處理命令請求；子進程帶有主進程的數據副本，操作效率更高.
如果使用線程，在處理共享內存的時候，必須使用同步對象，這樣會影響其性能。
使用子進程，會使用寫時拷貝，fork子進程的時候，子進程會拷貝父進程的頁表，即虛實映射關系，不是物理內存；父子進程一方寫操作，觸發寫時拷貝機制，于是父子進程就有了獨立的數據副本，就不用加鎖來保證數據安全。
fork子進程的過程中，父進程的頁表越大阻塞的時間也越長，不過通常而言該過程是非常快。
fork完子進程后，如果父子進程任意一方修改了共享數據，就會發生**「寫時復制」**，這期間會拷貝物理內存，如果內存越大，自然阻塞的時間也越長；這里復制粒度是一個內存頁，如果只是修改一個256B的數據，父進程需要讀原來的整個內存頁，然后再映射到新的物理地址寫入。一讀一寫會造成讀寫放大。如果內存頁越大（例如2MB的大頁），那么讀寫放大也就越嚴重，對Redis性能造成影響。因此使用Redis的AOF功能時，需要注意頁表的大小不要設置的太大。 子進程在進行 AOF 重寫期間主進程還需要繼續處理命令，而新的命令可能對現有的數據進行修改， 會讓當前數據庫的數據和重寫后的 AOF 文件中的數據不一致，此時Redis引入了另一個緩沖區的概念——AOF重寫緩沖區。
因此當子進程在執行AOF重寫（bgrewriteaof）時， 主進程需要執行以下三個工作：處理客戶端的命令請求；將寫命令追加到AOF緩沖區（aof_buf）；將寫命令追加到AOF重寫緩沖區。
當子進程完成 AOF重寫之后， 它會向父進程發送一個完成信號， 父進程在接到完成信號之后， 會調用一個信號處理函數， 并完成以下工作：
將 AOF重寫緩沖區中的內容全部寫入到新AOF 文件中；完畢之后， 現有 AOF 文件、新 AOF 文件和數據庫三者的狀態就完全一致了
對新的 AOF 文件進行改名，覆蓋原有的 AOF 文件。注意，這是一個原子操作，改名過程中不接受客戶端指令。完畢之后， 程序就完成了新舊兩個 AOF 文件的交替。主進程就可以繼續像往常一樣接受命令請求了。 在整個 AOF 后臺重寫過程中， 只有將AOF重寫緩沖區數據寫入新AOF文件和改名操作會造成主進程阻塞， 其他時候， AOF 后臺重寫都不會對主進程造成阻塞， 這將 AOF 重寫對性能造成的影響降到了最低。
五、AOF后臺重寫觸發條件
1、AOF的其他兩個配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
2、AOF 重寫可以由用戶通過調用 bgrewriteaof手動觸發。
3、服務器在 AOF 功能開啟的情況下， 會維持以下三個變量：
記錄當前 AOF 文件大小的變量 aof_current_size;
記錄最后一次 AOF 重寫之后， AOF 文件大小的變量 aof_rewrite_base_size;
增長百分比變量 aof_rewrite_perc
4、當Redis中的定時函數 serverCron 執行時， 它都會檢查以下條件是否全部滿足， 如果是的話， 就會觸發自動的 AOF 重寫：沒有 bgsave 命令在進行。沒有 bgrewriteaof 在進行。當前 AOF 文件大小大于 我們設置的auto-aof-rewrite-min-size。當前 AOF 文件大小和最后一次 AOF 重寫后的大小之間的比率大于等于指定的增長百分比auto-aof-rewrite-percentage。
默認情況下， 增長百分比為 100% ， 也即是說， 如果前面三個條件都已經滿足， 并且當前 AOF 文件大小比最后一次 AOF 重寫時的大小要大一倍的話， 那么觸發自動 AOF 重寫。
六、總結:
AOF是將Redis的所有寫日志同步到磁盤的一種持久化方法，通過執行AOF中記錄的所有指令可以達到恢復Redis原始數據狀態的目的。
對于指令的同步時機，Redis提供了三種AOF同步策略，分別是No，Everysec，Always，三種策略對Redis性能的負面影響是由低到高的，在數據可靠性上也是由低到高的。
為了解決AOF日志太大的問題，Redis提供了AOF重寫的機制，利用「寫時復制」和「AOF重寫緩沖區」達到精簡AOF文件的目的。