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

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

惊群问题解决思路

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

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惊群的场景,不过我不希望会见识到。