亲测，先给出结论：
select不存在惊群效应，每次来一个socket消息，只有一个消费进程被唤醒。
e_poll存在惊群效应，每次来一个socket连接请求，处于空闲状态的消费进程都被唤醒。
先对select机制的测试，直接上代码:
//select测试
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <sys/wait.h>
#include <stdio.h>
#include <string.h>
#define PROCESS_NUM 10
int main()
{
int fd = socket(PF_INET, SOCK_STREAM, 0);
int connfd;
int pid;
char sendbuff[1024];
struct sockaddr_in serveraddr;
serveraddr.sin_family = AF_INET;
serveraddr.sin_addr.s_addr = htonl(INADDR_ANY);
serveraddr.sin_port = htons(1234);
bind(fd, (struct sockaddr*)&serveraddr, sizeof(serveraddr));
listen(fd, 1024);
int i;
for(i = 0; i < PROCESS_NUM; i++)
{
int pid = fork();
if(pid == 0)
{
while(1)
{
connfd = accept(fd, (struct sockaddr*)NULL, NULL);
snprintf(sendbuff, sizeof(sendbuff), "accept PID is %d\n", getpid());
send(connfd, sendbuff, strlen(sendbuff) + 1, 0);
printf("process %d accept success!\n", getpid());
close(connfd);
}
}
}
int status;
wait(&status);
return 0;
}
测试结果，服务端为：
[root@localhost operea_study]# gcc select.c -o a
[root@localhost operea_study]# ./a
process 12515 accept success!
客户端为：
[minping@localhost ~]$ curl 127.0.0.1:1234
accept PID is 12515
[minping@localhost ~]$
证明linux的select不存在惊群效应：当多个进程都阻塞在对同一个socket的accept上，当有一个新的连接到来时，，确实只有一个进程被内核唤醒，其他进程还是继续保持休眠状态。
然后对e_poll的测试：
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/epoll.h>
#include <netdb.h>
#include <string.h>
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <stdlib.h>
#include <errno.h>
#include <sys/wait.h>
#define PROCESS_NUM 10
static int
create_and_bind (char *port)
{
int fd = socket(PF_INET, SOCK_STREAM, 0);
struct sockaddr_in serveraddr;
serveraddr.sin_family = AF_INET;
serveraddr.sin_addr.s_addr = htonl(INADDR_ANY);
serveraddr.sin_port = htons(atoi(port));
bind(fd, (struct sockaddr*)&serveraddr, sizeof(serveraddr));
return fd;
}
static int
make_socket_non_blocking (int sfd)
{
int flags, s;
flags = fcntl (sfd, F_GETFL, 0);
if (flags == -1)
{
perror ("fcntl");
return -1;
}
flags |= O_NONBLOCK;
s = fcntl (sfd, F_SETFL, flags);
if (s == -1)
{
perror ("fcntl");
return -1;
}
return 0;
}
#define MAXEVENTS 64
int
main (int argc, char *argv[])
{
int sfd, s;
int efd;
struct epoll_event event;
struct epoll_event *events;
sfd = create_and_bind("1234");
if (sfd == -1)
abort ();
s = make_socket_non_blocking (sfd);
if (s == -1)
abort ();
s = listen(sfd, SOMAXCONN);
if (s == -1)
{
perror ("listen");
abort ();
}
efd = epoll_create(MAXEVENTS);
if (efd == -1)
{
perror("epoll_create");
abort();
}
event.data.fd = sfd;
//event.events = EPOLLIN | EPOLLET;
event.events = EPOLLIN;
s = epoll_ctl(efd, EPOLL_CTL_ADD, sfd, &event);
if (s == -1)
{
perror("epoll_ctl");
abort();
}
/* Buffer where events are returned */
events = calloc(MAXEVENTS, sizeof event);
int k;
for(k = 0; k < PROCESS_NUM; k++)
{
int pid = fork();
if(pid == 0)
{
/* The event loop */
while (1)
{
int n, i;
n = epoll_wait(efd, events, MAXEVENTS, -1);
printf("process %d return from epoll_wait!\n", getpid());
/* sleep here is very important!*/
//sleep(2);
for (i = 0; i < n; i++)
{
if ((events[i].events & EPOLLERR) || (events[i].events & EPOLLHUP) || (!(events[i].events & EPOLLIN)))
{
/* An error has occured on this fd, or the socket is not
ready for reading (why were we notified then?) */
fprintf (stderr, "epoll error\n");
close (events[i].data.fd);
continue;
}
else if (sfd == events[i].data.fd)
{
/* We have a notification on the listening socket, which
means one or more incoming connections. */
struct sockaddr in_addr;
socklen_t in_len;
int infd;
char hbuf[NI_MAXHOST], sbuf[NI_MAXSERV];
in_len = sizeof in_addr;
infd = accept(sfd, &in_addr, &in_len);
if (infd == -1)
{
printf("process %d accept failed!\n", getpid());
break;
}
printf("process %d accept successed!\n", getpid());
/* Make the incoming socket non-blocking and add it to the
list of fds to monitor. */
close(infd);
}
}
}
}
}
int status;
wait(&status);
free (events);
close (sfd);
return EXIT_SUCCESS;
}
服务端测试结果：
[root@localhost operea_study]# gcc e_poll.c -o b
[root@localhost operea_study]# ./b
process 12778 return from epoll_wait!
process 12779 return from epoll_wait!
process 12779 accept successed!
process 12780 return from epoll_wait!
process 12787 return from epoll_wait!
process 12781 return from epoll_wait!
process 12786 return from epoll_wait!
process 12786 accept failed!
process 12780 accept failed!
process 12785 return from epoll_wait!
process 12782 return from epoll_wait!
process 12783 return from epoll_wait!
process 12784 return from epoll_wait!
process 12784 accept failed!
process 12778 accept failed!
process 12781 accept failed!
process 12787 accept failed!
process 12783 accept failed!
process 12782 accept failed!
process 12785 accept failed!
客户端测试结果：
[minping@localhost ~]$ curl 127.0.0.1:1234
curl: (52) Empty reply from server
[minping@localhost ~]$
发现epoll下，10个监听在这个socket上处于epoll_wait状态的进程，在有连接请求过来的时候，都被唤醒了，惊群效应发生。
再过一下事件的经过：当主进程创建socket，然后bind，然后listen后，将该socket加入到epoll中。然后fork出多个进程，每个进程都阻塞在对这个socket监听的epoll_wait上，当有一个新的连接过来时，发现这些进程全部被唤醒。
那么问题来了，为什么linux内核对select做了修复，避免了惊群效应的发生，而对epoll却不进行处理，到目前为止，epoll还是会发生惊群效应呢？
下面摘抄自网友的一段话，觉得说的还比较在理：
accept确实应该只能被一个进程调用成功，但是epoll的情况就比较复杂，epoll监听的文件描述符，
除了可能后续被accept调用外，还可能是其他网络IO事件的监听对象，那其他网络IO是否只能由一个进程处理我们是不得知的。
所以linux对epoll并没有就惊群效应做修复，而是放之，让用户层自己做处理。
第二个问题，上面说了linux对epoll并没有修复惊群效应问题，而是留给用户层(业务层)自己来处理，那么nginx是怎么处理惊群效应的呢？
nginx的网络架构大致是这样的：读取主配置文件创建socket，bind，listen等一系列动作做好后，fork出一堆子进程(为了最大限度利用cpu，一般几个核就fork几个子进程)，然后每个子进程会调用ngx_event_process_init 函数来初始化自己进程的内部的连接池。ngx_event_process_init 函数还有一个很重要的工作就是：如果如果配置文件里面没有开启accept_mutex锁的话，就通过 ngx_add_event 将监听套接字（socket fd）添加到每个fork出来的子进程的 epoll 中。
每个子进程的ngx_event_process_init 函数执行完后就会在一个死循环中执行ngx_process_events_and_timers，这个函数会读取配置文件里面有没有开启accept mutex锁，如果开启了accept mutex锁，则此进程会尝试获取锁，获取成功就将socket fd当道自己这个子进程的epoll中。ngx_process_events_and_timers再调用 ngx_process_events，在 ngx_process_events这个函数里面阻塞调用 epoll_wait。
总结来说，nginx就是利用 accept_mutex 这把锁来解决epoll_wait惊群问题的。
如果配置文件中没有开启 accept_mutex，则所有的监听套接字不管三七二十一，都加入到每子个进程的 epoll中，这样当一个新的连接来到时，所有的 worker 子进程都会惊醒。
如果配置文件中开启了 accept_mutex，则只有一个子进程会将监听套接字添加到 epoll 中，这样当一个新的连接来到时，当然就只有一个 worker 子进程会被唤醒了。
总结：
1，accept 不会有惊群，epoll_wait 才会。
2，Nginx 的 accept_mutex,并不是解决 accept 惊群问题，而是解决 epoll_wait 惊群问题。
3，说Nginx 解决了 epoll_wait 惊群问题，也是不对的，它只是控制是否将监听套接字加入到子进程的epoll 中。监听套接字只在一个子进程的 epoll 中，当新的连接来到时，其他子进程当然不会惊醒了。
网友评论