Nginx事件驅動框架處理流程是什么

這篇文章主要介紹“Nginx事件驅動框架處理流程是什么”，在日常操作中，相信很多人在Nginx事件驅動框架處理流程是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Nginx事件驅動框架處理流程是什么”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

ngx_event_core_module模塊的ngx_event_process_init方法對事件模塊做了一些初始化。其中包括將“請求連接”這樣一個讀事件對應的處理方法（handler）設置為ngx_event_accept函數，并將此事件添加到epoll模塊中。當有新連接事件發生時，ngx_event_accept就會被調用。大致流程是這樣：

worker進程在ngx_worker_process_cycle方法中不斷循環調用ngx_process_events_and_timers函數處理事件，這個函數是事件處理的總入口。

ngx_process_events_and_timers會調用ngx_process_events，這是一個宏，相當于ngx_event_actions.process_events，ngx_event_actions是個全局的結構體，存儲了對應事件驅動模塊（這里是epoll模塊）的10個函數接口。所以這里就是調用了ngx_epoll_module_ctx.actions.process_events函數，也就是ngx_epoll_process_events函數來處理事件。

ngx_epoll_process_events調用linux函數接口epoll_wait獲得“有新連接”這個事件，然后調用這個事件的handler處理函數來對這個事件進行處理。

在上面已經說過handler已經被設置成了ngx_event_accept函數，所以就調用ngx_event_accept進行實際的處理。

下面分析ngx_event_accept方法，它的流程圖如下所示：

經過精簡的代碼如下，注釋中的序號對應上圖的序號：

void
ngx_event_accept(ngx_event_t *ev)
{
 socklen_t  socklen;
 ngx_err_t  err;
 ngx_log_t  *log;
 ngx_uint_t  level;
 ngx_socket_t  s;
 ngx_event_t  *rev, *wev;
 ngx_listening_t  *ls;
 ngx_connection_t *c, *lc;
 ngx_event_conf_t *ecf;
 u_char  sa[ngx_sockaddrlen];
 
 if (ev->timedout) {
  if (ngx_enable_accept_events((ngx_cycle_t *) ngx_cycle) != ngx_ok) {
   return;
  }
 
  ev->timedout = 0;
 }
 
 ecf = ngx_event_get_conf(ngx_cycle->conf_ctx, ngx_event_core_module);
 
 if (ngx_event_flags & ngx_use_rtsig_event) {
  ev->available = 1;
 
 } else if (!(ngx_event_flags & ngx_use_kqueue_event)) {
  ev->available = ecf->multi_accept;
 }
 
 lc = ev->data;
 ls = lc->listening;
 ev->ready = 0;
 
 do {
  socklen = ngx_sockaddrlen;
 
  /* 1、accept方法試圖建立連接，非阻塞調用 */
  s = accept(lc->fd, (struct sockaddr *) sa, &socklen);
 
  if (s == (ngx_socket_t) -1)
  {
   err = ngx_socket_errno;
 
   if (err == ngx_eagain)
   {
    /* 沒有連接，直接返回 */
    return;
   }
 
   level = ngx_log_alert;
 
   if (err == ngx_econnaborted) {
    level = ngx_log_err;
 
   } else if (err == ngx_emfile || err == ngx_enfile) {
    level = ngx_log_crit;
   }
 
   if (err == ngx_econnaborted) {
    if (ngx_event_flags & ngx_use_kqueue_event) {
     ev->available--;
    }
 
    if (ev->available) {
     continue;
    }
   }
 
   if (err == ngx_emfile || err == ngx_enfile) {
    if (ngx_disable_accept_events((ngx_cycle_t *) ngx_cycle)
     != ngx_ok)
    {
     return;
    }
 
    if (ngx_use_accept_mutex) {
     if (ngx_accept_mutex_held) {
      ngx_shmtx_unlock(&ngx_accept_mutex);
      ngx_accept_mutex_held = 0;
     }
 
     ngx_accept_disabled = 1;
 
    } else {
     ngx_add_timer(ev, ecf->accept_mutex_delay);
    }
   }
 
   return;
  }
 
  /* 2、設置負載均衡閾值 */
  ngx_accept_disabled = ngx_cycle->connection_n / 8
        - ngx_cycle->free_connection_n;
 
  /* 3、從連接池獲得一個連接對象 */
  c = ngx_get_connection(s, ev->log);
 
  /* 4、為連接創建內存池 */
  c->pool = ngx_create_pool(ls->pool_size, ev->log);
 
  c->sockaddr = ngx_palloc(c->pool, socklen);
 
  ngx_memcpy(c->sockaddr, sa, socklen);
 
  log = ngx_palloc(c->pool, sizeof(ngx_log_t));
 
  /* set a blocking mode for aio and non-blocking mode for others */
  /* 5、設置套接字屬性為阻塞或非阻塞 */
  if (ngx_inherited_nonblocking) {
   if (ngx_event_flags & ngx_use_aio_event) {
    if (ngx_blocking(s) == -1) {
     ngx_log_error(ngx_log_alert, ev->log, ngx_socket_errno,
         ngx_blocking_n " failed");
     ngx_close_accepted_connection(c);
     return;
    }
   }
 
  } else {
   if (!(ngx_event_flags & (ngx_use_aio_event|ngx_use_rtsig_event))) {
    if (ngx_nonblocking(s) == -1) {
     ngx_log_error(ngx_log_alert, ev->log, ngx_socket_errno,
         ngx_nonblocking_n " failed");
     ngx_close_accepted_connection(c);
     return;
    }
   }
  }
 
  *log = ls->log;
 
  c->recv = ngx_recv;
  c->send = ngx_send;
  c->recv_chain = ngx_recv_chain;
  c->send_chain = ngx_send_chain;
 
  c->log = log;
  c->pool->log = log;
 
  c->socklen = socklen;
  c->listening = ls;
  c->local_sockaddr = ls->sockaddr;
  c->local_socklen = ls->socklen;
 
  c->unexpected_eof = 1;
 
  rev = c->read;
  wev = c->write;
 
  wev->ready = 1;
 
  if (ngx_event_flags & (ngx_use_aio_event|ngx_use_rtsig_event)) {
   /* rtsig, aio, iocp */
   rev->ready = 1;
  }
 
  if (ev->deferred_accept) {
   rev->ready = 1;
 
  }
 
  rev->log = log;
  wev->log = log;
 
  /*
   * todo: mt: - ngx_atomic_fetch_add()
   *  or protection by critical section or light mutex
   *
   * todo: mp: - allocated in a shared memory
   *   - ngx_atomic_fetch_add()
   *  or protection by critical section or light mutex
   */
 
  c->number = ngx_atomic_fetch_add(ngx_connection_counter, 1);
 
  if (ls->addr_ntop) {
   c->addr_text.data = ngx_pnalloc(c->pool, ls->addr_text_max_len);
   if (c->addr_text.data == null) {
    ngx_close_accepted_connection(c);
    return;
   }
 
   c->addr_text.len = ngx_sock_ntop(c->sockaddr, c->socklen,
            c->addr_text.data,
            ls->addr_text_max_len, 0);
   if (c->addr_text.len == 0) {
    ngx_close_accepted_connection(c);
    return;
   }
  }
 
  /* 6、將新連接對應的讀寫事件添加到epoll對象中 */
  if (ngx_add_conn && (ngx_event_flags & ngx_use_epoll_event) == 0) {
   if (ngx_add_conn(c) == ngx_error) {
    ngx_close_accepted_connection(c);
    return;
   }
  }
 
  log->data = null;
  log->handler = null;
 
  /* 7、tcp建立成功調用的方法，這個方法在ngx_listening_t結構體中 */
  ls->handler(c);
 
 } while (ev->available); /* available標志表示一次盡可能多的建立連接，由配置項multi_accept決定 */
}

