Nginx 是如何解決驚羣效應的？

前置知識

linux 網絡處理的基本方法：bind listen accept
epoll 的基本方法：epoll_create epoll_ctl epoll_wait

什麼是驚羣效應？

第一次聽到的這個名詞的時候覺得很是有趣，不知道是個什麼意思，總覺得又是奇怪的中文翻譯導致的。

複雜的說（來源於網絡）TLDR;

驚羣效應（thundering herd）是指多進程（多線程）在同時阻塞等待同一個事件的時候（休眠狀態），如果等待的這個事件發生，那麼他就會喚醒等待的所有進程（或者線程），但是最終卻只能有一個進程（線程）獲得這個時間的 “控制權”，對該事件進行處理，而其他進程（線程）獲取“控制權” 失敗，只能重新進入休眠狀態，這種現象和性能浪費就叫做驚羣效應。

簡單的講（我的大白話）

有一道雷打下來，把很多人都吵醒了，但只有其中一個人去收衣服了。也就是：有一個請求過來了，把很多進程都喚醒了，但只有其中一個能最終處理。

原因 & 問題

說起來其實也簡單，多數時候爲了提高應用的請求處理能力，會使用多進程（多線程）去監聽請求，當請求來時，因爲都有能力處理，所以就都被喚醒了。

而問題就是，最終還是隻能有一個進程能來處理。當請求多了，不停地喚醒、休眠、喚醒、休眠，做了很多的無用功，上下文切換又累，對吧。那怎麼解決這個問題呢？下面就是今天要看的重點，我們看看 nginx 是如何解決這個問題的。

Nginx 架構

第一點我們需要了解 nginx 大致的架構是怎麼樣的。nginx 將進程分爲 master 和 worker 兩類，非常常見的一種 M-S 策略，也就是 master 負責統籌管理 worker，當然它也負責如：啓動、讀取配置文件，監聽處理各種信號等工作。

圖片來自：https://aosabook.org/en/v2/nginx.html

但是，第一個要注意的問題就出現了，master 的工作有且只有這些，對於請求來說它是不管的，就如同圖中所示，請求是直接被 worker 處理的。如此一來，請求應該被哪個 worker 處理呢？worker 內部又是如何處理請求的呢？

Nginx 使用 epoll

接下來我們就要知道 nginx 是如何使用 epoll 來處理請求的。下面可能會涉及到一些源碼的內容，但不用擔心，你不需要全部理解，只需要知道它們的作用就可以了。順便我會簡單描述一下我是如何去找到這些源碼的位置的。

Master 的工作

其實 Master 並不是毫無作爲，至少端口是它來佔的。https://github.com/nginx/nginx/blob/b489ba83e9be446923facfe1a2fe392be3095d1f/src/core/ngx_connection.c#L407C13-L407C13

