nginx 惊群问题解决 && 条件变量虚假唤醒为什么不学着点？

希望打开此篇对你能有所帮助。

@[toc]

惊群问题解决思路

和本文主旨无关的代码我就不放了，上一篇有，因为事关上一篇的主旨。

void ngx_process_events_and_timers(ngx_cycle_t *cycle)
{
    ···
 
    /*ngx_use_accept_mutex表示是否需要通过对accept加锁来解决惊群问题。
    当使用了master模式，nginx worker进程数>1时且配置文件中打开accept_mutex时，这个标志置为1 */
    if (ngx_use_accept_mutex) {
        //负载均衡处理
        if (ngx_accept_disabled > 0) {
            ngx_accept_disabled--;
 
        } else {
            //调用ngx_trylock_accept_mutex方法，尝试获取accept锁
            if (ngx_trylock_accept_mutex(cycle) == NGX_ERROR) {
                return;
            }
 
            //拿到锁
            if (ngx_accept_mutex_held) {
                /*给flags增加标记NGX_POST_EVENTS，这个标记作为处理时间核心函数ngx_process_events的一个参数，
                这个函数中所有事件将延后处理。会把accept事件都放到ngx_posted_accept_events链表中，
                epollin|epollout普通事件都放到ngx_posted_events链表中 */
                flags |= NGX_POST_EVENTS;
            } else {
                /*获取锁失败，意味着既不能让当前worker进程频繁的试图抢锁，也不能让它经过太长事件再去抢锁
                即使开启了timer_resolution时间精度，也需要让ngx_process_change方法在没有新事件的时候至少等待ngx_accept_mutex_delay毫秒之后再去试图抢锁
                而没有开启时间精度时，如果最近一个定时器事件的超时时间距离现在超过了ngx_accept_mutex_delay毫秒，也要把timer设置为ngx_accept_mutex_delay毫秒，
                这是因为当前进程虽然没有抢到accept_mutex锁，但也不能让ngx_process_change方法在没有新事件的时候等待的时间超过ngx_accept_mutex_delay，这会影响整个负载均衡机制*/
                if (timer == NGX_TIMER_INFINITE
                    || timer > ngx_accept_mutex_delay)
                {
                    timer = ngx_accept_mutex_delay;
                }
            }
        }
    }
 
   ···
}

条件变量为什么不学着点？

就拿老生常谈的生产消费者模型来说：为什么会觉得我生产一次的面包只够一个人吃呢？

对于 epoll 惊群的想法

其实挺羡慕那些能讨论 epoll 惊群的小伙伴，我还没试过epoll惊群，据说是开了多条线程或者多个进程，然后挂一个epoll上了是吧，事件到来的时候就会通知一大堆。

不晓得哦，不过我看 nginx 是一个进程一个 epoll 吧。之前看muduo使用reactor模型也是，在mainloop上挂一个epoll，其他subloop都放一个eventfd在mainloop上。

不晓得，不晓得哦，应该是我还没机会见识到epoll惊群的场景，不过我不希望会见识到。