nginx中的“驚群”問題

nginx一般會運行多個worker進程，這些進程會同時監聽同一端口。當有新連接到來時，內核將這些進程全部喚醒，但只有一個進程能夠和客戶端連接成功，導致其它進程在喚醒時浪費了大量開銷，這被稱為“驚群”現象。nginx解決“驚群”的方法是，讓進程獲得互斥鎖ngx_accept_mutex，讓進程互斥地進入某一段臨界區。在該臨界區中，進程將它所要監聽的連接對應的讀事件添加到epoll模塊中，使得當有“新連接”事件發生時，該worker進程會作出反應。這段加鎖并添加事件的過程是在函數ngx_trylock_accept_mutex中完成的。而當其它進程也進入該函數想要添加讀事件時，發現互斥鎖被另外一個進程持有，所以它只能返回，它所監聽的事件也無法添加到epoll模塊，從而無法響應“新連接”事件。但這會出現一個問題：持有互斥鎖的那個進程在什么時候釋放互斥鎖呢？如果需要等待它處理完所有的事件才釋放鎖的話，那么會需要相當長的時間。而在這段時間內，其它worker進程無法建立新連接，這顯然是不可取的。nginx的解決辦法是：通過ngx_trylock_accept_mutex獲得了互斥鎖的進程，在獲得就緒讀/寫事件并從epoll_wait返回后，將這些事件歸類放入隊列中：

新連接事件放入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); /* 不需要延后，則立即處理事件 */
}

寫事件做類似處理。進程接下來處理ngx_posted_accept_events隊列中的事件，處理完后立即釋放互斥鎖，使該進程占用鎖的時間降到了最低。

nginx中的負載均衡問題

nginx中每個進程使用了一個處理負載均衡的閾值ngx_accept_disabled，它在上圖的第2步中被初始化：

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

它的初值為一個負數，該負數的絕對值等于總連接數的7/8.當閾值小于0時正常響應新連接事件，當閾值大于0時不再響應新連接事件，并將ngx_accept_disabled減1，代碼如下：

if (ngx_accept_disabled > 0)
{
  ngx_accept_disabled--;
}
else
{
 if (ngx_trylock_accept_mutex(cycle) == ngx_error)
 {
  return;
 }
 ....
}

這說明，當某個進程當前的連接數達到能夠處理的總連接數的7/8時，負載均衡機制被觸發，進程停止響應新連接。

到此，關于“Nginx事件驅動框架處理流程是什么”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！