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