什麽是Nginx驚群問題？如何解決它？

咔咔侃技术

對于nginx的驚群問題，我們首先需要理解的是，在nginx啓動過程中，master進程會監聽配置文件中指定的各個端口，然後master進程就會調用fork()方法創建各個子進程，根據進程的工作原理，子進程是會繼承父進程的全部內存數據以及監聽的端口的，也就是說worker進程在啓動之後也是會監聽各個端口的。關于驚群，指的就是當客戶端有新建連接的請求到來時，就會觸發各個worker進程的連接建立事件，但是只有一個worker進程能夠正常處理該事件，而其他的worker進程會發現事件已經失效，從而重新循環進入等待狀態。這種由于一個事件而“驚”起了所有worker進程的現象就是驚群問題。很明顯，如果所有的worker進程都被觸發了，那麽這將消耗大量的資源，本文則主要講解nginx是如何處理驚群問題的。

1. 解決方式

在前面的文章中，我們講到，每個worker進程被創建的時候，都會調用ngx_worker_process_init()方法初始化當前worker進程，這個過程中有一個非常重要的步驟，即每個worker進程都會調用epoll_create()方法爲自己創建一個獨有的epoll句柄。對于每一個需要監聽的端口，都有一個文件描述符與之對應，而worker進程只有將該文件描述符通過epoll_ctl()方法添加到當前進程的epoll句柄中，並且監聽accept事件，此時才會被客戶端的連接建立事件觸發，從而處理該事件。從這裏也可以看出，worker進程如果沒有將所需要監聽的端口對應的文件描述符添加到該進程的epoll句柄中，那麽其是無法被觸發對應的事件的。基于這個原理，nginx就使用了一個共享鎖來控制當前進程是否有權限將需要監聽的端口添加到當前進程的epoll句柄中，也就是說，只有獲取鎖的進程才會監聽目標端口。通過這種方式，就保證了每次事件發生時，只有一個worker進程會被觸發。如下圖所示爲worker進程工作循環的一個示意圖：

什麽是Nginx驚群問題？如何解決它？

這裏關于圖中的流程，需要說明的一點是，每個worker進程在進入循環之後就會嘗試獲取共享鎖，如果沒有獲取到，就會將所監聽的端口的文件描述符從當前進程的epoll句柄中移除（即使並不存在也會移除），這麽做的主要目的是防止丟失客戶端連接事件，即使這可能造成少量的驚群問題，但是並不嚴重。試想一下，如果按照理論，在當前進程釋放鎖的時候就將監聽的端口的文件描述符從epoll句柄中移除，那麽在下一個worker進程獲取鎖之前，這段時間各個端口對應的文件描述符是沒有任何epoll句柄進行監聽的，此時就會造成事件的丟失。如果反過來，按照圖中的在獲取鎖失敗的時候才移除監聽的文件描述符，由于獲取鎖失敗，則說明當前一定有一個進程已經監聽了這些文件描述符，因而此時移除是安全的。但是這樣會造成的一個問題是，按照上圖，當前進程在一個循環執行完畢的時候，會釋放鎖，然後處理其他的事件，注意這個過程中其是沒有釋放所監聽的文件描述符的。此時，如果另一個進程獲取到了鎖，並且監聽了文件描述符，那麽這個時候就有兩個進程監聽了文件描述符，因而此時如果客戶端發生連接建立事件，那麽就會觸發兩個worker進程。這個問題是可以容忍的，主要原因有兩點：

  • 這個時候發生的驚群現象只觸發了更少的worker進程，比起每次都驚起所有的worker進程要好很多；
  • 會發生這種驚群問題的主要原因是，當前進程釋放了鎖，但是沒有釋放所監聽的文件描述符，但是worker進程在釋放鎖之後主要是處理客戶端連接的讀寫事件和檢查標志位，這個過程是非常短的，在處理完之後，其就會嘗試獲取鎖，這個時候就會釋放所監聽的文件描述符了，而相較而言，獲取鎖的worker進程在等待處理客戶端的連接建立事件的事件就更長了，因而會發生驚群問題的概率還是比較小的。

2. 源碼講解

worker進程初始事件的方法主要是在ngx_process_events_and_timers()方法中進行的，下面我們就來看看該方法是如何處理整個流程的，如下是該方法的源碼：

