文章主要給大家介紹了關于Nginx中accept鎖的機制與實現的相關資料，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧

前言

nginx采用多進程的模,當一個請求過來的時候,系統會對進程進行加鎖操作,保證只有一個進程來接受請求。

本文基于Nginx 0.8.55源代碼，并基于epoll機制分析

1. accept鎖的實現

1.1 accpet鎖是個什么東西

提到accept鎖，就不得不提起驚群問題。

所謂驚群問題，就是指的像Nginx這種多進程的服務器，在fork后同時監聽同一個端口時，如果有一個外部連接進來，會導致所有休眠的子進程被喚醒，而最終只有一個子進程能夠成功處理accept事件，其他進程都會重新進入休眠中。這就導致出現了很多不必要的schedule和上下文切換，而這些開銷是完全不必要的。

而在Linux內核的較新版本中，accept調用本身所引起的驚群問題已經得到了解決，但是在Nginx中，accept是交給epoll機制來處理的，epoll的accept帶來的驚群問題并沒有得到解決（應該是epoll_wait本身并沒有區別讀事件是否來自于一個Listen套接字的能力，所以所有監聽這個事件的進程會被這個epoll_wait喚醒。），所以Nginx的accept驚群問題仍然需要定制一個自己的解決方案。

accept鎖就是nginx的解決方案，本質上這是一個跨進程的互斥鎖，以這個互斥鎖來保證只有一個進程具備監聽accept事件的能力。

實現上accept鎖是一個跨進程鎖，其在Nginx中是一個全局變量，聲明如下：

1. ngx_shmtx_t   ngx_accept_mutex;

這是一個在event模塊初始化時就分配好的鎖，放在一塊進程間共享的內存中，以保證所有進程都能訪問這一個實例，其加鎖解鎖是借由linux的原子變量來做CAS，如果加鎖失敗則立即返回，是一種非阻塞的鎖。加解鎖代碼如下：

1. static ngx_inline ngx_uint_t            
2. ngx_shmtx_trylock(ngx_shmtx_t *mtx)          
3. {                   
4.  return (*mtx->lock == 0 && ngx_atomic_cmp_set(mtx->lock, 0, ngx_pid)); 
5. }                   
6.                      
7. #define ngx_shmtx_lock(mtx) ngx_spinlock((mtx)->lock, ngx_pid, 1024)  
8.                      
9. #define ngx_shmtx_unlock(mtx) (void) ngx_atomic_cmp_set((mtx)->lock, ngx_pid, 0)

可以看出，調用ngx_shmtx_trylock失敗后會立刻返回而不會阻塞。

1.2 accept鎖如何保證只有一個進程能夠處理新連接

要解決epoll帶來的accept鎖的問題也很簡單，只需要保證同一時間只有一個進程注冊了accept的epoll事件即可。
Nginx采用的處理模式也沒什么特別的，大概就是如下的邏輯：

嘗試獲取accept鎖
if 獲取成功：
 在epoll中注冊accept事件
else:
 在epoll中注銷accept事件
處理所有事件
釋放accept鎖

當然這里忽略了延后事件的處理，這部分我們放到后面討論。

對于accept鎖的處理和epoll中注冊注銷accept事件的的處理都是在ngx_trylock_accept_mutex中進行的。而這一系列過程則是在nginx主體循環中反復調用的void ngx_process_events_and_timers(ngx_cycle_t *cycle)中進行。

也就是說，每輪事件的處理都會首先競爭accept鎖，競爭成功則在epoll中注冊accept事件，失敗則注銷accept事件，然后處理完事件之后，釋放accept鎖。由此只有一個進程監聽一個listen套接字，從而避免了驚群問題。

1.3 事件處理機制為不長時間占用accept鎖作了哪些努力

accept鎖處理驚群問題的方案看起來似乎很美，但如果完全使用上述邏輯，就會有一個問題：如果服務器非常忙，有非常多事件要處理，那么“處理所有事件這一步”就會消耗非常長的時間，也就是說，某一個進程長時間占用accept鎖，而又無暇處理新連接；其他進程又沒有占用accept鎖，同樣無法處理新連接——至此，新連接就處于無人處理的狀態，這對服務的實時性無疑是很要命的。

為了解決這個問題，Nginx采用了將事件處理延后的方式。即在ngx_process_events的處理中，僅僅將事件放入兩個隊列中：

1. ngx_thread_volatile ngx_event_t *ngx_posted_accept_events;       
2. ngx_thread_volatile ngx_event_t *ngx_posted_events;

返回后先處理ngx_posted_accept_events后立刻釋放accept鎖，然后再慢慢處理其他事件。

即ngx_process_events僅對epoll_wait進行處理，事件的消費則放到accept鎖釋放之后，來最大限度地縮短占有accept的時間，來讓其他進程也有足夠的時機處理accept事件。

