事件處理框架

???????? 所有的worker進程都在ngx_worker_process_cycle方法中循環(huán)處理事件，處理分發(fā)事件則在ngx_worker_process_cycle方法中調(diào)用ngx_process_events_and_timers方法，循環(huán)調(diào)用該方法就是 在處理全部事件，這正是事件驅(qū)動機制的核心。該方法既會處理普通的網(wǎng)絡(luò)事件，也會處理定時器事件。

ngx_process_events_and_timers方法中核心操作主要有下面3個：

1）? 調(diào)用所使用事件驅(qū)動模塊實現(xiàn)的process_events方法。處理網(wǎng)絡(luò)事件

2）? 處理兩個post事件隊列中的事件，實際上就是分別調(diào)用ngx_event_process_posted(cycle, &ngx_posted_accept_events)和ngx_event_process_posted(cycle,&ngx_posted_events)方法

3）? 處理定時事件，實際上就是調(diào)用ngx_event_expire_timers()方法

以下是ngx_process_events_and_timers方法中的時間框架處理流程圖以及源碼，能夠結(jié)合理解：

源碼例如以下：

void ngx_process_events_and_timers(ngx_cycle_t *cycle) {ngx_uint_t flags;ngx_msec_t timer, delta;/*假設(shè)配置文件里使用了timer_resolution配置項，也就是ngx_timer_resolution值大于0。則說明用戶希望server時間精度為ngx_timer_resolution毫秒。這時。將ngx_process_changes的timer參數(shù)設(shè)為-1。告訴ngx_process_change方法在檢測時間時不要等待。直接搜集全部已經(jīng)就緒的時間然后返回；同一時候?qū)lag參數(shù)初始化為0，它是在告訴ngx_process_changes沒有不論什么附加動作*/if (ngx_timer_resolution) {timer = NGX_TIMER_INFINITE;flags = 0;} else {/*假設(shè)沒有使用timer_resolution,那么將調(diào)用ngx_event_find_timer()方法，獲取近期一個將要觸發(fā)的時間距離如今有多少毫秒，然后把這個值賦予timer參數(shù)。告訴ngx_process_change方法在檢測事件時假設(shè)沒有不論什么事件。最多等待timer毫秒就返回;將flag參數(shù)設(shè)置為UPDATE_TIME,告訴ngx_process_change方法更新?lián)Q成的時間*/timer = ngx_event_find_timer();flags = NGX_UPDATE_TIME;#if (NGX_THREADS)if (timer == NGX_TIMER_INFINITE || timer > 500) {timer = 500;}#endif}/*ngx_use_accept_mutex表示是否須要通過對accept加鎖來解決驚群問題。

當nginx worker進程數(shù)>1時且配置文件里打開accept_mutex時。這個標志置為1 */ if (ngx_use_accept_mutex) { /*ngx_accept_disabled表示此時滿負荷，不是必需再處理新連接了， 我們在nginx.conf以前配置了每個nginx worker進程可以處理的最大連接數(shù)。 當達到最大數(shù)的7/8時。ngx_accept_disabled為正。說明本nginx worker進程很繁忙， 將不再去處理新連接，這也是個簡單的負載均衡 */ if (ngx_accept_disabled > 0) { ngx_accept_disabled--; } else { /*獲得accept鎖，多個worker僅有一個可以得到這把鎖。獲得鎖不是堵塞過程， 都是立馬返回，獲取成功的話ngx_accept_mutex_held被置為1。拿到鎖，意味 著監(jiān)聽句柄被放到本進程的epoll中了。假設(shè)沒有拿到鎖，則監(jiān)聽句柄會被 從epoll中取出。*/ if (ngx_trylock_accept_mutex(cycle) == NGX_ERROR) { return; } /*拿到鎖的話，置flag為NGX_POST_EVENTS，這意味著ngx_process_events函數(shù)中， 不論什么事件都將延后處理。會把accept事件都放到ngx_posted_accept_events鏈表中， epollin | epollout事件都放到ngx_posted_events鏈表中 */ if (ngx_accept_mutex_held) { flags |= NGX_POST_EVENTS; } else { /*獲取鎖失敗。意味著既不能讓當前worker進程頻繁的試圖搶鎖，也不能讓它經(jīng)過太長事件再去搶鎖 以下的代碼：即使開啟了timer_resolution時間精度。牙須要讓ngx_process_change方法在沒有新 事件的時候至少等待ngx_accept_mutex_delay毫秒之后再去試圖搶鎖 而沒有開啟時間精度時， 假設(shè)近期一個定時器事件的超時時間距離如今超過了ngx_accept_mutex_delay毫秒，也要把timer設(shè) 置為ngx_accept_mutex_delay毫秒，這是由于當前進程盡管沒有搶到accept_mutex鎖，但也不能讓 ngx_process_change方法在沒有新事件的時候等待的時間超過ngx_accept_mutex_delay，這會影響 整個負載均衡機制*/ if (timer == NGX_TIMER_INFINITE || timer > ngx_accept_mutex_delay) { timer = ngx_accept_mutex_delay; } } } } //計算ngx_process_events消耗的時間 delta = ngx_current_msec; //linux下，調(diào)用ngx_epoll_process_events函數(shù)開始處理 (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); //假設(shè)ngx_posted_accept_events鏈表有數(shù)據(jù)，就開始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); } //假設(shè)ngx_process_events消耗的時間大于0，那么這時可能有新的定時器事件觸發(fā) if (delta) { //處理定時事件 ngx_event_expire_timers(); } ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0, "posted events %p", ngx_posted_events); //ngx_posted_events鏈表中有數(shù)據(jù)，進行處理 if (ngx_posted_events) { if (ngx_threaded) { ngx_wakeup_worker_thread(cycle); } else { ngx_event_process_posted(cycle, &ngx_posted_events); } } }

驚群問題

在建立連接的時候。Nginx處于充分發(fā)揮多核CPU架構(gòu)性能的考慮。使用了多個worker子進程監(jiān)聽同樣port的設(shè)計，這樣多個子進程在accept建立新連接時會有爭搶，這會帶來的“驚群”問題。子進程數(shù)量越多越明顯，這會造成系統(tǒng)性能的下降。

master進程開始監(jiān)聽Webport，fork出多個worker子進程，這些子進程同一時候監(jiān)聽同一個Webport。普通情況下，有多少CPU核心就有配置多少個worker子進程。這樣全部的worker子進程都在承擔著Webserver的角色。從而發(fā)揮多核機器的威力。如果如今沒實用戶連入server。某一時刻恰好全部的子進程都休眠且等待新連接的系統(tǒng)調(diào)用，這時有一個用戶向server發(fā)起了連接，內(nèi)核在收到TCP的SYN包時。會激活全部的休眠worker子進程。終于僅僅有最先開始運行accept的子進程能夠成功建立新連接，而其它worker子進程都將accept失敗。

這些accept失敗的子進程被內(nèi)核喚醒是不必要的，他們被喚醒會的運行非?？赡苁嵌嘤嗟?#xff0c;那么這一時刻他們占用了本不須要占用的資源，引發(fā)了不必要的進程切換，添加了系統(tǒng)開銷。

非常多操作系統(tǒng)的最新版本號的內(nèi)核已經(jīng)在事件驅(qū)動機制中攻克了驚群問題，但Nginx作為可移植性極高的webserver。還是在自身的應(yīng)用層面上較好的攻克了這一問題。既然驚群是個多子進程在同一時刻監(jiān)聽同一個port引起的。那么Nginx的解決方法也非常easy，它規(guī)定了同一時刻僅僅能有唯一一個worker子進程監(jiān)聽Webport，這樣就不會發(fā)生驚群了。此時新連接時間就僅僅能喚醒唯一正在監(jiān)聽port的worker子進程。

怎樣限制在某一時刻僅能有一個子進程監(jiān)聽webport呢？在打開accept_mutex鎖的情況下。僅僅有調(diào)用ngx_trylock_accept_mutex方法后。當前的worker進程才會去試著監(jiān)聽webport。

該方法詳細實現(xiàn)例如以下：

ngx_int_t ngx_trylock_accept_mutex(ngx_cycle_t *cycle) {/*使用進程間的同步鎖，試圖獲取accept_mutex。注意，ngx_trylock_accept_mutex返回1表示成功拿到鎖，返回0表示獲取鎖失敗。這個獲取所的過程是非堵塞的。此時一旦鎖被其它worker子進程占用，該方法會立馬返回。

*/ if (ngx_shmtx_trylock(&ngx_accept_mutex)) { ngx_log_debug0(NGX_LOG_DEBUG_EVENT, cycle->log, 0, "accept mutex locked"); /*假設(shè)獲取到accept_mutex鎖。但ngx_accept_mutex_held為1，則立馬返回。

ngx_accept_mutex_held 是一個標志位，當它為1時，表示當前進程已經(jīng)獲取到鎖了*/ if (ngx_accept_mutex_held && ngx_accept_events == 0 && !(ngx_event_flags & NGX_USE_RTSIG_EVENT)) { //ngx_accept_mutex鎖之前已經(jīng)獲取到了。立馬返回 return NGX_OK; } //將全部監(jiān)聽連接的事件加入到當前epoll等事件驅(qū)動模塊中 if (ngx_enable_accept_events(cycle) == NGX_ERROR) { /*既然將監(jiān)聽句柄加入到事件驅(qū)動模塊失敗，就必須釋放ngx_accept_mutex鎖*/ ngx_shmtx_unlock(&ngx_accept_mutex); return NGX_ERROR; } /*經(jīng)過ngx_enable_accept_events方法的調(diào)用。當前進程的時間驅(qū)動模塊已經(jīng)開始監(jiān) 聽全部的port，這時須要把ngx_accept_mutex_heald標志置為1，方便本進程的其它模 塊了解它眼下已經(jīng)獲取到了鎖*/ ngx_accept_events = 0; ngx_accept_mutex_held = 1; return NGX_OK; } /*假設(shè)ngx_shmtx_trylock返回0，則表明獲取ngx_accept_mutex鎖失敗，這時假設(shè) ngx_accept_mutex_held標志還為1，即當前進程還在獲取到鎖的狀態(tài)，這顯然不對，須要處理*/ ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0, "accept mutex lock failed: %ui", ngx_accept_mutex_held); if (ngx_accept_mutex_held) { /*ngx_disable_accept_events(會將全部監(jiān)聽連接的讀事件從事件驅(qū)動模塊中移除*/ if (ngx_disable_accept_events(cycle) == NGX_ERROR) { return NGX_ERROR; } /*在沒有獲取到ngx_accept_mutex鎖時，必須把ngx_accept_mutex_held置為0*/ ngx_accept_mutex_held = 0; } return NGX_OK; }

在上面的代碼中，ngx_accept_mutex是進程間的同步鎖（見http://blog.csdn.net/walkerkalr/article/details/38237147）,ngx_accept_mutex_held是當前進程的一個全局變量。他們的定義例如以下：

ngx_shmtx_t ngx_accept_mutex; ngx_uint_t ngx_accept_mutex_held;

因此。在調(diào)用ngx_try_accept_mutex方法后，假設(shè)沒有獲取到鎖。當前進程調(diào)用process_events時僅僅能處理已有連接上的事件。

假設(shè)唯一獲取到鎖且其epoll等事件驅(qū)動模塊開始監(jiān)控webport上的新連接事件。這種情況下，調(diào)用process_events時就會既處理已有連接上的事件，也處理新連接的事件，但這種話，什么時候釋放ngx_accept_mutex鎖呢？假設(shè)等到這批事件所有運行完。因為這個worker進程上可能有非常多活躍的連接，處理這些連接上的事件會占用非常長時間，也就是說。會非常長時間都沒有釋放ngx_accept_mutex鎖，這樣，其它worker進程就非常難得到處理新連接的機會。

怎樣解決長時間占用ngx_accept_mutex的問題呢？這就要依靠ngx_posted_accept_events隊列（存放新連接事件的隊列）和ngx_posted_events隊列（存放普通事件的隊列）。實際上ngx_posted_accepted_events隊列和ngx_posted_events隊列把事件進行了歸類，以使先處理ngx_posted_accept_events隊列中的事件，處理完后就要釋放ngx_accept_mutex鎖，接著再處理ngx_posted_events隊列中的時間，這樣就大大降低了ngx_accept_mutex鎖占用的時間。

負載均衡

在建立連接時。在多個子進程爭搶處理一個新連接時間時，一定僅僅有一個worker子進程終于會成功簡歷連接。隨后，它會一直處理這個連接直到連接關(guān)閉。那么，假設(shè)有的子進程非常勤奮。他們搶著建立并處理了大部分連接，而有的子進程則運氣不好。僅僅處理了少量連接，這對多核CPU架構(gòu)下的應(yīng)用是非常不利的。由于子進程之間應(yīng)該是平等的。每一個子進程應(yīng)該盡量獨占一個CPU核心。子進程間負載不均衡，必然會影響整個服務(wù)的性能。

與驚群問題的解決方法一樣。僅僅有打開了accept_mutex鎖，才干實現(xiàn)子進程間的負載均衡。在這里。初始化了一個全局變量ngx_accept_disabled。他就是負載均衡機制實現(xiàn)的關(guān)鍵閾值。實際上它就是一個整型數(shù)據(jù)。

ngx_int_t ngx_accept_disabled;

這個閾值是與連接池中連接的使用密切相關(guān)的，在建立連接時會進行賦值，例如以下所看到的

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

因此。在啟動時該閾值是一個負值。其絕對值是連接總數(shù)的7/8。事實上ngx_accept_disabled的使用方法非常easy，當它為負數(shù)時，不會觸發(fā)負載均衡操作，正常獲取accept鎖。試圖處理新連接。

而當ngx_accept_disabled是正數(shù)時，就會觸發(fā)Nginx進行負載均衡操作了。nginx此時不再處理新連接事件，取而代之的不過ngx_accept_disabled值減1,。這表示既然經(jīng)過一輪事件處理。那么相對負載肯定有所減小，所以要對應(yīng)調(diào)整這個值。例如以下所看到的

if (ngx_accept_disabled > 0) {ngx_accept_disabled--;} else {//調(diào)用ngx_trylock_accept_mutex方法，嘗試獲取accept鎖if (ngx_trylock_accept_mutex(cycle) == NGX_ERROR) {return;}

Nginx各worker子進程間的負載均衡僅在某個worker進程處理的連接數(shù)達到它最大處理總數(shù)的7/8時才會觸發(fā)。這時該worker進程就會降低處理新連接的機會，這樣其它較空暇的worker進程就有機會去處理很多其它的新連接。以達到整個webserver的均衡效果。

?

版權(quán)聲明：本文博主原創(chuàng)文章，博客，未經(jīng)同意不得轉(zhuǎn)載。

轉(zhuǎn)載于:https://www.cnblogs.com/yxwkf/p/4854229.html

總結(jié)

以上是生活随笔為你收集整理的Nginx——事件驱动机制(雷霆追风问题，负载均衡)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。