问题：
有一个单进程的linux epoll服务器程序，近来希望将它改写成多进程版本，
主要原因有：
1、在服务高峰期间 并发的 网络请求非常大，目前的单进程版本的支撑不了：单进程时只有一个循环先后处理epoll_wait()到的事件，使得某些不幸排队靠后的socket fd的网络事件得不到及时处理；
2、希望充分利用到服务器的多颗CPU；
但随着改写工作的深入，便第一次碰到了“惊群”问题，程序设想如下：
主进程先监听端口： listen_fd = socket(...);
创建epoll，epoll_fd = epoll_create(...);
然后开始fork()，每个子进程进入大循环，去等待新的accept，epoll_wait(...)，处理事件等。
接着就遇到了“惊群”现象：当listen_fd有新的accept()请求过来，操作系统会唤醒所有子进程（因为这些进程都epoll_wait()同 一个listen_fd，操作系统又无从判断由谁来负责accept，索性干脆全部叫醒……），但最终只会有一个进程成功accept，其他进程 accept失败。外国IT友人认为所有子进程都是被“吓醒”的，所以称之为Thundering Herd（惊群）。
打个比方，街边有一家麦当劳餐厅，里面有4个服务小窗口，每个窗口各有一名服务员。当大门口进来一位新客人，“欢迎光临！”餐厅大门的感应式门铃自动响了 （相当于操作系统底层捕抓到了一个网络事件），于是4个服务员都抬起头（相当于操作系统唤醒了所有服务进程）希望将客人招呼过去自己所在的服务窗口。但结 果可想而知，客人最终只会走向其中某一个窗口，而其他3个窗口的服务员只能“失望叹息”（这一声无奈的叹息就相当于accept()返回EAGAIN错 误），然后埋头继续忙自己的事去。
这样子“惊群”现象必然造成资源浪费，那有木有好的解决办法呢？
寻找解决方法：
看了网上N多帖子和网页，阅读多款优秀开源程序的源代码，再结合自己的实验测试，总结如下：
1、实际情况中，在发生惊群时，并非全部子进程都会被唤醒，而是一部分子进程被唤醒。但被唤醒的进程仍然只有1个成功accept，其他皆失败，errno=EAGAIN。
2、所有基于linux epoll机制的服务器程序在多进程时都受惊群问题的困扰，包括 lighttpd 和 nginx 等程序，各家程序的处理办法也不一样。
lighttpd的解决思路：无视惊群。采 用Watcher/Workers模式，具体措施有优化fork()与epoll_create()的位置（让每个子进程自己去 epoll_create()和epoll_wait()），捕获accept()抛出来的错误并忽视等。这样子一来，当有新accept时仍将有多个 lighttpd子进程被唤醒。
nginx的解决思路：避免惊群。具体措施有使用全局互斥锁，每个子进程在epoll_wait()之前先去申请锁，申请到则继续处理，获取不到则等待，并设置了一个负载均衡的算法（当某一个子进程的任务量达到总设置量的7/8时，则不会再尝试去申请锁）来均衡各个进程的任务量。
3、也流传Linux 2.6.x之后的内核，就已经解决了accept的惊群问题，论文地址 static.usenix.org/event/useni… 。
但其实不然，这篇论文里提到的改进并未能彻底解决实际生产环境中的惊群问题，因为大多数多进程服务器程序都是在fork()之后，再对 epoll_wait(listen_fd,...)的事件，这样子当listen_fd有新的accept请求时，进程们还是会被唤醒。论文的改进主要 是在内核级别让accept()成为原子操作，避免被多个进程都调用了。
多方考量，最后选择参考lighttpd的Watcher/Workers模型，实现了我需要的那款多进程epoll程序，核心流程如下：
主 进程先监听端口， listen_fd = socket(...); ，setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR,...)，setnonblocking(listen_fd)，listen(listen_fd,...)。
开始fork()，到达子进程数上限（建议根据服务器实际的CPU核数来配置）后，主进程变成一个Watcher，只做子进程维护和信号处理等全局性工作。
每 一个子进程（Worker）中，都创建属于自己的epoll，epoll_fd = epoll_create(...);，接着将listen_fd加入epoll_fd中，然后进入大循环，epoll_wait()等待并处理事件。千 万注意， epoll_create()这一步一定要在fork()之后。
大胆设想（未实现）：每个Worker进程采用多线程方式来提高大循环的socket fd处理速度，必要时考虑加入互斥锁来做同步，但\
\
面，以单进程和多进程处理一个http请求为例，分析一下事件处理的流程。我用nginx里面已有的ngx_log_debugX()来插入事件处理的主要函数ngx_epoll_process_events()和ngx_event_process_posted()。在编译的时候，需要加上"--with-debug"参数。并指定nginx.conf里面的"error_log logs/debug.log debug_core | debug_event | debug_http;"。重新启动nginx。
\
单进程(work_processes 1)：
1. 在初始化即ngx_worker_process_init()中调用两次ngx_epoll_add_event()。第一次是在ngx_event_process_init()里面，即给每个监听的端口(在我的例子里只监听80端口)添加一个NGX_READ_EVENT事件；第二次是ngx_add_channel_event()，即给进程间通行的socketpair添加NGX_READ_EVENT事件。
2. 不断调用ngx_epoll_process_events()函数，探测监听的事件是否发生。如果此时有一个http请求进来，就会触发epoll的事件。由于之前每个监听的端口已经设置handler是ngx_event_accept()，这样，就会在ngx_epoll_process_events()里面调用rev->handler(rev)，即调用ngx_event_accept()。在这个函数里，accept()被调用，即接收请求并为其分配一个新的连接，初始化这个新连接，并调用listening socket的handler，即ls->handler(c)。因为ls->handler在http_block()（读取配置之后）里面已经设置了(ls->handler = ngx_http_init_connection;)，那么就会调用ngx_http_init_connection()。而在这个函数里，又会添加一个读事件，并设置其处理钩子是ngx_http_init_request()。
3. epoll触发新的事件调用ngx_http_init_request()，并继续http请求处理的每一个环节。(如process request line，process headers，各个phase等)
4. 最后client关闭了连接(我用的是Linux下的curl)。调用了ngx_http_finalize_request() => ngx_http_finalize_connection() => ngx_http_set_keepalive()。ngx_http_set_keepalive()函数设置事件的处理函数是ngx_http_keepalive_handler()，并调用ngx_post_event()把它添加到ngx_posted_events队列里。然后ngx_event_process_posted()函数就会一一处理并删除队列里所有的事件。在ngx_http_keepalive_handler()函数里，调用ngx_http_close_connection() => ngx_close_connection() => ngx_del_conn(c,NGX_CLOSE_EVENT)。ngx_del_conn()即ngx_epoll_del_connection()，即把这个处理请求的connection从epoll监听的事件列表中删除。
\
\
多进程(我设置了work_processes 2)：和单进程不同，单进程设置epoll timer为-1，即没有事件就一直阻塞在那里，直到监听的端口收到请求。而多进程则不同，每个进程会设置一个epoll_wait()的timeout，去轮番尝试获取在监听端口接受请求的权利，如果没有事件就去处理其它的事件，如果获得了就阻塞(*直到有任意事件发生)
1. 在ngx_event_process_init()里面，只会调用ngx_add_channel_event()给进程间通信的socketpair添加事件，而不给http监听的端口添加事件(为了保证不会有多个工作进程来同时接受请求)。而每个进程被fork()之后，父进程(master process)都会调用ngx_pass_open_channel() => ngx_write_channel() => sendmsg()来通知所有已经存在的进程(这会触发接收方的事件，调用ngx_channel_handler()函数)
2. 在ngx_process_events_and_timers()里，用一个锁来同步所有的进程ngx_trylock_accept_mutex()，并只有一个进程能够得到ngx_accept_mutex这个锁。得到这个锁的进程会调用ngx_enable_accept_events()添加一个监听端口的事件。
3. 在ngx_epoll_process_events()里，调用了ngx_locked_post_event()添加了一个读事件到accept queue(即ngx_posted_accept_events)，然后在ngx_event_process_posted()里面处理，即调用ngx_event_accept()，并添加一个读事件(后面和单进程是一样的)。在处理完ngx_posted_accept_events队列里面的所有accept事件之后，ngx_accept_mutex这个锁也会被释放，即把接受请求的权利让给其它的进程。
\
*在多进程的模式下，每当有新的子进程启动的时候，父进程(master process)都会向其余所有进程的socketpair channel广播新的子进程的channel。这样，就会导致之前获取监听端口权限(即ngx_accept_mutex)的进程触发epoll事件，从而释放ngx_accept_mutex，虽然这个是发生在初始化阶段(之后子进程间一般不通信)，一般不会产生两个或多个进程同时在epoll添加监听端口事件的情况。但是在理论上，这样的设计可能会导致系统的bug(比如有人通过给子进程发送信号的办法来实现一些特殊的功能时，就有可能让其中一个进程放弃ngx_accept_mutex，而另外某一个进程在之后先于它再次获取到ngx_accept_mutex)。
\
\
\
在说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为解决惊群做了什么：
\
\
\
\
void
ngx_process_events_and_timers(ngx_cycle_t *cycle)
{
。。。 。。。
//ngx_use_accept_mutex表示是否需要通过对accept加锁来解决惊群问题。当nginx worker进程数>1时且配置文件中打开accept_mutex时，这个标志置为1
if (ngx_use_accept_mutex) {
//ngx_accept_disabled表示此时满负荷，没必要再处理新连接了，我们在nginx.conf曾经配置了每一个nginx worker进程能够处理的最大连接数，当达到最大数的7/8时，ngx_accept_disabled为正，说明本nginx worker进程非常繁忙，将不再去处理新连接，这也是个简单的负载均衡
if (ngx_accept_disabled > 0) {
ngx_accept_disabled--;
} else {
//获得accept锁，多个worker仅有一个可以得到这把锁。获得锁不是阻塞过程，都是立刻返回，获取成功的话ngx_accept_mutex_held被置为1。拿到锁，意味着监听句柄被放到本进程的epoll中了，如果没有拿到锁，则监听句柄会被从epoll中取出。
if (ngx_trylock_accept_mutex(cycle) == NGX_ERROR) {
return;
}
//拿到锁的话，置flag为NGX_POST_EVENTS，这意味着ngx_process_events函数中，任何事件都将延后处理，会把accept事件都放到ngx_posted_accept_events链表中，epollin|epollout事件都放到ngx_posted_events链表中
if (ngx_accept_mutex_held) {
flags |= NGX_POST_EVENTS;
} else {
//拿不到锁，也就不会处理监听的句柄，这个timer实际是传给epoll_wait的超时时间，修改为最大ngx_accept_mutex_delay意味着epoll_wait更短的超时返回，以免新连接长时间没有得到处理
if (timer == NGX_TIMER_INFINITE
|| timer > ngx_accept_mutex_delay)
{
timer = ngx_accept_mutex_delay;
}
}
}
}
。。。 。。。
//linux下，调用ngx_epoll_process_events函数开始处理
(void) ngx_process_events(cycle, timer, flags);
。。。 。。。
//如果ngx_posted_accept_events链表有数据，就开始accept建立新连接
if (ngx_posted_accept_events) {
ngx_event_process_posted(cycle, &ngx_posted_accept_events);
}
//释放锁后再处理下面的EPOLLIN EPOLLOUT请求
if (ngx_accept_mutex_held) {
ngx_shmtx_unlock(&ngx_accept_mutex);
}
if (delta) {
ngx_event_expire_timers();
}
ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0,
"posted events %p", ngx_posted_events);
//然后再处理正常的数据读写请求。因为这些请求耗时久，所以在ngx_process_events里NGX_POST_EVENTS标志将事件都放入ngx_posted_events链表中，延迟到锁释放了再处理。
if (ngx_posted_events) {
if (ngx_threaded) {
ngx_wakeup_worker_thread(cycle);
} else {
ngx_event_process_posted(cycle, &ngx_posted_events);
}
}
｝
\