void ngx_process_events_and_timers(ngx_cycle_t *cycle) {
  ngx_uint_t flags;
  ngx_msec_t timer, delta;

  if (ngx_trylock_accept_mutex(cycle) == NGX_ERROR) {
    return;
  }

  // 這裏開始處理事件，對于kqueue模型，其指向的是ngx_kqueue_process_events()方法，
  // 而對于epoll模型，其指向的是ngx_epoll_process_events()方法
  // 這個方法的主要作用是，在對應的事件模型中獲取事件列表，然後將事件添加到ngx_posted_accept_events
  // 隊列或者ngx_posted_events隊列中
  (void) ngx_process_events(cycle, timer, flags);

  // 這裏開始處理accept事件，將其交由ngx_event_accept.c的ngx_event_accept()方法處理；
  ngx_event_process_posted(cycle, &ngx_posted_accept_events);

  // 開始釋放鎖
  if (ngx_accept_mutex_held) {
    ngx_shmtx_unlock(&ngx_accept_mutex);
  }

  // 如果不需要在事件隊列中進行處理，則直接處理該事件
  // 對于事件的處理，如果是accept事件，則將其交由ngx_event_accept.c的ngx_event_accept()方法處理；
  // 如果是讀事件，則將其交由ngx_http_request.c的ngx_http_wait_request_handler()方法處理；
  // 對于處理完成的事件，最後會交由ngx_http_request.c的ngx_http_keepalive_handler()方法處理。

  // 這裏開始處理除accept事件外的其他事件
  ngx_event_process_posted(cycle, &ngx_posted_events);
}

上面的代碼中，我們省略了大部分的檢查工作，只留下了骨架代碼。首先，worker進程會調用ngx_trylock_accept_mutex()方法獲取鎖，這其中如果獲取到了鎖就會監聽各個端口對應的文件描述符。然後會調用ngx_process_events()方法處理epoll句柄中監聽到的事件。接著會釋放共享鎖，最後就是處理已建立連接的客戶端的讀寫事件。下面我們來看一下ngx_trylock_accept_mutex()方法是如何獲取共享鎖的:

ngx_int_t ngx_trylock_accept_mutex(ngx_cycle_t *cycle) {
  // 嘗試使用CAS算法獲取共享鎖
  if (ngx_shmtx_trylock(&ngx_accept_mutex)) {

    // ngx_accept_mutex_held爲1表示當前進程已經獲取到了鎖
    if (ngx_accept_mutex_held && ngx_accept_events == 0) {
      return NGX_OK;
    }

    // 這裏主要是將當前連接的文件描述符注冊到對應事件的隊列中，比如kqueue模型的change_list數組
    // nginx在啓用各個worker進程的時候，默認情況下，worker進程是會繼承master進程所監聽的socket句柄的，
    // 這就導致一個問題，就是當某個端口有客戶端事件時，就會把監聽該端口的進程都給喚醒，
    // 但是只有一個worker進程能夠成功處理該事件，而其他的進程被喚醒之後發現事件已經過期，
    // 因而會繼續進入等待狀態，這種現象稱爲"驚群"現象。
    // nginx解決驚群現象的方式一方面是通過這裏的共享鎖的方式，即只有獲取到鎖的worker進程才能處理
    // 客戶端事件，但實際上，worker進程是通過在獲取鎖的過程中，爲當前worker進程重新添加各個端口的監聽事件，
    // 而其他worker進程則不會監聽。也就是說同一時間只有一個worker進程會監聽各個端口，
    // 這樣就避免了"驚群"問題。
    // 這裏的ngx_enable_accept_events()方法就是爲當前進程重新添加各個端口的監聽事件的。
    if (ngx_enable_accept_events(cycle) == NGX_ERROR) {
      ngx_shmtx_unlock(&ngx_accept_mutex);
      return NGX_ERROR;
    }

    // 標志當前已經成功獲取到了鎖
    ngx_accept_events = 0;
    ngx_accept_mutex_held = 1;

    return NGX_OK;
  }

  // 前面獲取鎖失敗了，因而這裏需要重置ngx_accept_mutex_held的狀態，並且將當前連接的事件給清除掉
  if (ngx_accept_mutex_held) {
    // 如果當前進程的ngx_accept_mutex_held爲1，則將其重置爲0，並且將當前進程在各個端口上的監聽
    // 事件給刪除掉
    if (ngx_disable_accept_events(cycle, 0) == NGX_ERROR) {
      return NGX_ERROR;
    }

    ngx_accept_mutex_held = 0;
  }

  return NGX_OK;
}

上面的代碼中，本質上主要做了三件事：

  • 通過ngx_shmtx_trylock()方法嘗試使用CAS方法獲取共享鎖；
  • 獲取鎖之後則調用ngx_enable_accept_events()方法監聽目標端口對應的文件描述符；
  • 如果沒有獲取到鎖，則調用ngx_disable_accept_events()方法釋放所監聽的文件描述符；

3. 小結

本文首先對驚群現象的産生原因進行了講解，然後介紹了nginx是如何解決驚群問題的，最後從源碼角度對nginx處理驚群問題的方式進行了講解。

轉自：https://my.oschina.net/zhangxufeng/blog/3151282

科技

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。