緊跟著上一節(jié)所講的，Nginx里面worker子進程之間相互獨立，各自接收新的連接，接收數(shù)據(jù)報文，處理請求，等等。
但是，由于監(jiān)聽socket是由父進程創(chuàng)建的，所以在子進程調用accept函數(shù)接收新的連接時可能會出現(xiàn)所謂的驚群（thundering herd）, 其實這個現(xiàn)象即使出現(xiàn)，我個人認為對性能的影響也不會太大，不就是一次accept操作失敗么。另外呢，子進程之間雖然是獨立工作的，但是，也可能出現(xiàn)不同的子進程之間負載不均衡的情況，比如某些子進程處理1000個連接，有的子進程處理100個連接，差了十倍。
Nginx里面，針對上面提到的兩點，對程序進行了一些優(yōu)化。來看看ngx_process_events_and_timers
函數(shù)里面的代碼，這個函數(shù)是worker子進程中服務器主循環(huán)每次循環(huán)都會調用的函數(shù)：
// 如果使用了accept mutex
if (ngx_use_accept_mutex) {
// 如果當前禁止accept操作的計數(shù)還大于0
if (ngx_accept_disabled > 0) {
// 將這個計數(shù)減一
ngx_accept_disabled--;
} else {
// 嘗試獲取accept鎖
if (ngx_trylock_accept_mutex(cycle) == NGX_ERROR) {
return;
}
// 如果獲取到了accept鎖
if (ngx_accept_mutex_held) {
flags |= NGX_POST_EVENTS;
} else {
// 否則， 如果滿足下面兩個條件，將定時器置為ngx_accept_mutex_delay， 這個值是一個配置參數(shù)指定的
if (timer == NGX_TIMER_INFINITE
|| timer > ngx_accept_mutex_delay)
{
timer = ngx_accept_mutex_delay;
}
}
}
}
// 記下當前時間點
delta = ngx_current_msec;
// 處理事件
(void) ngx_process_events(cycle, timer, flags);
// 得到處理事件所用的時間
delta = ngx_current_msec - delta;
ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0,
"timer delta: %M", delta);
// 如果有accept事件發(fā)生， 就去處理accept事件，其實最后就是調用accept函數(shù)接收新的連接
if (ngx_posted_accept_events) {
ngx_event_process_posted(cycle, &ngx_posted_accept_events);
}
// 已經(jīng)處理完接收新連接的事件了，如果前面獲取到了accept鎖，那就解鎖
if (ngx_accept_mutex_held) {
ngx_shmtx_unlock(&ngx_accept_mutex);
}
if (delta) {
ngx_event_expire_timers();
}
ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0,
"posted events %p", ngx_posted_events);
// 除了accepet事件之外的其他事件放在這個隊列中， 如果隊列不為空，就去處理相關的事件
if (ngx_posted_events) {
if (ngx_threaded) {
ngx_wakeup_worker_thread(cycle);
} else {
ngx_event_process_posted(cycle, &ngx_posted_events);
}
}
上面的代碼中，ngx_accept_disabled變量是在函數(shù)ngx_event_accept中被賦值的：
ngx_accept_disabled = ngx_cycle->connection_n / 8
- ngx_cycle->free_connection_n;
簡單的理解，當前已經(jīng)接收的連接（connection_n）越多，可用的空閑連接（free_connection_n）越少，這個值越大。
所以呢，假如某個子進程，當前已經(jīng)接收了一定數(shù)量的連接，那么這個計數(shù)值就會相應的大，也就是說，這個子進程將會暫緩（注意，不是暫停）接收新的連接，而去專注于處理當前已經(jīng)接收的連接；反之，如果某子進程當前處理的連接數(shù)量少，那么這個計數(shù)就會相應的小，于是這個較為空閑的子進程就會更多的接收新的連接請求。這個策略，確保了各個worker子進程之間負載是相對均衡的，不會出現(xiàn)某些子進程接收的連接特別多，某些又特別少。
同樣的，在這段代碼中，看到了即使現(xiàn)在子進程可以接收新的連接，也需要去競爭以獲取accept鎖，只有獲得了這個鎖才能接收新的連接，所以避免了前面提到的驚群現(xiàn)象的發(fā)生。
另外，在linux的新版內核中，加入了一個所謂的"cpu affinity"的特性，利用這個特性，你可以指定哪些進程只能運行在哪些CPU上面，我對這個不太熟悉，查看了一些資料，提到的說法是，有了這個特性，比如進程A在CPU1上面運行，那么在CPU1上面會cache一些與該進程相關的數(shù)據(jù)，那么再次調用的時候性能方面就會高效一些，反之，如果頻繁的切換到不同的CPU上面去運行，那么之前在別的CPU上面的cache就會失效。
Nginx里面針對Linux內核的這個特性做了一些優(yōu)化，它也可以在配置文件中指定哪些子進程可以運行在哪些CPU上面,這個優(yōu)化與配置選項worker_cpu_affinity有關。可以在 http://wiki.nginx.org/NginxCoreModule
找到關于這個配置相關的信息。