linux网络编程惊群现象模拟

对于linux服务器的惊群现象早有耳闻，只是不知道他的具体场景，如今在学linux网络编程多进程模型下，正好遇到这个问题。

如今计算机都是多核了，网络编程框架也逐步丰富多了，我所知道的有多进程、多线程、异步事件驱动常用的三种模型。最经典的模型就是Nginx中所用的Master-Worker多进程异步驱动模型。今天和大家一起讨论一下网络开发中遇到的“惊群”现象。今天周末，结合自己的理解和网上的资料，彻底将“惊群”弄明白。需要弄清楚如下几个问题：

（1）什么是“惊群”，会产生什么问题？
（2）“惊群”的现象怎么用代码模拟出来？

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

何为惊群，简而言之，惊群现象（thundering herd）就是当多个进程和线程在同时阻塞等待同一个事件时，如果这个事件发生，会唤醒所有的进程/线程，但最终只可能有一个进程/线程对该事件进行处理，其他进程/线程会在失败后重新休眠，这种性能浪费就是惊群。例如当以多进程/线程的方式调用accept等待连接时，如果有客户端来连接，所有的accept都会返回(该线程被唤醒了)，但是只有一个是正确的返回。

按照上面所说，应该很好模拟出惊群现象。这个代码好写，就是在多线程/进程里调用accept函数。这里就不再贴代码了。可是执行后我们并没有发现惊群现象，同一时间永远只有一个线程/进程的accept返回。

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

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

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

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define IP   "192.168.0.136"
#define PORT  8887
#define PROCESS_NUM 4
#define MAXEVENTS 64

int sfd, s;
int efd;
struct epoll_event event;
struct epoll_event *events;

static int create_and_bind ()
{
    int fd = socket(PF_INET, SOCK_STREAM, 0);
    struct sockaddr_in serveraddr;
    serveraddr.sin_family = AF_INET;
    inet_pton( AF_INET, IP, &serveraddr.sin_addr);  
    serveraddr.sin_port = htons(PORT);
    int on = 1;
    setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on));
    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;
}

void* func(void* p)  {
    int k = (int)p;
    worker(sfd, efd, events, k);
}

void worker(int sfd, int efd, struct epoll_event *events, int k) {
    /* The event loop */
    while (1) {
        int n, i;
        n = epoll_wait(efd, events, MAXEVENTS, -1);
        //sleep(2);      //如果放开这里就会看到惊群现象
        printf("worker  %d return from epoll_wait!\n", k);
        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("worker %d accept failed!\n", k);
                    break;
                }
                printf("worker %d accept successed!\n", k);
                /* Make the incoming socket non-blocking and add it to the list of fds to monitor. */
                close(infd); 
            }
        }
    }
}

int main (int argc, char *argv[])
{
    sfd = create_and_bind();
    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;
    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++) {
        printf("Create worker %d\n", k+1);
        /*int pid = fork();
        if(pid == 0) {
            printf("worker %d\n", k+1);
            worker(sfd, efd, events, k);
        }*/
        pthread_t t;
        pthread_create(&t, NULL, func, (void*)(k + 1));
    }
    sleep(120);
    free (events);
    close (sfd);
    return EXIT_SUCCESS;
}

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

而当放开worker代码中那行注释的代码，就有惊群现象了：

4个线程都有返回，但只有一个返回正确。

原因可能是，虽然有连接时被唤醒，但是马上就进入挂起状态，而其他线程不知道他曾经被唤醒过，所以才被唤醒了。

把多线程换作多进程也会有同样的效果。

所以解决惊群的问题可以用锁，调用epoll_wait之前申请锁，申请到则继续处理，否则等待。

Nginx中使用mutex互斥锁解决这个问题，具体措施有使用全局互斥锁，每个子进程在epoll_wait()之前先去申请锁，申请到则继续处理，获取不到则等待，并设置了一个负载均衡的算法（当某一个子进程的任务量达到总设置量的7/8时，则不会再尝试去申请锁）来均衡各个进程的任务量。后面深入学习一下Nginx的惊群处理过程。

参考：

https://www.cnblogs.com/Anker/p/7071849.html