Nginx中的“惊群”问题
Nginx一般会运行多个worker进程，这些进程会同时监听同一端口。当有新连接到来时，内核将这些进程全部唤醒，但只有一个进程能够和客户端连接成功，导致其它进程在唤醒时浪费了大量开销，这被称为“惊群”现象。Nginx解决“惊群”的方法是，让进程获得互斥锁ngx_accept_mutex，让进程互斥地进入某一段临界区。在该临界区中，进程将它所要监听的连接对应的读事件添加到epoll模块中，使得当有“新连接”事件发生时，该worker进程会作出反应。这段加锁并添加事件的过程是在函数ngx_trylock_accept_mutex中完成的。而当其它进程也进入该函数想要添加读事件时，发现互斥锁被另外一个进程持有，所以它只能返回，它所监听的事件也无法添加到epoll模块，从而无法响应“新连接”事件。但这会出现一个问题：持有互斥锁的那个进程在什么时候释放互斥锁呢？如果需要等待它处理完所有的事件才释放锁的话，那么会需要相当长的时间。而在这段时间内，其它worker进程无法建立新连接，这显然是不可取的。Nginx的解决办法是：通过ngx_trylock_accept_mutex获得了互斥锁的进程，在获得就绪读/写事件并从epoll_wait返回后，将这些事件归类放入队列中：
新连接事件放入ngx_posted_accept_events队列
已有连接事件放入ngx_posted_events队列
代码如下：
if (flags & NGX_POST_EVENTS)
{
/* 延后处理这批事件 */
queue = (ngx_event_t **) (rev->accept ? &ngx_posted_accept_events : &ngx_posted_events);
/* 将事件添加到延后执行队列中 */
ngx_locked_post_event(rev, queue);
}
else
{
rev->handler(rev); /* 不需要延后，则立即处理事件 */
}
写事件做类似处理。进程接下来处理ngx_posted_accept_events队列中的事件，处理完后立即释放互斥锁，使该进程占用锁的时间降到了最低。
Nginx中的负载均衡问题
Nginx中每个进程使用了一个处理负载均衡的阈值ngx_accept_disabled，它在上图的第2步中被初始化：
ngx_accept_disabled = ngx_cycle->connection_n / 8 - ngx_cycle->free_connection_n;
它的初值为一个负数，该负数的绝对值等于总连接数的7/8.当阈值小于0时正常响应新连接事件，当阈值大于0时不再响应新连接事件，并将ngx_accept_disabled减1，代码如下：
if (ngx_accept_disabled > 0)
{
ngx_accept_disabled--;
}
else
{
if (ngx_trylock_accept_mutex(cycle) == NGX_ERROR)
{
return;
}
....
}
这说明，当某个进程当前的连接数达到能够处理的总连接数的7/8时，负载均衡机制被触发，进程停止响应新连接。
参考：
《深入理解Nginx》 P328-P334.