ngx_open_listening_sockets(ngx_cycle_t *cycle)
{
    .....
    for (i = 0; i < cycle->listening.nelts; i++) {
        .....
        if (bind(s, ls[i].sockaddr, ls[i].socklen) == -1) {

        if (listen(s, ls[i].backlog) == -1) {
}

那麼，根據我們 nginx.conf 的配置文件，看需要監聽哪個端口，於是就去 bind 的了，這裏沒問題。

【發現源碼】這裏我是直接在代碼裏面搜 bind 方法去找的，因爲我知道，不管你怎麼樣，你總是要綁定端口的

然後是創建 worker 的，雖不起眼，但很關鍵。https://github.com/nginx/nginx/blob/b489ba83e9be446923facfe1a2fe392be3095d1f/src/os/unix/ngx_process.c#L186

ngx_spawn_process(ngx_cycle_t *cycle, ngx_spawn_proc_pt proc, void *data,
    char *name, ngx_int_t respawn)
{
    ....
    pid = fork();

【發現源碼】這裏我直接搜 fork，整個項目裏面需要 fork 的情況只有兩個地方，很快就找到了 worker

由於是 fork 創建的，也就是複製了一份 task_struct 結構。所以 master 的幾乎全部它都有。

Worker 的工作

Nginx 有一個分模塊的思想，它將不同功能分成了不同的模塊，而 epoll 自然就是在 ngx_epoll_module.c 中了

https://github.com/nginx/nginx/blob/b489ba83e9be446923facfe1a2fe392be3095d1f/src/event/modules/ngx_epoll_module.c#L330C23-L330C23

ngx_epoll_init(ngx_cycle_t *cycle, ngx_msec_t timer)
{
    ngx_epoll_conf_t  *epcf;

    epcf = ngx_event_get_conf(cycle->conf_ctx, ngx_epoll_module);
    
    if (ep == -1) {
        ep = epoll_create(cycle->connection_n / 2);

其他不重要，就連 epoll_ctl 和 epoll_wait 也不重要了，這裏你需要知道的就是，從調用鏈路來看，是 worker 創建的 epoll 對象，也就是每個 worker 都有自己的 epoll 對象，而監聽的 sokcet 是一樣的！

【發現源碼】這裏更加直接，搜索 epoll_create 肯定就能找到

問題的關鍵

此時問題的關鍵基本就能瞭解了，每個 worker 都有處理能力，請求來了此時應該喚醒誰呢？講道理那不是所有 epoll 都會有事件，所有 worker 都 accept 請求？顯然這樣是不行的。那麼 nginx 是如何解決的呢？

如何解決

解決方式一共有三種，下面我們一個個來看：

accept_mutex（應用層的解決方案）
EPOLLEXCLUSIVE（內核層的解決方案）
SO_REUSEPORT（內核層的解決方案）

accept_mutex

看到 mutex 可能你就知道了，鎖嘛！這也是對於高併發處理的 ” 基操 “ 遇事不決加鎖，沒錯，加鎖肯定能解決問題。https://github.com/nginx/nginx/blob/b489ba83e9be446923facfe1a2fe392be3095d1f/src/event/ngx_event_accept.c#L328

具體代碼就不展示了，其中細節很多，但本質很容易理解，就是當請求來了，誰拿到了這個鎖，誰就去處理。沒拿到的就不管了。鎖的問題很直接，除了慢沒啥不好的，但至少很公平。

EPOLLEXCLUSIVE

EPOLLEXCLUSIVE 是 2016 年 4.5+ 內核新添加的一個 epoll 的標識。它降低了多個進程 / 線程通過 epoll_ctl 添加共享 fd 引發的驚羣概率，使得一個事件發生時，只喚醒一個正在 epoll_wait 阻塞等待喚醒的進程（而不是全部喚醒）。

關鍵是：每次內核只喚醒一個睡眠的進程處理資源

但，這個方案不是完美的解決了，它僅是降低了概率哦。爲什麼這樣說呢？相比於原來全部喚醒，那肯定是好了不少，降低了衝突。但由於本質來說 socket 是共享的，當前進程處理完成的時間不確定，在後面被喚醒的進程可能會發現當前的 socket 已經被之前喚醒的進程處理掉了。

SO_REUSEPORT

Nginx 在 1.9.1 版本加入了這個功能 https://www.nginx.com/blog/socket-sharding-nginx-release-1-9-1/

其本質是利用了 Linux 的 reuseport 的特性，使用 reuseport 內核允許多個進程 listening socket 到同一個端口上，而從內核層面做了負載均衡，每次喚醒其中一個進程。

反應到 Nginx 上就是，每個 Worker 進程都創建獨立的 listening socket，監聽相同的端口，accept 時只有一個進程會獲得連接。效果就和下圖所示一樣。

而使用方式則是：

http {
     server {
          listen 80 reuseport;
          server_name  localhost;
          # ...
     }
}

從官方的測試情況來看確實是厲害

當然，正所謂：完事無絕對，技術無銀彈。這個方案的問題在於內核是不知道你忙還是不忙的。只會無腦的丟給你。與之前的搶鎖對比，搶鎖的進程一定是不忙的，現在手上的工作都已經忙不過來了，沒機會去搶鎖了；而這個方案可能導致，如果當前進程忙不過來了，還是會只要根據 reuseport 的負載規則輪到你了就會發送給你，所以會導致有的請求被前面慢的請求卡住了。

總結

本文，從瞭解什麼 ” 驚羣效應 “到 nginx 架構和 epoll 處理的原理，最終分析三種不同的處理 “驚羣效應” 的方案。分析到這裏，我想你應該明白其實 nginx 這個多隊列服務模型是所存在的一些問題，只不過絕大多數場景已經完完全全夠用了。

參考鏈接

這一篇對於 nginx 鎖內部實現有詳細解析
https://aosabook.org/en/v2/nginx.html
epoll 和驚羣

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Hx6zdbSoXOw7VQxKU72HJA