那么具體是怎么實現的呢？其實就是在static ngx_int_t ngx_epoll_process_events(ngx_cycle_t *cycle, ngx_msec_t timer, ngx_uint_t flags)的flags參數中傳入一個NGX_POST_EVENTS的標志位，處理事件時檢查這個標志位即可。

這里只是避免了事件的消費對于accept鎖的長期占用，那么萬一epoll_wait本身占用的時間很長呢？這種事情也不是不可能發生。這方面的處理也很簡單，epoll_wait本身是有超時時間的，限制住它的值就可以了，這個參數保存在ngx_accept_mutex_delay這個全局變量中。

下面放上ngx_process_events_and_timers 的實現代碼，可以大概一觀相關的處理：

1. void                  
2. ngx_process_events_and_timers(ngx_cycle_t *cycle)       
3. {                   
4.  ngx_uint_t flags;              
5.  ngx_msec_t timer, delta;            
6.      
7.      
8.     /* 省略一些處理時間事件的代碼 */                   
9.  // 這里是處理負載均衡鎖和accept鎖的時機        
10.  if (ngx_use_accept_mutex) {           
11.   // 如果負載均衡token的值大于0, 則說明負載已滿，此時不再處理accept, 同時把這個值減一
12.   if (ngx_accept_disabled > 0) {          
13.    ngx_accept_disabled--;           
14.                      
15.   } else {               
16.    // 嘗試拿到accept鎖           
17.    if (ngx_trylock_accept_mutex(cycle) == NGX_ERROR) {   
18.     return;             
19.    }                
20.                      
21.    // 拿到鎖之后把flag加上post標志，讓所有事件的處理都延后  
22.    // 以免太長時間占用accept鎖         
23.    if (ngx_accept_mutex_held) {         
24.     flags |= NGX_POST_EVENTS;         
25.                      
26.    } else {              
27.     if (timer == NGX_TIMER_INFINITE       
28.      || timer > ngx_accept_mutex_delay)      
29.     {               
30.      timer = ngx_accept_mutex_delay; // 最多等ngx_accept_mutex_delay個毫秒，防止占用太久accept鎖
31.     }               
32.    }                
33.   }                 
34.  }                   
35.  delta = ngx_current_msec;            
36.                      
37.  // 調用事件處理模塊的process_events，處理一個epoll_wait的方法   
38.  (void) ngx_process_events(cycle, timer, flags);      
39.                      
40.  delta = ngx_current_msec - delta; //計算處理events事件所消耗的時間  
41.                      
42.  ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0,      
43.      "timer delta: %M", delta);        
44.                      
45.  // 如果有延后處理的accept事件，那么延后處理這個事件     
46.  if (ngx_posted_accept_events) {          
47.   ngx_event_process_posted(cycle, &ngx_posted_accept_events);  
48.  }                  
49.                      
50.  // 釋放accept鎖              
51.  if (ngx_accept_mutex_held) {           
52.   ngx_shmtx_unlock(&ngx_accept_mutex);        
53.  }                  
54.                      
55.  // 處理所有的超時事件             
56.  if (delta) {               
57.   ngx_event_expire_timers();           
58.  }                  
59.                      
60.  ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0,      
61.      "posted events %p", ngx_posted_events);     
62.                      
63.  if (ngx_posted_events) {            
64.   if (ngx_threaded) {            
65.    ngx_wakeup_worker_thread(cycle);        
66.                      
67.   } else {               
68.    // 處理所有的延后事件           
69.    ngx_event_process_posted(cycle, &ngx_posted_events);   
70.   }                 
71.  }                  
72. }

再來看看ngx_epoll_process_events的相關處理：

1. // 讀事件                                      
2. if ((revents & EPOLLIN) && rev->active) {
3.  if ((flags & NGX_POST_THREAD_EVENTS) && !rev->accept) {
4.   rev->posted_ready = 1;
5.  
6.  } else {
7.   rev->ready = 1;
8.  }                                       
9.  if (flags & NGX_POST_EVENTS) {
10.   queue = (ngx_event_t **) (rev->accept ?
11.       &ngx_posted_accept_events : &ngx_posted_events);
12.   ngx_locked_post_event(rev, queue);
13.  } else {
14.   rev->handler(rev);
15.  }
16. }                                        
17. wev = c->write;
18.  
19. // 寫事件
20. if ((revents & EPOLLOUT) && wev->active) {
21.  if (flags & NGX_POST_THREAD_EVENTS) {
22.   wev->posted_ready = 1;
23.  } else {
24.   wev->ready = 1;
25.  }
26.  
27.  if (flags & NGX_POST_EVENTS) {
28.   ngx_locked_post_event(wev, &ngx_posted_events);
29.  } else {
30.   wev->handler(wev);
31.  }
32. }

處理也相對簡單，如果拿到了accept鎖，就會有NGX_POST_EVENTS標志那么就會放到相應的隊列中。沒有的話就會直接處理事件。

總結

以上就是Nginx服務器中accept鎖的機制與實現詳解的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值。