在說nginx前，先來看看什麼是“驚群”？簡單說來，多執行緒/多程序（linux下執行緒程序也沒多大區別）等待同一個socket事件，當這個事件發生時，這些執行緒/程序被同時喚醒，就是驚群。可以想見，效率很低下，許多程序被核心重新排程喚醒，同時去響應這一個事件，當然只有一個程序能處理事件成功，其他的程序在處理該事件失敗後重新休眠（也有其他選擇）。這種效能浪費現象就是驚群。

驚群通常發生在server 上，當父程序繫結一個埠監聽socket，然後fork出多個子程序，子程序們開始迴圈處理（比如accept）這個socket。每當使用者發起一個TCP連線時，多個子程序同時被喚醒，然後其中一個子程序accept新連線成功，餘者皆失敗，重新休眠。

那麼，我們不能只用一個程序去accept新連線麼？然後通過訊息佇列等同步方式使其他子程序處理這些新建的連線，這樣驚群不就避免了？沒錯，驚群是避免了，但是效率低下，因為這個程序只能用來accept連線。對多核機器來說，僅有一個程序去accept，這也是程式設計師在自己創造accept瓶頸。所以，我仍然堅持需要多程序處理accept事件。

其實，在linux2.6核心上，accept系統呼叫已經不存在驚群了（至少我在2.6.18核心版本上已經不存在）。大家可以寫個簡單的程式試下，在父程序中bind,listen，然後fork出子程序，所有的子程序都accept這個監聽控制代碼。這樣，當新連線過來時，大家會發現，僅有一個子程序返回新建的連線，其他子程序繼續休眠在accept呼叫上，沒有被喚醒。

但是很不幸，通常我們的程式沒那麼簡單，不會願意阻塞在accept呼叫上，我們還有許多其他網路讀寫事件要處理，linux下我們愛用epoll解決非阻塞socket。所以，即使accept呼叫沒有驚群了，我們也還得處理驚群這事，因為epoll有這問題。上面說的測試程式，如果我們在子程序內不是阻塞呼叫accept，而是用epoll_wait，就會發現，新連線過來時，多個子程序都會在epoll_wait後被喚醒！

nginx就是這樣，master程序監聽埠號（例如80），所有的nginx worker程序開始用epoll_wait來處理新事件（linux下），如果不加任何保護，一個新連線來臨時，會有多個worker程序在epoll_wait後被喚醒，然後發現自己accept失敗。現在，我們可以看看nginx是怎麼處理這個驚群問題了。

nginx的每個worker程序在函式ngx_process_events_and_timers中處理事件，(void) ngx_process_events(cycle, timer, flags);封裝了不同的事件處理機制，在linux上預設就封裝了epoll_wait呼叫。我們來看看ngx_process_events_and_timers為解決驚群做了什麼：

void
ngx_process_events_and_timers(ngx_cycle_t *cycle)
{
。。。 。。。
    //ngx_use_accept_mutex表示是否需要通過對accept加鎖來解決驚群問題。當nginx worker程序數>1時且配置檔案中開啟accept_mutex時，這個標誌置為1
    if (ngx_use_accept_mutex) {
    		//ngx_accept_disabled表示此時滿負荷，沒必要再處理新連線了，我們在nginx.conf曾經配置了每一個nginx worker程序能夠處理的最大連線數，當達到最大數的7/8時，ngx_accept_disabled為正，說明本nginx worker程序非常繁忙，將不再去處理新連線，這也是個簡單的負載均衡
        if (ngx_accept_disabled > 0) {
            ngx_accept_disabled--;

        } else {
        		//獲得accept鎖，多個worker僅有一個可以得到這把鎖。獲得鎖不是阻塞過程，都是立刻返回，獲取成功的話ngx_accept_mutex_held被置為1。拿到鎖，意味著監聽控制代碼被放到本程序的epoll中了，如果沒有拿到鎖，則監聽控制代碼會被從epoll中取出。
            if (ngx_trylock_accept_mutex(cycle) == NGX_ERROR) {
                return;
            }

						//拿到鎖的話，置flag為NGX_POST_EVENTS，這意味著ngx_process_events函式中，任何事件都將延後處理，會把accept事件都放到ngx_posted_accept_events連結串列中，epollin|epollout事件都放到ngx_posted_events連結串列中
            if (ngx_accept_mutex_held) {
                flags |= NGX_POST_EVENTS;

            } else {
            		//拿不到鎖，也就不會處理監聽的控制代碼，這個timer實際是傳給epoll_wait的超時時間，修改為最大ngx_accept_mutex_delay意味著epoll_wait更短的超時返回，以免新連線長時間沒有得到處理
                if (timer == NGX_TIMER_INFINITE
                    || timer > ngx_accept_mutex_delay)
                {
                    timer = ngx_accept_mutex_delay;
                }
            }
        }
    }
。。。 。。。
		//linux下，呼叫ngx_epoll_process_events函式開始處理
    (void) ngx_process_events(cycle, timer, flags);
。。。 。。。
		//如果ngx_posted_accept_events連結串列有資料，就開始accept建立新連線
    if (ngx_posted_accept_events) {
        ngx_event_process_posted(cycle, &ngx_posted_accept_events);
    }

		//釋放鎖後再處理下面的EPOLLIN EPOLLOUT請求
    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);
		//然後再處理正常的資料讀寫請求。因為這些請求耗時久，所以在ngx_process_events裡NGX_POST_EVENTS標誌將事件都放入ngx_posted_events連結串列中，延遲到鎖釋放了再處理。
    if (ngx_posted_events) {
        if (ngx_threaded) {
            ngx_wakeup_worker_thread(cycle);

        } else {
            ngx_event_process_posted(cycle, &ngx_posted_events);
        }
    }
