欢迎来到站长教程网!

Ubuntu

当前位置:主页 > 服务器教程 > Ubuntu >

“惊群”,看看Nginx是怎么解决它的

时间:2019-11-08|栏目:Ubuntu|点击:

在说nginx前,先来看看什么是“惊群”?简单说来,多线程/多进程(linux下线程进程也没多大区别)等待同一个socket事件,当这个事件发生时,这些线程/进程被同时唤醒,就是惊群。可以想见,效率很低下,许多进程被内核重新调度唤醒,同时去响应这一个事件,当然只有一个进程能处理事件成功,其他的进程在处理该事件失败后重新休眠(也有其他选择)。这种性能浪费现象就是惊群。

惊群通常发生在server 上,当父进程绑定一个端口监听socket,然后fork出多个子进程,子进程们开始循环处理(比如accept)这个socket。每当用户发起一个TCP连接时,多个子进程同时被唤醒,然后其中一个子进程accept新连接成功,余者皆失败,重新休眠。

那么,我们不能只用一个进程去accept新连接么?然后通过消息队列等同步方式使其他子进程处理这些新建的连接,这样惊群不就避免了?没错,惊群是避免了,但是效率低下,因为这个进程只能用来accept连接。对多核机器来说,仅有一个进程去accept,这也是程序员在自己创造accept瓶颈。所以,我仍然坚持需要多进程处理accept事件。

其实,在linux2.6内核上,accept系统调用已经不存在惊群了(至少我在2.6.18内核版本上已经不存在)。大家可以写个简单的程序试下,在父进程中bind,listen,然后fork出子进程,所有的子进程都accept这个监听句柄。这样,当新连接过来时,大家会发现,仅有一个子进程返回新建的连接,其他子进程继续休眠在accept调用上,没有被唤醒。

但是很不幸,通常我们的程序没那么简单,不会愿意阻塞在accept调用上,我们还有许多其他网络读写事件要处理,linux下我们爱用epoll解决非阻塞socket。所以,即使accept调用没有惊群了,我们也还得处理惊群这事,因为epoll有这问题。上面说的测试程序,如果我们在子进程内不是阻塞调用accept,而是用epoll_wait,就会发现,新连接过来时,多个子进程都会在epoll_wait后被唤醒!

nginx就是这样,master进程监听端口号(例如80),所有的nginx worker进程开始用epoll_wait来处理新事件(linux下),如果不加任何保护,一个新连接来临时,会有多个worker进程在epoll_wait后被唤醒,然后发现自己accept失败。现在,我们可以看看nginx是怎么处理这个惊群问题了。

nginx的每个worker进程在函数ngx_process_events_and_timers中处理事件,(void) ngx_process_events(cycle, timer, flags);封装了不同的事件处理机制,在linux上默认就封装了epoll_wait调用。我们来看看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 {                   //获得accept锁,多个worker仅有一个可以得到这把锁。获得锁不是阻塞过程,都是立刻返回,获取成功的话ngx_accept_mutex_held被置为1。拿到锁,意味着监听句柄被放到本进程的epoll中了,如果没有拿到锁,则监听句柄会被从epoll中取出。               if (ngx_trylock_accept_mutex(cycle) == NGX_ERROR) {                   return;               }                              //拿到锁的话,置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;                  } else {                       //拿不到锁,也就不会处理监听的句柄,这个timer实际是传给epoll_wait的超时时间,修改为最大ngx_accept_mutex_delay意味着epoll_wait更短的超时返回,以免新连接长时间没有得到处理                   if (timer == NGX_TIMER_INFINITE                       || timer > ngx_accept_mutex_delay)                   {                       timer = ngx_accept_mutex_delay;                   }               }           }       }   。。。 。。。           //linux下,调用ngx_epoll_process_events函数开始处理       (void) ngx_process_events(cycle, timer, flags);   。。。 。。。           //如果ngx_posted_accept_events链表有数据,就开始accept建立新连接       if (ngx_posted_accept_events) {           ngx_event_process_posted(cycle, &ngx_posted_accept_events);       }              //释放锁后再处理下面的EPOLLIN EPOLLOUT请求       if (ngx_accept_mutex_held) {           ngx_shmtx_unlock(&ngx_accept_mutex);       }          if (delta) {           ngx_event_expire_timers();       }          ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0,                      "posted events %p", ngx_posted_events);           //然后再处理正常的数据读写请求。因为这些请求耗时久,所以在ngx_process_events里NGX_POST_EVENTS标志将事件都放入ngx_posted_events链表中,延迟到锁释放了再处理。       if (ngx_posted_events) {           if (ngx_threaded) {               ngx_wakeup_worker_thread(cycle);              } else {               ngx_event_process_posted(cycle, &ngx_posted_events);           }       }   }  

上一篇:rsync ssh实例

栏    目:Ubuntu

下一篇:轻松使用Hadoop RPC

本文标题:“惊群”,看看Nginx是怎么解决它的

本文地址:http://www.jh-floor.com/fuwuqijiaocheng/Ubuntu/122899.html

广告投放 | 联系我们 | 版权申明

重要申明:本站所有的文章、图片、评论等,均由网友发表或上传并维护或收集自网络,属个人行为,与本站立场无关。

如果侵犯了您的权利,请与我们联系,我们将在24小时内进行处理、任何非本站因素导致的法律后果,本站均不负任何责任。

联系QQ:888888 | 邮箱:888888#qq.com(#换成@)

Copyright © 2002-2017 青云站长教程网 版权所有 琼ICP备xxxxxxxx号