Nginx解决惊群现象

惊群现象：所有的工作进程都在等待一个socket，当socket客户端连接时，所有工作线程都被唤醒，但最终有且仅有一个工作线程去处理该连接，其他进程又要进入睡眠状态。

Nginx通过控制争抢处理socket的进程数量和抢占ngx_accept_mutex锁解决惊群现象。只有一个ngx_accept_mutex锁，谁拿到锁，谁处理该socket的请求。

如果当前进程的连接数>最大连接数*7/8，则该进程不参与本轮竞争。

//nginx的每个worker进程在函数ngx_process_events_and_timers中处理事件。下面代码是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         {              //工作进程抢占锁，抢占成功的进程将ngx_accept_mutex_held变量置为1。拿到锁，意味着socket被放到本进程的epoll中了，如果没有拿到锁，则socket会被从epoll中取出。              //此处trylock是非阻塞锁，如果没有抢占到锁，进程会立刻返回，处理自己监听的描述符上的读写事件。            if(pthread_mutex_trylock(&ngx_accept_mutex))            {                ngx_accept_mutex_held = 1;            }            else            {                //设置time时间，500ms后就去争抢锁，使得没有拿到锁的worker进程，去拿锁的频繁更高，确保每个进程可以处理几乎相同数量的fd的读写。                timer = 500;                ngx_accept_mutex_held = 0;            }             //拿到锁的话，置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;            }        }        //继续epoll_wait等待处理事件        int num = epoll_wait(epollfd, events, length, timer);        for(int i=0; i<num; ++i)        {            ......            //如果是读事件            if (revents & EPOLLIN)            {                //有NGX_POST_EVENTS标志的话，就把accept事件放到ngx_posted_accept_events队列中，把正常的事件放到ngx_posted_events队列中延迟处理                //新连接事件队列ngx_posted_accept_events                //用户读写事件队列ngx_posted_events                if (flags & NGX_POST_EVENTS)                {                    queue = rev->accept ?                         &ngx_posted_accept_events:                        &ngx_posted_events;                    ngx_post_event(rev, queue);                }                else//处理                {                    rev->handler(rev);                }            }            //如果是写事件            if (revents & EPOLLOUT)            {                //同理，有NGX_POST_EVENTS标志的话，写事件延迟处理，放到ngx_posted_events队列中             if (flags & NGX_POST_EVENTS)             {                ngx_post_event(rev, &ngx_posted_events);            }            else//处理            {                rev->handler(rev);            }        }    }    //先处理新用户的连接事件        ngx_event_process_posted(cycle, &ngx_posted_accept_events);    //释放处理新连接的锁    if(ngx_accept_mutex_held)    {        pthread_mutex_unlock(&ngx_accept_mutex);    }      //再处理已建立连接的用户读写事件      ngx_event_process_posted(cycle, &ngx_posted_events);}

nginx从抢锁、释放锁到处理事件的整个过程，我已经结合代码做了注释，相信大家对整个过程应该已经不陌生了。至于pthread_mutex_trylock()中进程是如何抢占锁的，这就有赖于实现抢占的算法了，此处只是解释处理过程，并不关心抢占实现原理。感兴趣的同学可以自己搜索相关资料。

1.先处理新用户的连接事件，再释放处理新连接的锁，为什这么设计？
如果刚释放锁，就有新连接，刚获得锁的进程要给等待队列中添加sockfd时，此时原获得锁的进程也要从等待队列中删除sockfd，TCP的三次握手的连接是非线程安全的。为了避免产生错误，使得将sockfd从等待队列中删除后，再让新的进程抢占锁，处理新连接。

2.拿到锁，将任务放在任务队列中，不是立刻去处理，为什这么设计？
每个进程要处理新连接事件，必须拿到锁，当前进程将新连接事件的sokect添加到任务队列中，立即释放锁，让其他进程尽快获得锁，处理用户的连接。

你可能有个疑问，如果没有加锁，有新事件连接时，所有的进程都会被唤醒执行accept，有且仅有一个进程会accept返回成功，其他进程都重新进入睡眠状态。现在有了锁，在发生accept之前，进程们要去抢占锁，也是有且仅有一个进程会抢到锁，其他进程也是重新进入睡眠状态。即：不论是否有accept锁，都会有很多进程被唤醒再重新进入睡眠状态的过程，那惊群现象如何解释？

其实，锁不能解决惊群现象，惊群现象是没办法解决的，很多进程被同时唤醒是一个必然的过程。Nginx中通过检查当前进程的连接数是否>最大连接数*7/8来判断当前进程是否能处理新连接，减少被唤醒的进程数量，也实现了简单的负载均衡。锁只能保证不让所有的进程去调用accept函数，解决了很多进程调用accept返回错误，锁解决的是惊群现象的错误，并不是解决了惊群现象！