｝

從上面的註釋可以看到，無論有多少個nginx worker程序，同一時刻只能有一個worker程序在自己的epoll中加入監聽的控制代碼。這個處理accept的nginx worker程序置flag為NGX_POST_EVENTS，這樣它在接下來的ngx_process_events函式（在linux中就是ngx_epoll_process_events函式）中不會立刻處理事件，延後，先處理完所有的accept事件後，釋放鎖，然後再處理正常的讀寫socket事件。我們來看下ngx_epoll_process_events是怎麼做的：

static ngx_int_t
ngx_epoll_process_events(ngx_cycle_t *cycle, ngx_msec_t timer, ngx_uint_t flags)
{
。。。 。。。
    events = epoll_wait(ep, event_list, (int) nevents, timer);
。。。 。。。
    ngx_mutex_lock(ngx_posted_events_mutex);

    for (i = 0; i < events; i++) {
        c = event_list[i].data.ptr;

。。。 。。。

        rev = c->read;

        if ((revents & EPOLLIN) && rev->active) {
。。。 。。。
//有NGX_POST_EVENTS標誌的話，就把accept事件放到ngx_posted_accept_events佇列中，把正常的事件放到ngx_posted_events佇列中延遲處理
            if (flags & NGX_POST_EVENTS) {
                queue = (ngx_event_t **) (rev->accept ?
                               &ngx_posted_accept_events : &ngx_posted_events);

                ngx_locked_post_event(rev, queue);

            } else {
                rev->handler(rev);
            }
        }

        wev = c->write;

        if ((revents & EPOLLOUT) && wev->active) {
。。。 。。。
//同理，有NGX_POST_EVENTS標誌的話，寫事件延遲處理，放到ngx_posted_events佇列中
            if (flags & NGX_POST_EVENTS) {
                ngx_locked_post_event(wev, &ngx_posted_events);

            } else {
                wev->handler(wev);
            }
        }
    }

    ngx_mutex_unlock(ngx_posted_events_mutex);

    return NGX_OK;
}

看看ngx_use_accept_mutex在何種情況下會被開啟：

    if (ccf->master && ccf->worker_processes > 1 && ecf->accept_mutex) {
        ngx_use_accept_mutex = 1;
        ngx_accept_mutex_held = 0;
        ngx_accept_mutex_delay = ecf->accept_mutex_delay;

    } else {
        ngx_use_accept_mutex = 0;
    }

當nginx worker數量大於1時，也就是多個程序可能accept同一個監聽的控制代碼，這時如果配置檔案中accept_mutex開關打開了，就將ngx_use_accept_mutex置為1。

再看看有些負載均衡作用的ngx_accept_disabled是怎麼維護的，在ngx_event_accept函式中：

        ngx_accept_disabled = ngx_cycle->connection_n / 8
                              - ngx_cycle->free_connection_n;

表明，當已使用的連線數佔到在nginx.conf裡配置的worker_connections總數的7/8以上時，ngx_accept_disabled為正，這時本worker將ngx_accept_disabled減1，而且本次不再處理新連線。

最後，我們看下ngx_trylock_accept_mutex函式是怎麼玩的：

ngx_int_t
ngx_trylock_accept_mutex(ngx_cycle_t *cycle)
{
//ngx_shmtx_trylock是非阻塞取鎖的，返回1表示成功，0表示沒取到鎖
    if (ngx_shmtx_trylock(&ngx_accept_mutex)) {

//ngx_enable_accept_events會把監聽的控制代碼都塞入到本worker程序的epoll中
        if (ngx_enable_accept_events(cycle) == NGX_ERROR) {
            ngx_shmtx_unlock(&ngx_accept_mutex);
            return NGX_ERROR;
        }
//ngx_accept_mutex_held置為1，表示拿到鎖了，返回
        ngx_accept_events = 0;
        ngx_accept_mutex_held = 1;

        return NGX_OK;
    }

//處理沒有拿到鎖的邏輯，ngx_disable_accept_events會把監聽控制代碼從epoll中取出
    if (ngx_accept_mutex_held) {
        if (ngx_disable_accept_events(cycle) == NGX_ERROR) {
            return NGX_ERROR;
        }

        ngx_accept_mutex_held = 0;
    }

    return NGX_OK;
}                              

OK，關於鎖的細節是如何實現的，這篇限於篇幅就不說了，下篇帖子再來講。現在大家清楚nginx是怎麼處理驚群了吧？簡單了說，就是同一時刻只允許一個nginx worker在自己的epoll中處理監聽控制代碼。它的負載均衡也很簡單，當達到最大connection的7/8時，本worker不會去試圖拿accept鎖，也不會去處理新連線，這樣其他nginx worker程序就更有機會去處理監聽控制代碼，建立新連線了。而且，由於timeout的設定，使得沒有拿到鎖的worker程序，去拿鎖的頻繁更高。