原文：http://blog.csdn.net/russell_tao/article/details/7204260
在说nginx前，先来看看什么是“惊群”？简单说来，多线程/多进程（linux下线程进程也没多大区别）等待同一个socket事件，当这个事件发生时，这些线程/进程被同时唤醒，就是惊群。可以想见，效率很低下，许多进程被内核重新调度唤醒，同时去响应这一个事件，当然只有一个进程能处理事件成功，其他的进程在处理该事件失败后重新休眠（也有其他选择）。这种性能浪费现象就是惊群。
惊群通常发生在server 上，当父进程绑定一个端口监听socket，然后fork出多个子进程，子进程们开始循环处理（比如accept）这个socket。每当用户发起一个TCP连接时，多个子进程同时被唤醒，然后其中一个子进程accept新连接成功，余者皆失败，重新休眠。
那么，我们不能只用一个进程去accept新连接么？然后通过消息队列等同步方式使其他子进程处理这些新建的连接，这样惊群不就避免了？没错，惊群是避免了，但是效率低下，因为这个进程只能用来accept连接。对多核机器来说，仅有一个进程去accept，这也是程序员在自己创造accept瓶颈。所以，我仍然坚持需要多进程处理accept事件。
其实，在linux2.6内核上，accept系统调用已经不存在惊群了（至少我在2.6.18内核版本上已经不存在）。大家可以写个简单的程序试下，在父进程中bind,listen，然后fork出子进程，所有的子进程都accept这个监听句柄。这样，当新连接过来时，大家会发现，仅有一个子进程返回新建的连接，其他子进程继续休眠在accept调用上，没有被唤醒。
但是很不幸，通常我们的程序没那么简单，不会愿意阻塞在accept调用上，我们还有许多其他网络读写事件要处理，linux下我们爱用epoll解决非阻塞socket。所以，即使accept调用没有惊群了，我们也还得处理惊群这事，因为epoll有这问题。上面说的测试程序，如果我们在子进程内不是阻塞调用accept，而是用epoll_wait，就会发现，新连接过来时，多个子进程都会在epoll_wait后被唤醒！
nginx就是这样，master进程监听端口号（例如80），所有的nginx worker进程开始用epoll_wait来处理新事件（linux下），如果不加任何保护，一个新连接来临时，会有多个worker进程在epoll_wait后被唤醒，然后发现自己accept失败。现在，我们可以看看nginx是怎么处理这个惊群问题了。
nginx的每个worker进程在函数ngx_process_events_and_timers中处理事件，(void) ngx_process_events(cycle, timer, flags);封装了不同的事件处理机制，在linux上默认就封装了epoll_wait调用。我们来看看ngx_process_events_and_timers为解决惊群做了什么：
1 void 2 ngx_process_events_and_timers(ngx_cycle_t *cycle) 3 { 4 。。。 。。。 5 //ngx_use_accept_mutex表示是否需要通过对accept加锁来解决惊群问题。当nginx worker进程数>1时且配置文件中打开accept_mutex时，这个标志置为1 6 if (ngx_use_accept_mutex) { 7 //ngx_accept_disabled表示此时满负荷，没必要再处理新连接了，我们在nginx.conf曾经配置了每一个nginx worker进程能够处理的最大连接数，当达到最大数的7/8时，ngx_accept_disabled为正，说明本nginx worker进程非常繁忙，将不再去处理新连接，这也是个简单的负载均衡 8 if (ngx_accept_disabled > 0) { 9 ngx_accept_disabled--; 10 11 } else { 12 //获得accept锁，多个worker仅有一个可以得到这把锁。获得锁不是阻塞过程，都是立刻返回，获取成功的话ngx_accept_mutex_held被置为1。拿到锁，意味着监听句柄被放到本进程的epoll中了，如果没有拿到锁，则监听句柄会被从epoll中取出。 13 if (ngx_trylock_accept_mutex(cycle) == NGX_ERROR) { 14 return; 15 } 16 17 //拿到锁的话，置flag为NGX_POST_EVENTS，这意味着ngx_process_events函数中，任何事件都将延后处理，会把accept事件都放到ngx_posted_accept_events链表中，epollin|epollout事件都放到ngx_posted_events链表中 18 if (ngx_accept_mutex_held) { 19 flags |= NGX_POST_EVENTS; 20 21 } else { 22 //拿不到锁，也就不会处理监听的句柄，这个timer实际是传给epoll_wait的超时时间，修改为最大ngx_accept_mutex_delay意味着epoll_wait更短的超时返回，以免新连接长时间没有得到处理 23 if (timer == NGX_TIMER_INFINITE 24 || timer > ngx_accept_mutex_delay) 25 { 26 timer = ngx_accept_mutex_delay; 27 } 28 } 29 } 30 } 31 。。。 。。。 32 //linux下，调用ngx_epoll_process_events函数开始处理 33 (void) ngx_process_events(cycle, timer, flags); 34 。。。 。。。 35 //如果ngx_posted_accept_events链表有数据，就开始accept建立新连接 36 if (ngx_posted_accept_events) { 37 ngx_event_process_posted(cycle, &ngx_posted_accept_events); 38 } 39 40 //释放锁后再处理下面的EPOLLIN EPOLLOUT请求 41 if (ngx_accept_mutex_held) { 42 ngx_shmtx_unlock(&ngx_accept_mutex); 43 } 44 45 if (delta) { 46 ngx_event_expire_timers(); 47 } 48 49 ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0, 50 "posted events %p", ngx_posted_events); 51 //然后再处理正常的数据读写请求。因为这些请求耗时久，所以在ngx_process_events里NGX_POST_EVENTS标志将事件都放入ngx_posted_events链表中，延迟到锁释放了再处理。 52 if (ngx_posted_events) { 53 if (ngx_threaded) { 54 ngx_wakeup_worker_thread(cycle); 55 56 } else { 57 ngx_event_process_posted(cycle, &ngx_posted_events); 58 } 59 } 60 ｝
从上面的注释可以看到，无论有多少个nginx worker进程，同一时刻只能有一个worker进程在自己的epoll中加入监听的句柄。这个处理accept的nginx worker进程置flag为NGX_POST_EVENTS，这样它在接下来的ngx_process_events函数（在linux中就是ngx_epoll_process_events函数）中不会立刻处理事件，延后，先处理完所有的accept事件后，释放锁，然后再处理正常的读写socket事件。我们来看下ngx_epoll_process_events是怎么做的：
1 static ngx_int_t 2 ngx_epoll_process_events(ngx_cycle_t *cycle, ngx_msec_t timer, ngx_uint_t flags) 3 { 4 。。。 。。。 5 events = epoll_wait(ep, event_list, (int) nevents, timer); 6 。。。 。。。 7 ngx_mutex_lock(ngx_posted_events_mutex); 8 9 for (i = 0; i < events; i++) { 10 c = event_list[i].data.ptr; 11 12 。。。 。。。 13 14 rev = c->read; 15 16 if ((revents & EPOLLIN) && rev->active) { 17 。。。 。。。 18 //有NGX_POST_EVENTS标志的话，就把accept事件放到ngx_posted_accept_events队列中，把正常的事件放到ngx_posted_events队列中延迟处理 19 if (flags & NGX_POST_EVENTS) { 20 queue = (ngx_event_t **) (rev->accept ? 21 &ngx_posted_accept_events : &ngx_posted_events); 22 23 ngx_locked_post_event(rev, queue); 24 25 } else { 26 rev->handler(rev); 27 } 28 } 29 30 wev = c->write; 31 32 if ((revents & EPOLLOUT) && wev->active) { 33 。。。 。。。 34 //同理，有NGX_POST_EVENTS标志的话，写事件延迟处理，放到ngx_posted_events队列中 35 if (flags & NGX_POST_EVENTS) { 36 ngx_locked_post_event(wev, &ngx_posted_events); 37 38 } else { 39 wev->handler(wev); 40 } 41 } 42 } 43 44 ngx_mutex_unlock(ngx_posted_events_mutex); 45 46 return NGX_OK; 47 }
看看ngx_use_accept_mutex在何种情况下会被打开：
1 if (ccf->master && ccf->worker_processes > 1 && ecf->accept_mutex) { 2 ngx_use_accept_mutex = 1; 3 ngx_accept_mutex_held = 0; 4 ngx_accept_mutex_delay = ecf->accept_mutex_delay; 5 6 } else { 7 ngx_use_accept_mutex = 0; 8 }
当nginx worker数量大于1时，也就是多个进程可能accept同一个监听的句柄，这时如果配置文件中accept_mutex开关打开了，就将ngx_use_accept_mutex置为1。
再看看有些负载均衡作用的ngx_accept_disabled是怎么维护的，在ngx_event_accept函数中：
1 ngx_accept_disabled = ngx_cycle->connection_n / 8 2 - ngx_cycle->free_connection_n;
表明，当已使用的连接数占到在nginx.conf里配置的worker_connections总数的7/8以上时，ngx_accept_disabled为正，这时本worker将ngx_accept_disabled减1，而且本次不再处理新连接。
最后，我们看下ngx_trylock_accept_mutex函数是怎么玩的：
1 ngx_int_t 2 ngx_trylock_accept_mutex(ngx_cycle_t *cycle) 3 { 4 //ngx_shmtx_trylock是非阻塞取锁的，返回1表示成功，0表示没取到锁 5 if (ngx_shmtx_trylock(&ngx_accept_mutex)) { 6 7 //ngx_enable_accept_events会把监听的句柄都塞入到本worker进程的epoll中 8 if (ngx_enable_accept_events(cycle) == NGX_ERROR) { 9 ngx_shmtx_unlock(&ngx_accept_mutex); 10 return NGX_ERROR; 11 } 12 //ngx_accept_mutex_held置为1，表示拿到锁了，返回 13 ngx_accept_events = 0; 14 ngx_accept_mutex_held = 1; 15 16 return NGX_OK; 17 } 18 19 //处理没有拿到锁的逻辑，ngx_disable_accept_events会把监听句柄从epoll中取出 20 if (ngx_accept_mutex_held) { 21 if (ngx_disable_accept_events(cycle) == NGX_ERROR) { 22 return NGX_ERROR; 23 } 24 25 ngx_accept_mutex_held = 0; 26 } 27 28 return NGX_OK; 29 }
OK，关于锁的细节是如何实现的，这篇限于篇幅就不说了，下篇帖子再来讲。现在大家清楚nginx是怎么处理惊群了吧？简单了说，就是同一时刻只允许一个nginx worker在自己的epoll中处理监听句柄。它的负载均衡也很简单，当达到最大connection的7/8时，本worker不会去试图拿accept锁，也不会去处理新连接，这样其他nginx worker进程就更有机会去处理监听句柄，建立新连接了。而且，由于timeout的设定，使得没有拿到锁的worker进程，去拿锁的频繁更高。