參考：《Redis設計與實現》
文章目錄
1、AOF文件作用
AOF持久化是通過保存Redis服務器所執行的寫命令來記錄數據庫狀態（服務器中非空數據庫以及它們的鍵值對）的。被寫入AOF文件的所有命令都是以Redis的命令請求協議格式來保存的，Redis命令請求協議是純文本格式。
服務器在啓動的時候，通過載入和執行 AOF文件中保存的命令來還原服務器關閉之前的數據庫狀態。
2、AOF持久化實現
1、命令追加
當AOF持久化功能處於打開狀態時，服務器在執行完一個寫命令之後，會以協議格式將執行的寫命令追加到服務器的aof_buf緩衝區末尾
2、AOF文件寫入和同步
這一章看下來其實還是會有不理解的地方，比如說寫入和同步的區別是什麼，所以就從網上找了答案，因爲對OS不熟悉，正常熟悉OS應該是理解這一步所講述的纔對。 參考地址：SegmentFault
在AOF持久化的過程中，其實上是分成兩個部分:
- WRITE（寫入）：根據條件，將 aof_buf 中的緩存寫入到 AOF 文件。
- SAVE（同步）：根據條件，調用 fsync 或 fdatasync 函數，將 AOF 文件保存到磁盤中。
服務器在處理文件時間時可能會執行寫命令，把一些內容追加到aof緩衝區，所以在服務器每結束一次事件循環（負責節後客戶端的命令請求，以及向客戶端發送命令回覆）之前，都會調用flushAppendOnlyFile函數，考慮是否把aof緩衝區的內容寫入和保存到AOF文件中。
flushAppendOnlyFile的行爲由服務器配置的appendfsync選項決定，這個選項對應的參數和含義：
| 參數值 | 含義 |
|---|---|
| always | 每次寫入aof_buf緩衝區都把內容寫入和同步到AOF文件 |
| everysec(默認) | 如果上次同步AOF文件的時間距離超過一秒，對AoF文件進行同步（由專門的線程進行負責） |
| no | 將aof_buf緩衝區內容寫入AOF文件，但是不對AOF文件進行同步，由系統來決定 |
redis默認的文件同步配置是everysec，也就是說每隔一秒對AOF文件進行一次同步，這樣做主要是爲了在效率（執行同步需要消耗cpu時間）和安全（文件丟失）之間取得一個平衡，在服務器出現故障的情況下，最多丟失一秒的數據。
3、AOF文件載入與數據還原
AOF文件中包含重建數據庫狀態的所有寫命令，所以服務器只要讀入並重新執行一遍AOF文件保存的寫命令，就可以還原關閉前的數據庫狀態。
文件載入還原的操作過程圖示：
4、AOF重寫（BGREWRITEAOF）
1、AOF重寫的必要性
主要包含下面兩個原因，歸納總結：
- 隨着服務器運行時間的流逝，AOF文件體積會逐步變大，這就造成可能對Redis服務器的影響以及數據狀態還原的時間變長
- 隨着服務器運行時間的流逝，對於一個redis鍵值對的修改可能包含不止一條命令，而可以把命令進行壓縮成一條，所以過多的命令是表達過程，而不是結果
2、AOF重寫的實現
1、特點
AOF重寫實現的特點：
- 不需要對現有的AOF文件進行任何讀取、分析或者寫入操作
- 直接從redis數據庫的鍵值對生成對應的redis命令(比如說之前的操作是三個命令添加了10個值,而這種方式可以直接通過一條命令去生成這個鍵值對的最終狀態)
- 爲了防止客戶端輸入緩衝區溢出，如果元素超過redis.h/REDIS_AOF_REWRITE_ITEMS_FER_CMD配置的常量值，重寫程序就會用多條命令來記錄鍵的值
2、子進程處理
redis不希望AOF重寫的時候無法處理請求，所以redis把AOF重寫放在子進程中執行，這樣做可以同時達到兩個目的：
- 子進程在進行AOF重寫期間，服務器進程可以繼續執行命令請求
- 子進程攜帶父進程的數據副本，使用子進程而不是線程，可以在避免使用鎖的情況下，保證數據的安全性
3、AOF重寫緩衝區
子進程在進行AOF重寫的時候，服務器進程還需要繼續處理命令，新的命令會對現在的數據庫狀態進行修改，導致當前的數據庫狀態和AOF重寫之後的狀態不一致。
爲了解決上述的不一致問題，redis設置了一個AOF重寫緩衝區，在執行一個寫命令的時候會同時把該命令發送給AOF緩衝區和AOF重寫緩衝區。主要是爲了保證兩個操作都能正常完成：
- AOF緩衝區內容可以定期寫入並同步到AOF文件
- 創建子進程之後，服務器處理的命令會寫入到AOF重寫緩衝區
4、新AOF文件生成處理
當AOF重寫工作完成之後，子進程會向服務器進程發送一個信號，這個時候就會觸發AOF新文件生成的操作，分爲兩步：
- 將AOF重寫緩衝區的所有內容寫入到新的AOF文件中，
- 對新的AOF文件進程改名，原子性的覆蓋現有的AOF文件，完成新舊文件的替換