Linux 惊群效应之 Nginx 解决方案

前言

因为项目涉及到 Nginx 一些公共模块的使用，而且也想对惊群效应有个深入的了解，在整理了网上资料以及实践后，记录成文章以便大家复习巩固。

结论

• 不管还是多进程还是多线程，都存在惊群效应，本篇文章使用多进程分析。

• 在 Linux2.6 版本之后，已经解决了系统调用 accept 的惊群效应（前提是没有使用 select、poll、epoll 等事件机制）。

• 目前 Linux 已经部分解决了 epoll 的惊群效应（epoll 在 fork 之前），Linux2.6 是没有解决的。

• Epoll 在 fork 之后创建仍然存在惊群效应，Nginx 使用自己实现的互斥锁解决惊群效应。

惊群效应是什么

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

惊群效应消耗了什么

• Linux 内核对用户进程（线程）频繁地做无效的调度、上下文切换等使系统性能大打折扣。上下文切换（context switch）过高会导致 CPU 像个搬运工，频繁地在寄存器和运行队列之间奔波，更多的时间花在了进程（线程）切换，而不是在真正工作的进程（线程）上面。直接的消耗包括 CPU 寄存器要保存和加载（例如程序计数器）、系统调度器的代码需要执行。间接的消耗在于多核 cache 之间的共享数据。

• 为了确保只有一个进程（线程）得到资源，需要对资源操作进行加锁保护，加大了系统的开销。目前一些常见的服务器软件有的是通过锁机制解决的，比如 Nginx（它的锁机制是默认开启的，可以关闭）；还有些认为惊群对系统性能影响不大，没有去处理，比如 Lighttpd。

Linux 解决方案之 Accept

Linux 2.6 版本之前，监听同一个 socket 的进程会挂在同一个等待队列上，当请求到来时，会唤醒所有等待的进程。

Linux 2.6 版本之后，通过引入一个标记位 WQ_FLAG_EXCLUSIVE，解决掉了 accept 惊群效应。

具体分析会在代码注释里面，accept代码实现片段如下：

唤醒阻塞的 accept 代码片段如下：

Linux 解决方案之 Epoll

在使用 select、poll、epoll、kqueue 等 IO 复用时，多进程（线程）处理链接更加复杂。
在讨论 epoll 的惊群效应时候，需要分为两种情况：

• epoll_create 在 fork 之前创建

• epoll_create 在 fork 之后创建

epoll_create 在 fork 之前创建

与 accept 惊群的原因类似，当有事件发生时，等待同一个文件描述符的所有进程（线程）都将被唤醒，而且解决思路和 accept 一致。

为什么需要全部唤醒？因为内核不知道，你是否在等待文件描述符来调用 accept() 函数，还是做其他事情（信号处理，定时事件）。

此种情况惊群效应已经被解决。

epoll_create 在 fork 之后创建

epoll_create 在 fork 之前创建的话，所有进程共享一个 epoll 红黑数。
如果我们只需要处理 accept 事件的话，貌似世界一片美好了。但是 epoll 并不是只处理 accept 事件，accept 后续的读写事件都需要处理，还有定时或者信号事件。

当连接到来时，我们需要选择一个进程来 accept，这个时候，任何一个 accept 都是可以的。当连接建立以后，后续的读写事件，却与进程有了关联。一个请求与 a 进程建立连接后，后续的读写也应该由 a 进程来做。

当读写事件发生时，应该通知哪个进程呢？Epoll 并不知道，因此，事件有可能错误通知另一个进程，这是不对的。所以一般在每个进程（线程）里面会再次创建一个 epoll 事件循环机制，每个进程的读写事件只注册在自己进程的 epoll 种。

我们知道 epoll 对惊群效应的修复，是建立在共享在同一个 epoll 结构上的。epoll_create 在 fork 之后执行，每个进程有单独的 epoll 红黑树，等待队列，ready 事件列表。因此，惊群效应再次出现了。有时候唤醒所有进程，有时候唤醒部分进程，可能是因为事件已经被某些进程处理掉了，因此不用在通知另外还未通知到的进程了。

Nginx 解决方案之锁的设计

首先我们要知道在用户空间进程间锁实现的原理，起始原理很简单，就是能弄一个让所有进程共享的东西，比如 mmap 的内存，比如文件，然后通过这个东西来控制进程的互斥。

Nginx 中使用的锁是自己来实现的，这里锁的实现分为两种情况，一种是支持原子操作的情况，也就是由 NGX_HAVE_ATOMIC_OPS 这个宏来进行控制的，一种是不支持原子操作，这是是使用文件锁来实现。

锁结构体

如果支持原子操作，则我们可以直接使用 mmap，然后 lock 就保存 mmap 的内存区域的地址
如果不支持原子操作，则我们使用文件锁来实现，这里 fd 表示进程间共享的文件句柄，name 表示文件名

原子锁创建

原子锁获取

TryLock，它是非阻塞的，也就是说它会尝试的获得锁，如果没有获得的话，它会直接返回错误。
Lock，它也会尝试获得锁，而当没有获得他不会立即返回，而是开始进入循环然后不停的去获得锁，知道获得。不过 Nginx 这里还有用到一个技巧，就是每次都会让当前的进程放到 CPU 的运行队列的最后一位，也就是自动放弃 CPU。

原子锁实现
如果系统库支持的情况，此时直接调用OSAtomicCompareAndSwap32Barrier，即 CAS。

如果系统库不支持这个指令的话，Nginx 自己还用汇编实现了一个。

原子锁释放

Unlock 比较简单，和当前进程 id 比较，如果相等，就把 lock 改为 0，说明放弃这个锁。

#define ngx_shmtx_unlock(mtx) (void) ngx_atomic_cmp_set((mtx)->lock, ngx_pid, 0)  

Nginx 解决方案之惊群效应

变量分析

ngx_use_accept_mutex 这个变量，如果有这个变量，说明 Nginx 有必要使用 accept 互斥体，这个变量的初始化在 ngx_event_process_init 中。
ngx_accept_mutex_held 表示当前是否已经持有锁。
ngx_accept_mutex_delay 表示当获得锁失败后，再次去请求锁的间隔时间，这个时间可以在配置文件中设置的。

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

ngx_accept_disabled，这个变量是一个阈值，如果大于 0，说明当前的进程处理的连接过多。

是否使用锁

NGX_POST_EVENTS 标记，设置了这个标记就说明当 socket 有数据被唤醒时，我们并不会马上 accept 或者说读取，而是将这个事件保存起来，然后当我们释放锁之后，才会进行 accept 或者读取这个句柄。

如果没有设置 NGX_POST_EVENTS 标记的话，Nginx 会立即 Accept 或者读取句柄

定时器，这里如果 Nginx 没有获得锁，并不会马上再去获得锁，而是设置定时器，然后在 epoll 休眠(如果没有其他的东西唤醒)。此时如果有连接到达，当前休眠进程会被提前唤醒，然后立即 accept。否则，休眠 ngx_accept_mutex_delay时间，然后继续 tryLock。

获取锁来解决惊群

如上代码，当一个连接来的时候，此时每个进程的 epoll 事件列表里面都是有该 fd 的。抢到该连接的进程先释放锁，在 accept。没有抢到的进程把该 fd 从事件列表里面移除，不必再调用 accept，造成资源浪费。

同时由于锁的控制(以及获得锁的定时器)，每个进程都能相对公平的 accept 句柄，也就是比较好的解决了子进程负载均衡。