本文基於Nginx 0.8.55原始碼，並基於epoll機制分析
對於nginx而言，事件機制的處理無非就是幾個部分：
- 網路IO事件的處理
- 檔案IO事件的處理
- 定時器事件的處理
（當然還有許多其他的不過我現在並不是很關心。。）
我在讀Nginx定時器事件相關的程式碼時看到了很多有趣的設計和考量，感覺還是值得寫一寫的，當然大佬們可能司空見慣了……嘛。
1. nginx的時間快取
首先，由於較早期的Linux中，gettimeofday()本身是一個系統呼叫，對它的頻繁呼叫會有比較大的開銷，因此，Nginx採用了在本地快取時間的做法。
Nginx是用幾個全域性變數來快取時間的：
volatile ngx_msec_t ngx_current_msec;
volatile ngx_time_t *ngx_cached_time;
volatile ngx_str_t ngx_cached_err_log_time;
volatile ngx_str_t ngx_cached_http_time;
volatile ngx_str_t ngx_cached_http_log_time;
複製程式碼從命名和型別也能看出來，Nginx給各個模組提供了各種型別的快取變數，以供其他需要呼叫ngx_time()和ngx_timeofday()的模組提供當前時間，從而避免了gettimeofday()等系統呼叫的開銷（當然，較新版本的Linux中gettimeofday()已經不是傳統意義上的系統呼叫了，但是比較新的Nginx原始碼我也沒看……）
Nginx還提供了幾個佇列來快取時間的更新歷史：
static ngx_time_t cached_time[NGX_TIME_SLOTS];
static u_char cached_err_log_time[NGX_TIME_SLOTS]
[sizeof("1970/09/28 12:00:00")];
static u_char cached_http_time[NGX_TIME_SLOTS]
[sizeof("Mon, 28 Sep 1970 06:00:00 GMT")];
static u_char cached_http_log_time[NGX_TIME_SLOTS]
[sizeof("28/Sep/1970:12:00:00 +0600")];
複製程式碼事實上上面那些快取變數的實際值最終都指向了這些佇列中的值，不過我grep了一下原始碼，這些佇列好像也沒在別處派上用場…所以對他們也不詳細介紹了，簡而言之就是Nginx維護了一個slot全域性變數，每次在ngx_time_update函式中呼叫gettimeofday()獲取當前時間，在佇列後插入新時間然後移動slot來指示當前快取值，並且把ngx_cache_time等指標指向最新的cache_time[slot]就行了。
具體可以看ngx_time_update()的實現即可。
2. Nginx何時更新快取
這裡我們主要關注的問題是，Nginx更新時間快取的時機是什麼時候呢？
當然初啟動和cycle的初始化有幾次更新的時機，這裡我們主要考慮事件處理過程中時間更新的時機。
這裡Nginx給出了兩種不同的解決方案，由ngx_time_resolution變數決定：
- 在
ngx_timer_resolution為0的時候，Nginx會在每次呼叫epoll_wait後進行一次時間快取的更新 - 在
ngx_timer_resolution不為0的時候，這個值代表著時間精度，即“多長時間更新一次快取”，這時候Nginx會在時間模組初始化的時候設定定時器，讓定時器的中斷時間為ngx_timer_resolution規定的毫秒數，每觸發一次SIGALRM訊號，就呼叫一次ngx_time_update()。
當然，我們斷然不會允許訊號處理函式本身佔用過多的CPU時間，所以其訊號處理函式的實現非常簡單：
void
ngx_timer_signal_handler(int signo)
{
ngx_event_timer_alarm = 1;
#if 1
ngx_log_debug0(NGX_LOG_DEBUG_EVENT, ngx_cycle->log, 0, "timer signal");
#endif
}
複製程式碼而真正呼叫ngx_time_update()則是在ngx_process_events()中：
static ngx_int_t
ngx_epoll_process_events(ngx_cycle_t *cycle, ngx_msec_t timer, ngx_uint_t flags)
{
int events;
uint32_t revents;
ngx_int_t instance, i;
ngx_uint_t level;
ngx_err_t err;
ngx_log_t *log;
ngx_event_t *rev, *wev, **queue;
ngx_connection_t *c;
/* NGX_TIMER_INFINITE == INFTIM */
ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0,
"epoll timer: %M", timer);
// 呼叫epoll_wait
events = epoll_wait(ep, event_list, (int) nevents, timer);
err = (events == -1) ? ngx_errno : 0;
// 這裡時更新時間的時機之一
// 如果SIGALRM的回撥函式被呼叫，那麼ngx_event_timer_alarm設為1，此時更新時間
if (flags & NGX_UPDATE_TIME || ngx_event_timer_alarm) {
ngx_time_update();
}
if (err) {
if (err == NGX_EINTR) {
// 如果是被時鐘中斷，那麼返回NGX_OK
if (ngx_event_timer_alarm) {
ngx_event_timer_alarm = 0;
return NGX_OK;
}
level = NGX_LOG_INFO;
} else {
level = NGX_LOG_ALERT;
}
ngx_log_error(level, cycle->log, err, "epoll_wait() failed");
return NGX_ERROR;
}
/* 省略處理事件的程式碼 */
}
複製程式碼這裡我們可以看到，函式中首先會檢查一下flag引數的NGX_UPDATE_TIME標誌位，這是ngx_timer_resolution為0的時候才會設定的位，表示每次事件處理都會更新時間快取。而這之外的情況則是ngx_timer_resolution不為0，由軟中斷設定標誌位才會觸發時間快取的更新。
這裡也處理了當epoll_wait被訊號中斷的情況，如果錯誤正好是EINTR且ngx_event_timer_alarm正好為1，那麼就認為是該訊號中斷了epoll_wait，並把ngx_event_timer_alarm清0。
3. 定時事件的組織方式
對於定時事件，或者超時事件的處理，我們有一個非常簡單的直覺：給每個定時事件註冊一個定時器，在定時器回撥中去處理過期事件不就好了？程式碼寫起來多簡單，要是再有個lambda表示式……
可惜不行 ，系統底層提供的定時器數量肥腸有限，不過我們倒是可以把API設計成這樣……扯遠了。
Nginx這裡採用了一個很簡單而有效的策略：選擇一個合適的時機，儘可能地檢查最近要過期的事件是不是已經過期，有的話就處理，沒有的話就跳過。
那麼維護一個可以很快取得“最近要過期的結構”就顯得很重要了，而且在繁複的事件處理過程中，定時事件會隨機地插入，所以簡單的佇列也無法勝任——這個時候熟悉資料結構的同學可能很快就想到了紅黑樹。
沒錯，Nginx就是採用紅黑樹來管理定時事件（或者我們叫他超時事件）。以到期時間為key管理這顆紅黑樹，那麼紅黑樹中最左邊的事件就是即將超期的事件。而當事件的消費者要插入事件，消費完之後要刪除事件，包括尋找即將超期的事件，這些操作的時間複雜度都控制在O(logN)內，效率是相當高的。（關於紅黑樹這種資料結構的細節，請參考資料結構的專著）
這是Nginx管理超時事件的基調。具體的程式碼實現可以參照src/event/ngx_event_timer.c的三個函式，基本上就是一些紅黑樹的增刪改查然後調回撥啊之類的。
4. 處理定時事件的時機
超時事件的處理時機，當然還是放在大的事件迴圈中，為了減少accept鎖的佔用時間，超時事件的處理當然還是放在釋放accept鎖的時機之後。
為了防止不開啟timer_resolution的情況下，epoll_wait()佔用太多時間，在呼叫ngx_process_events(cycle, timer, flags)之前，Nginx會先計算距離最近超時事件的時間，然後把這個時間記錄在timer變數中傳給epoll_wait的超時引數，來控制epoll_wait的佔用時長。
此外，Nginx還會計算ngx_process_events呼叫所佔用的時長（delta變數）,唯有delta > 0的情況，才會呼叫ngx_event_expire_timers()來處理超時事件，以此來避免無意義的搜尋（真是煞費苦心啊）。
下面可以整體看看在事件迴圈中超時事件處理所佔的位置：
void
ngx_process_events_and_timers(ngx_cycle_t *cycle)
{
ngx_uint_t flags;
ngx_msec_t timer, delta;
if (ngx_timer_resolution) {
timer = NGX_TIMER_INFINITE;
flags = 0;
} else {
// 把距離最近的超時事件的時間記錄在timer中
timer = ngx_event_find_timer();
flags = NGX_UPDATE_TIME;
}
// 這裡是處理負載均衡鎖和accept鎖的時機
/* 省略了accept鎖的競爭 */
delta = ngx_current_msec;
// 呼叫事件處理模組的process_events，處理一個epoll_wait的方法
(void) ngx_process_events(cycle, timer, flags);
delta = ngx_current_msec - delta; //計算處理events事件所消耗的時間
// 如果有延後處理的accept事件，那麼延後處理這個事件
if (ngx_posted_accept_events) {
ngx_event_process_posted(cycle, &ngx_posted_accept_events);
}
// 釋放accept鎖
if (ngx_accept_mutex_held) {
ngx_shmtx_unlock(&ngx_accept_mutex);
}
// 處理所有的超時事件
if (delta) {
ngx_event_expire_timers();
}
/* 省略了延後事件的處理 */
}
複製程式碼