Redis 2.4版本做了很多功能改進，尤其是aof這塊變動較大。增加了自動的bgrewriteaof，開啟兩個後臺執行緒來避免主執行緒fsync、rename、close等阻塞操作，另外修復了出現重複命令進入aof檔案的bug，下面是基於2.4.1的原始碼aof這塊的改進分析。

舊的版本問題主要有:

• 1 主執行緒aof的每次fsync(everysecond模式)在高併發下時常出現100ms的延時,這源於fsync必不可少的磁碟操作,即便已經優化多次請求的離散小io轉化成一次大的連續io(sina的同學也反映過這個問題).
• 2 主執行緒裡backgroundRewriteDoneHandler函式在處理bgrewriteaof後臺程序退出的時候存在一個rename new-aof-file old-aof-file,然後再close old-aof-file的操作, close是一個unlink的操作(最後的引用計數), unlink消耗的時間取決於檔案的大小,是個容易阻塞的系統呼叫.
• 3 當發生bgsave或者bgrewriteaof的時候主執行緒和子程序同時寫入不同的檔案,這改變了原有連續寫模式,不同寫入點造成了磁碟磁頭的尋道時間加長(其實一個臺物理機多例項也有這個問題, 要避免同一時間點做bgrewriteaof), 這又加長了fsync時間.

在2.4版裡把fsync和close操作都移動到background來執行.

解決問題1

主執行緒僅僅把aofbuf的資料重新整理到aof檔案裡,然後通過bioCreateBackgroundJob函式往這佇列裡插入fsync job,於是原有主執行緒的fsync工作被轉移到後臺執行緒來做,這樣主執行緒阻塞問題就非同步的解決了.

但這又引發了一個問題,主執行緒對同一個fd如果有write操作,後臺執行緒同時在fsync,這兩個執行緒會互相影響. antirez為此做了一定研究,並給出了簡單的解決方案.

為了避免執行緒的互相影響,主執行緒每次write之前都要檢測一下後臺執行緒任務佇列裡是否有fsync操作,如果有則延遲這次aofbuf的flush,延遲flush這個功能,當然會增大丟資料的可能.

解決缺陷2

backgroundRewriteDoneHandler裡同樣的把close old-aof-file的工作交給backgroud thread來執行.

解決缺陷3

引入了延遲bgrewriteaof

自動的bgrewriteaof

為了避免aof檔案過大，我們會週期性的做bgrewriteaof來重整aof檔案。以前我們會額外的配置crontab在業務低峰期執行這個命令，這額外的增加一個workaroud的指令碼任務在大叢集裡是很糟糕的，不易檢查，出錯無法即時發現。

於是這個自動bgrewriteaof功能被直接加到redis的內部。首先對於aof檔案，server物件新增一個欄位來記錄aof檔案的大小server.appendonly_current_size，每次aof發生變化都會維護這個欄位。

bgrewriteaof完畢或者例項啟動載入aof資料後也會呼叫aofUpdateCurrentSize這個函式維護這個欄位，同時會記錄下此時的aof檔案的大小server.auto_aofrewrite_base_size作為基準值，用於接下來判斷aof增長率。

有了當前值和基準值我們就可以判斷aof檔案的增長情況。另外還需要配置兩個引數來判斷是否需要自動觸發bgrewriteaof。

auto_aofrewrite_perc: aof檔案的大小超過基準百分之多少後觸發bgrewriteaof。預設這個值設定為100，意味著當前aof是基準大小的兩倍的時候觸發bgrewriteaof。把它設定為0可以禁用自動觸發的功能。
auto_aofrewrite_min_size: 當前aof檔案大於多少位元組後才觸發。避免在aof較小的時候無謂行為。預設大小為64mb。
兩個引數都是可以在conf裡靜態配置，或者通過config set來動態修改的。

1. redis 127.0.0.1:6379> config get auto-aof-rewrite-percentage  
2. 1) "auto-aof-rewrite-percentage"  
3. 2) "100"  
4. redis 127.0.0.1:6379> config get auto-aof-rewrite-min-size  
5. 1) "auto-aof-rewrite-min-size"  
6. 2) "1048576"  
7. redis 127.0.0.1:6379> config get auto-aof-rewrite-min-size  
8. 1) "auto-aof-rewrite-min-size"  
9. 2) "1048576"  
10. redis 127.0.0.1:6379> config set auto-aof-rewrite-percentage 200  
11. OK  
12. redis 127.0.0.1:6379> config set auto-aof-rewrite-min-size 10485760  
13. OK  

然後就是觸發檢查的主邏輯，serverCron時間事件中每次都會檢查現有狀態和引數來判斷是否需要啟動bgrewriteaof。

如果aof檔案增長百分率growth大於auto_aofrewrite_perc，則自動的觸發後一個bgrewriteaof。

延遲bgrewriteaof

這是個小的改進，手動觸發的bgrewriteaof的時候如果同時存在bgsave在備份，會推遲這次操走的事件，設定server.aofrewrite_scheduled=1，待到bgsave結束後的下一次serverCron裡才會觸發。