Linux网络编程“惊群”问题总结

大家好！欢迎来观看小编的作品，小编每天关注各种各样的杂志以及新闻，费劲脑汁编辑最新的娱乐资讯，为的是给大家带来更好的文章，让大家在第一时间了解和知道，即使有的时候创作出来的内容令大家不是太喜欢，也不要生气，小编会不断努力的。谢谢大家！

Linux网络编程“惊群”问题总结

Linux网络编程

1、前言

我从事Linux系统下网络开发将近4年了，经常还是遇到一些问题，只是知其然而不知其所以然，有时候和其他人交流，搞得非常尴尬。如今计算机都是多核了，网络编程框架也逐步丰富多了，我所知道的有多进程、多线程、异步事件驱动常用的三种模型。最经典的模型就是Nginx中所用的Master-Worker多进程异步驱动模型。今天和大家一起讨论一下网络开发中遇到的“惊群”现象。之前只是听说过这个现象，网上查资料也了解了基本概念，在实际的工作中还真没有遇到过。今天周末，结合自己的理解和网上的资料，彻底将“惊群”弄明白。需要弄清楚如下几个问题：

（1）什么是“惊群”，会产生什么问题？

（2）“惊群”的现象怎么用代码模拟出来？

（3）如何处理“惊群”问题，处理“惊群”后的现象又是怎么样呢？

2、何为惊群

如今网络编程中经常用到多进程或多线程模型，大概的思路是父进程创建socket，bind、listen后，通过fork创建多个子进程，每个子进程继承了父进程的socket，调用accpet开始监听等待网络连接。这个时候有多个进程同时等待网络的连接事件，当这个事件发生时，这些进程被同时唤醒，就是“惊群”。这样会导致什么问题呢？我们知道进程被唤醒，需要进行内核重新调度，这样每个进程同时去响应这一个事件，而最终只有一个进程能处理事件成功，其他的进程在处理该事件失败后重新休眠或其他。网络模型如下图所示：

简而言之，惊群现象（thundering herd）就是当多个进程和线程在同时阻塞等待同一个事件时，如果这个事件发生，会唤醒所有的进程，但最终只可能有一个进程/线程对该事件进行处理，其他进程/线程会在失败后重新休眠，这种性能浪费就是惊群。

3、编码模拟“惊群”现象

我们已经知道了“惊群”是怎么回事，那么就按照上面的图编码实现看一下效果。我尝试使用多进程模型，创建一个父进程绑定一个端口监听socket，然后fork出多个子进程，子进程们开始循环处理（比如accept）这个socket。测试代码如下所示：

1 #include 2 #include 3 #include 4 #include 5 #include 6 #include 7 #include 8 #include 9 #include 10 #include 11 12 #define IP "127.0.0.1"13 #define PORT 888814 #define WORKER 415 16 int worker(int listenfd, int i)17 else 30 }31 return 0;32 }33 34 int main()35 58 59 if (pid

编译执行，在本机上使用telnet 127.0.0.1 8888测试，结果如下所示：

按照“惊群"现象，期望结果应该是4个子进程都会accpet到请求，其中只有一个成功，另外三个失败的情况。而实际的结果显示，父进程开始创建4个子进程，每个子进程开始等待accept连接。当telnet连接来的时候，只有worker2 子进程accpet到请求，而其他的三个进程并没有接收到请求。

这是什么原因呢？难道惊群现象是假的吗？于是赶紧google查一下，惊群到底是怎么出现的。

其实在Linux2.6版本以后，内核内核已经解决了accept()函数的“惊群”问题，大概的处理方式就是，当内核接收到一个客户连接后，只会唤醒等待队列上的第一个进程或线程。所以，如果服务器采用accept阻塞调用方式，在最新的Linux系统上，已经没有“惊群”的问题了。

但是，对于实际工程中常见的服务器程序，大都使用select、poll或epoll机制，此时，服务器不是阻塞在accept，而是阻塞在select、poll或epoll_wait，这种情况下的“惊群”仍然需要考虑。接下来以epoll为例分析：

使用epoll非阻塞实现代码如下所示：

1 #include 2 #include 3 #include 4 #include 5 #include 6 #include 7 #include 8 #include 9 #include 10 #include 11 #include 12 #include 13 14 #define IP "127.0.0.1" 15 #define PORT 8888 16 #define PROCESS_NUM 4 17 #define MAXEVENTS 64 18 19 static int create_and_bind () 20 { 21 int fd = socket(PF_INET, SOCK_STREAM, 0); 22 struct sockaddr_in serveraddr; 23 serveraddr.sin_family = AF_INET; 24 inet_pton( AF_INET, IP, &serveraddr.sin_addr); 25 serveraddr.sin_port = htons(PORT); 26 bind(fd, (struct sockaddr*)&serveraddr, sizeof(serveraddr)); 27 return fd; 28 } 29 30 static int make_socket_non_blocking (int sfd) 31 { 32 int flags, s; 33 flags = fcntl (sfd, F_GETFL, 0); 34 if (flags == -1) { 35 perror ("fcntl"); 36 return -1; 37 } 38 flags |= O_NONBLOCK; 39 s = fcntl (sfd, F_SETFL, flags); 40 if (s == -1) { 41 perror ("fcntl"); 42 return -1; 43 } 44 return 0; 45 } 46 47 void worker(int sfd, int efd, struct epoll_event *events, int k) { 48 /* The event loop */ 49 while (1) { 50 int n, i; 51 n = epoll_wait(efd, events, MAXEVENTS, -1); 52 printf("worker %d return from epoll_wait!\n", k); 53 for (i = 0; i

父进程中创建套接字，并设置为非阻塞，开始listen。然后fork出4个子进程，在worker中调用epoll_wait开始accpet连接。使用telnet测试结果如下：

从结果看出，与上面是一样的，只有一个进程接收到连接，其他三个没有收到，说明没有发生惊群现象。这又是为什么呢？

在早期的Linux版本中，内核对于阻塞在epoll_wait的进程，也是采用全部唤醒的机制，所以存在和accept相似的“惊群”问题。新版本的的解决方案也是只会唤醒等待队列上的第一个进程或线程，所以，新版本Linux 部分的解决了epoll的“惊群”问题。所谓部分的解决，意思就是：对于部分特殊场景，使用epoll机制，已经不存在“惊群”的问题了，但是对于大多数场景，epoll机制仍然存在“惊群”。

epoll存在惊群的场景如下：在worker保持工作的状态下，都会被唤醒，例如在epoll_wait后调用sleep一次。改写woker函数如下：

依然感谢大家耐心的看完小编的作品，有不好的地方请大家多多提出宝贵的意见或建议哦，小编会及时改正的。爱你们哟！！