nginx如何解决惊群效应

什么是惊群效应

惊群效应（thundering herd）是指多进程（多线程）在同时阻塞等待同一个事件的时候（休眠状态），如果等待的这个事件发生，那么他就会唤醒等待的所有进程（或者线程），但是最终却只能有一个进程（线程）获得这个时间的“控制权”，对该事件进行处理，而其他进程（线程）获取“控制权”失败，只能重新进入休眠状态，这种现象和性能浪费就叫做惊群效应。

惊群效应场景

在早期的Linux版本中，内核对于阻塞在epoll_wait的进程，也是采用全部唤醒的机制，所以存在和accept相似的“惊群”问题。新版本的的解决方案也是只会唤醒等待队列上的个进程或线程，所以，新版本Linux 部分的解决了epoll的“惊群”问题。所谓部分的解决，意思就是：对于部分特殊场景，使用epoll机制，已经不存在“惊群”的问题了，但是对于大多数场景，epoll机制仍然存在“惊群”。

1、场景一：epoll_create()在fork子进程之前：

如果epoll_create()调用在fork子进程之前，那么epoll_create()创建的epfd 会被所有子进程继承。接下来，所有子进程阻塞调用epoll_wait()，等待被监控的描述符（包括用于监听客户连接的监听描述符）出现新事件。如果监听描述符发生可读事件，内核将阻塞队列上排在位的进程/线程唤醒，被唤醒的进程/线程继续执行accept()函数，得到新建立的客户连接描述符connfd。这种情况下，任何一个子进程被唤醒并执行accept()函数都是没有问题的。

但是，接下来，子进程的工作如果是调用epoll_ctl(epfd, EPOLL_CTL_ADD, connfd, &ev);将新建连接的描述符connfd加入到epfd中统一监控的话，因为，当前的epfd是在fork之前创建的，此时系统中只有一个epoll监控文件，即所有子进程共享一个epoll监控文件。任何一个进程（父进程或子进程）向epoll监控文件添加、修改和删除文件描述符时，都会影响到其它进程的epoll_wait。 

后续，当connfd描述符上接收到客户端信息时，内核也无法保证每次都是唤醒同一个进程/线程，来处理这个连接描述符connfd上的读写信息（其它进程可能根本就不认识connfd；或者在不同进程中，相同的描述符对应不同的客户端连接），最终导致连接处理错误。（另外，不同的线程处理同一个连接描述符，也会导致发送的信息乱序）

所以，应该避免epoll_create()在fork子进程之前。关于这一点，据说libevent的文档中有专门的描述。

2、场景二：epoll_create()在fork子进程之后：

如果epoll_create()在fork子进程之后，则每个进程都有自己的epoll监控文件（当某个进程将新建连接的描述符connfd加入到本进程的epfd中统一监控，不会影响其它进程的epoll_wait），但是为了实现并发监听，所有的子进程都会调用 

epoll_ctl(epfd, EPOLL_CTL_ADD, listenfd, &ev); 

将监听描述符加入到监控文件中，也就是说所有子进程都在通过epoll机制轮询同一个监听描述符。如果有新的客户端请求接入，监听描述符出现POLLIN事件（表示描述符可读，有新连接接入），此时内核会唤醒所有的进程，所以“惊群”的问题依然存在。

源码实现

int ngx_cdecl
main(int argc, char *const *argv)
{
    ...
     cycle = ngx_init_cycle(&init_cycle);
    ...
     ngx_master_process_cycle(cycle); // 创建工作进程
    
}

ngx_cycle_t *
ngx_init_cycle(ngx_cycle_t *old_cycle)
{
    ...
    if (ngx_open_listening_sockets(cycle) != NGX_OK) {
        goto failed;
    }
    
}

ngx_int_t
ngx_open_listening_sockets(ngx_cycle_t *cycle)
{
    ... 
  //ngx_socket定义
  //#define ngx_socket          socket
  //#define ngx_socket_n        "socket()"
    s = ngx_socket(ls[i].sockaddr->sa_family, ls[i].type, 0);

    if (bind(s, ls[i].sockaddr, ls[i].socklen) == -1) {
       err = ngx_socket_errno;
    }    

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

nginx解决方式

• 锁

对于这种情况下的“惊群”问题，Nginx的解决方案和《UNP 第三版》第30章中30.7和30.8给出的加锁方案类似,大概就是通过互斥锁对每个进程从epoll_wait到accept之间的处理通过互斥量保护。需要注意的是，对于这种加锁操作，每次只有一个子进程能执行epoll_wait和accept，具体哪个进程得到执行，要看内核调度。所以，为了解决负载均衡的问题，Nginx的解决方案中，每个进程有一个当前连接计数，如果当前连接计数超过大连接的7/8，该进程就停止接收新的连接。

源码实现如下：

void
ngx_process_events_and_timers(ngx_cycle_t *cycle)
{
   ...
   //对监听的sockets事件进行处理

    if (ngx_use_accept_mutex) {
        if (ngx_accept_disabled > 0) {
            ngx_accept_disabled--;

        } else {
            // 加锁成功进行后续处理
            if (ngx_trylock_accept_mutex(cycle) == NGX_ERROR) {
                return;
            }
            //设置网络读写事件延迟处理标志，即在释放锁后处理
            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;
                }
            }
        }
    }

    ...

    //这里面epollwait等待网络事件
    //网络连接事件，放入ngx_posted_accept_events队列
    //网络读写事件，放入ngx_posted_events队列
    (void) ngx_process_events(cycle, timer, flags);
    ...

    //先处理网络连接事件，只有获取到锁，这里才会有连接事件
    ngx_event_process_posted(cycle, &ngx_posted_accept_events);

    //释放锁，让其他进程也能够拿到
    if (ngx_accept_mutex_held) {
        ngx_shmtx_unlock(&ngx_accept_mutex);
    }

    ngx_event_expire_timers();
     //处理网络读写事件
    ngx_event_process_posted(cycle, &ngx_posted_events);
}

• SO_REUSEPORT

nginx 在 1.9.1 版本加入了这个功能，其本质是利用了 Linux 的 reuseport 的特性， 内核允许多个进程 listening socket 到同一个端口上，从内核层面做了负载均衡，每次只唤醒其中一个进程。

修改参数如下，只需要在listen 端口后面加上 reuseport即可 ：

server {
        listen 80 reuseport;
        listen 443 ssl http2 reuseport;
        server_name   xxx.xxx.com;
        charset utf-8;

官方测试情况如下：

网上这方面的内容也非常多，大家可以自行搜索。详细参考 The SO_REUSEPORT socket option [LWN.net]  https://blog.n0p.me/2018/02/2018-02-20-portsharding/

注意：启用REUSEPORT也可能导致一些意想不到的问题，比如单个请求处理的最大延迟可能会增加，可以参考 https://blog.cloudflare.com/the-sad-state-of-linux-socket-balancing/