Nginx伺服器中accept鎖的機制與實現詳解

佚名發表於2018-12-19
Nginx伺服器
文章主要給大家介紹了關於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. }
  7. #define ngx_shmtx_lock(mtx) ngx_spinlock((mtx)->lock, ngx_pid, 1024)
  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;
  8. /* 省略一些處理時間事件的程式碼 */
  9. // 這裡是處理負載均衡鎖和accept鎖的時機
  10. if (ngx_use_accept_mutex) {
  11. // 如果負載均衡token的值大於0, 則說明負載已滿，此時不再處理accept, 同時把這個值減一
  12. if (ngx_accept_disabled > 0) {
  13. ngx_accept_disabled--;
  15. } else {
  16. // 嘗試拿到accept鎖
  17. if (ngx_trylock_accept_mutex(cycle) == NGX_ERROR) {
  18. return;
  19. }
  21. // 拿到鎖之後把flag加上post標誌，讓所有事件的處理都延後
  22. // 以免太長時間佔用accept鎖
  23. if (ngx_accept_mutex_held) {
  24. flags |= NGX_POST_EVENTS;
  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;
  37. // 呼叫事件處理模組的process_events，處理一個epoll_wait的方法
  38. (void) ngx_process_events(cycle, timer, flags);
  40. delta = ngx_current_msec - delta; //計算處理events事件所消耗的時間
  42. ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0,
  43. "timer delta: %M", delta);
  45. // 如果有延後處理的accept事件，那麼延後處理這個事件
  46. if (ngx_posted_accept_events) {
  47. ngx_event_process_posted(cycle, &ngx_posted_accept_events);
  48. }
  50. // 釋放accept鎖
  51. if (ngx_accept_mutex_held) {
  52. ngx_shmtx_unlock(&ngx_accept_mutex);
  53. }
  55. // 處理所有的超時事件
  56. if (delta) {
  57. ngx_event_expire_timers();
  58. }
  60. ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0,
  61. "posted events %p", ngx_posted_events);
  63. if (ngx_posted_events) {
  64. if (ngx_threaded) {
  65. ngx_wakeup_worker_thread(cycle);
  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;
  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;
  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. }
  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鎖的機制與實現詳解的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值。

相關文章