之前在分析ligty的時候提到，它的
超時處理模型大致如下：
注冊一個處理alarm信號的回調(diào)函數(shù)，然后每秒鐘觸發(fā)一次
回調(diào)函數(shù)每次被觸發(fā)之后，置某個標志位
在服務(wù)器的主循環(huán)中，每次循環(huán)都會檢查這個標志位有沒有被置位，如果有，說明一秒鐘已經(jīng)過去，這時輪詢所有當前處理的連接，刪除超時的連接。
這個模型，最大的問題在于，它的效率與當前連接數(shù)量有很大關(guān)系，數(shù)量大了，輪詢一次的成本很高。
Nginx里面，處理超時連接的模型比之ligty高效了很多：
當前所有可能被觸發(fā)的定時器被保存在紅黑樹這種數(shù)據(jù)結(jié)構(gòu)中，通過紅黑樹，你可以很快的得到距離當前最快發(fā)生的定時器事件的時間差。
將這個時間差作為select/poll/epoll等函數(shù)的參數(shù)，也就是，最多等待這么長時間就返回。
當函數(shù)返回時，得到函數(shù)調(diào)用總共花費了多少時間，根據(jù)這個時間取出紅黑樹的根節(jié)點比較查看是否應(yīng)該觸發(fā)該定時器時間，如果可以則將該定時器從紅黑樹中刪除，然后繼續(xù)查看新的成為樹根的定時器節(jié)點，這個過程一直進行下去直到?jīng)]有定時器滿足被觸發(fā)的條件，也就是還沒有到被觸發(fā)的事件。
Nginx里面，新接收了一個連接，會保存這個連接上來的時間，并且以這個時間來加入紅黑樹定時器中。
可以看到，因為引入了紅黑樹這個數(shù)據(jù)結(jié)構(gòu)，所有的定時器都可以按照順序來依次取出，這樣不用輪詢所有事件來查看是否超時了；而以距離當前最快發(fā)生的定時器事件時間差作為輪詢的定時，又可以不用使用alarm信號來觸發(fā)定時，一舉兩得。
這個處理超時事件的模型，與我之前分析過的
libevent的模型，大體相同，只不過，在那里紅黑樹被堆代替了。