Nginx采用的處理模式也沒什么特別的，大概就是如下的邏輯：

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

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

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

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

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

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

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

ngx_thread_volatile ngx_event_t *ngx_posted_accept_events;        
ngx_thread_volatile ngx_event_t *ngx_posted_events;

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

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

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

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

下面放上ngx_process_events_and_timers 的實現(xiàn)代碼，可以大概一觀相關(guān)的處理：

void                   
ngx_process_events_and_timers(ngx_cycle_t *cycle)        
{                    
 ngx_uint_t flags;               
 ngx_msec_t timer, delta;             
    
	
	/* 省略一些處理時間事件的代碼 */                    
 // 這里是處理負載均衡鎖和accept鎖的時機         
 if (ngx_use_accept_mutex) {            
  // 如果負載均衡token的值大于0, 則說明負載已滿，此時不再處理accept, 同時把這個值減一
  if (ngx_accept_disabled > 0) {           
   ngx_accept_disabled--;            
                    
  } else {                
   // 嘗試拿到accept鎖            
   if (ngx_trylock_accept_mutex(cycle) == NGX_ERROR) {    
    return;              
   }                 
                    
   // 拿到鎖之后把flag加上post標志，讓所有事件的處理都延后   
   // 以免太長時間占用accept鎖          
   if (ngx_accept_mutex_held) {          
    flags |= NGX_POST_EVENTS;          
                    
   } else {               
    if (timer == NGX_TIMER_INFINITE        
     || timer > ngx_accept_mutex_delay)       
    {                
     timer = ngx_accept_mutex_delay; // 最多等ngx_accept_mutex_delay個毫秒，防止占用太久accept鎖
    }                
   }                 
  }                  
 }                    
 delta = ngx_current_msec;             
                    
 // 調(diào)用事件處理模塊的process_events，處理一個epoll_wait的方法    
 (void) ngx_process_events(cycle, timer, flags);       
                    
 delta = ngx_current_msec - delta; //計算處理events事件所消耗的時間   
                    
 ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0,       
     "timer delta: %M", delta);         
                    
 // 如果有延后處理的accept事件，那么延后處理這個事件      
 if (ngx_posted_accept_events) {           
  ngx_event_process_posted(cycle, &ngx_posted_accept_events);   
 }                   
                    
 // 釋放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);      
                    
 if (ngx_posted_events) {             
  if (ngx_threaded) {             
   ngx_wakeup_worker_thread(cycle);         
                    
  } else {                
   // 處理所有的延后事件            
   ngx_event_process_posted(cycle, &ngx_posted_events);    
  }                  
 }                   
}

再來看看ngx_epoll_process_events的相關(guān)處理：

  // 讀事件                                       
  if ((revents & EPOLLIN) && rev->active) {
   if ((flags & NGX_POST_THREAD_EVENTS) && !rev->accept) {
    rev->posted_ready = 1;

   } else {
    rev->ready = 1;
   }                                        
   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) {
   if (flags & NGX_POST_THREAD_EVENTS) {
    wev->posted_ready = 1;
   } else {
    wev->ready = 1;
   }

   if (flags & NGX_POST_EVENTS) {
    ngx_locked_post_event(wev, &ngx_posted_events);
   } else {
    wev->handler(wev);
   }
  }

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

贊(0)
聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉(zhuǎn)載和分享網(wǎng)絡(luò)內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-62778877-8306；郵箱：fanjiao@west.cn。本站原創(chuàng)內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明出處：西部數(shù)碼知識庫 » Nginx中accept鎖的機制與實現(xiàn)詳解

登錄

找回密碼

注冊