## AOF介紹 Redis提供兩種持久化機制 1. RDB: 將數據庫的快照以二進制的方式保存到磁盤； 2. AOF: 將所有寫入命令及相關參數以協議文本的方式寫入文件并持久保存磁盤。 本文只關心AOF，簡單介紹一下：Redis Server將所有寫入的命令轉換成協議文本的方式寫入AOF文件，例如：Server收到 set key value的的寫入命令，server會進行以下幾步操作： 1. 將命令轉換成協議文本，轉換后的結果：`*3\r\n$3\r\nSET\r\n$3\r\nKEY\r\n$5\r\nVALUE\r\n`； 2. 將協議文本追加到aof緩存，也就是aof_buf； 3. 根據sync策略調用fsync/fdatasync。 到目前為止已經成功保存數據，如果想要還原AOF，只需要將AOF里命令讀出來并重放就可以還原數據庫。 AOF持久化機制存在一個致命的問題，隨著時間推移，AOF文件會膨脹，如果頻繁寫入AOF文件會膨脹到無限大，當server重啟時嚴重影響數據庫還原時間，影響系統可用性。為解決此問題，系統需要定期重寫AOF文件，目前采用的方式是創建一個新的AOF文件，將數據庫里的全部數據轉換成協議的方式保存到文件中，通過此操作達到減少AOF文件大小的目的，重寫后的大小一定是小于等于舊AOF文件的大小。 重寫AOF提供兩種方式 1. REWRITE: 在主線程中重寫AOF，會阻塞工作線程，在生產環境中很少使用，處于廢棄狀態； 2. BGREWRITE: 在后臺（子進程）重寫AOF, 不會阻塞工作線程，能正常服務，此方法最常用。 本文只關心BGREWRITE的問題，因此只介紹此命令的實現機制。 ## AOF后臺Rewrite實現方式 Server收到BGREWRITE命令或者系統觸發AOF重寫時，主進創建一個子進程并進行AOF重寫，主進程異步等待子進程結束（信號量），此時主進程能正常接收處理用戶請求，用戶請求會修改數據庫里數據，會使得當前數據庫的數據跟重寫后AOF里不一致，需要有種機制保證數據的一致性。當前的做法是在重寫 AOF 期間系統會新開一塊內存用于緩存重寫期間收到的命令，在重寫完成以后再將緩存中的數據追加到新的AOF。在處理命令時既要將命令追加到 aof_buf，也要追加到重寫AOF Buffer。 ## AOF后臺Rewrite存在的問題 重寫AOF Buffer是個不限大小的buffer,但用戶寫入的數據量較多時會出現以下兩個問題： 1. 占用過多內存，浪費資源； 2. 主進程將AOF buffer數據寫入到新AOF文件中時會阻塞工作線程，用戶正常請求的延時會變高，嚴重情況下會超時，主備同步也會出問題，斷開重連，重新同步等。 ## AOF后臺Rewrite解決方案 ### 官方解決方案 主要思路是AOF重寫期間，主進程跟子進程通過管道通信，主進程實時將新寫入的數據發送給子進程，子進程從管道讀出數據交緩存在buffer中，子進程等待存量數據全部寫入AOF文件后，將緩存數據追加到AOF文件中，此方案只是解決阻塞工作線程問題，但占用內存過多問題并沒有解決。 ### 新解決方案 主要思路是AOF重寫期間，主進程創建一個新的aof_buf，新的AOF文件用于接收新寫入的命令，sync策略保持不變，在AOF重寫期間，系統需要向兩個aof_buf，兩個AOF文件同時追加新寫入的命令。當主進程收到子進程重寫AOF文件完成后，停止向老的aof_buf，AOF文件追加命令，然后刪除舊的AOF文件(流程跟原來保持一致)；將將子進程新生成的AOF文件重命名為appendonly.aof.last，具體流程如下： 1. 停止向舊的aof_buf，AOF文件追加命令； 2. 刪除舊的的appendonly.aof.last文件； 3. 交換兩個aof_buf，AOF文件指針； 4. 回收舊的aof_buf,AOF文件； 5. 重命令子進程生成的AOF文件為appendonly.aof.last； 系統運行期間同時存在兩個AOF文件，一個是當前正在寫的AOF，另一個是存量的AOF數據文件。因此需要修改數據庫恢復相關邏輯，加載AOF時先要加載存量數據appendonly.aof.last,再加載appendonly.aof。