AI 助理
备案控制台
开发者社区 开发与运维 文章 正文

“惊群”，看看nginx是怎么解决它的

2015-03-30 1203
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
简介： 在说nginx前，先来看看什么是“惊群”？简单说来，多线程/多进程（linux下线程进程也没多大区别）等待同一个socket事件，当这个事件发生时，这些线程/进程被同时唤醒，就是惊群。可以想见，效率很低下，许多进程被内核重新调度唤醒，同时去响应这一个事件，当然只有一个进程能处理事件成功，其他的进程在处理该事件失败后重新休眠（也有其他选择）。

在说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为解决惊群做了什么：

 

[cpp]  view plain copy
 
  1. void  
  2. ngx_process_events_and_timers(ngx_cycle_t *cycle)  
  3. {  
  4. 。。。 。。。  
  5.     //ngx_use_accept_mutex表示是否需要通过对accept加锁来解决惊群问题。当nginx worker进程数>1时且配置文件中打开accept_mutex时，这个标志置为1  
  6.     if (ngx_use_accept_mutex) {  
  7.             //ngx_accept_disabled表示此时满负荷，没必要再处理新连接了，我们在nginx.conf曾经配置了每一个nginx worker进程能够处理的最大连接数，当达到最大数的7/8时，ngx_accept_disabled为正，说明本nginx worker进程非常繁忙，将不再去处理新连接，这也是个简单的负载均衡  
  8.         if (ngx_accept_disabled > 0) {  
  9.             ngx_accept_disabled--;  
  10.   
  11.         } else {  
  12.                 //获得accept锁，多个worker仅有一个可以得到这把锁。获得锁不是阻塞过程，都是立刻返回，获取成功的话ngx_accept_mutex_held被置为1。拿到锁，意味着监听句柄被放到本进程的epoll中了，如果没有拿到锁，则监听句柄会被从epoll中取出。  
  13.             if (ngx_trylock_accept_mutex(cycle) == NGX_ERROR) {  
  14.                 return;  
  15.             }  
  16.   
  17.                         //拿到锁的话，置flag为NGX_POST_EVENTS，这意味着ngx_process_events函数中，任何事件都将延后处理，会把accept事件都放到ngx_posted_accept_events链表中，epollin|epollout事件都放到ngx_posted_events链表中  
  18.             if (ngx_accept_mutex_held) {  
  19.                 flags |= NGX_POST_EVENTS;  
  20.   
  21.             } else {  
  22.                     //拿不到锁，也就不会处理监听的句柄，这个timer实际是传给epoll_wait的超时时间，修改为最大ngx_accept_mutex_delay意味着epoll_wait更短的超时返回，以免新连接长时间没有得到处理  
  23.                 if (timer == NGX_TIMER_INFINITE  
  24.                     || timer > ngx_accept_mutex_delay)  
  25.                 {  
  26.                     timer = ngx_accept_mutex_delay;  
  27.                 }  
  28.             }  
  29.         }  
  30.     }  
  31. 。。。 。。。  
  32.         //linux下，调用ngx_epoll_process_events函数开始处理  
  33.     (void) ngx_process_events(cycle, timer, flags);  
  34. 。。。 。。。  
  35.         //如果ngx_posted_accept_events链表有数据，就开始accept建立新连接  
  36.     if (ngx_posted_accept_events) {  
  37.         ngx_event_process_posted(cycle, &ngx_posted_accept_events);  
  38.     }  
  39.   
  40.         //释放锁后再处理下面的EPOLLIN EPOLLOUT请求  
  41.     if (ngx_accept_mutex_held) {  
  42.         ngx_shmtx_unlock(&ngx_accept_mutex);  
  43.     }  
  44.   
  45.     if (delta) {  
  46.         ngx_event_expire_timers();  
  47.     }  
  48.   
  49.     ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0,  
  50.                    "posted events %p", ngx_posted_events);  
  51.         //然后再处理正常的数据读写请求。因为这些请求耗时久，所以在ngx_process_events里NGX_POST_EVENTS标志将事件都放入ngx_posted_events链表中，延迟到锁释放了再处理。  
  52.     if (ngx_posted_events) {  
  53.         if (ngx_threaded) {  
  54.             ngx_wakeup_worker_thread(cycle);  
  55.   
  56.         } else {  
  57.             ngx_event_process_posted(cycle, &ngx_posted_events);  
  58.         }  
  59.     }  
  60. ｝  


从上面的注释可以看到，无论有多少个nginx worker进程，同一时刻只能有一个worker进程在自己的epoll中加入监听的句柄。这个处理accept的nginx worker进程置flag为NGX_POST_EVENTS，这样它在接下来的ngx_process_events函数（在linux中就是ngx_epoll_process_events函数）中不会立刻处理事件，延后，先处理完所有的accept事件后，释放锁，然后再处理正常的读写socket事件。我们来看下ngx_epoll_process_events是怎么做的：

 

 

[cpp]  view plain copy
 
  1. static ngx_int_t  
  2. ngx_epoll_process_events(ngx_cycle_t *cycle, ngx_msec_t timer, ngx_uint_t flags)  
  3. {  
  4. 。。。 。。。  
  5.     events = epoll_wait(ep, event_list, (int) nevents, timer);  
  6. 。。。 。。。  
  7.     ngx_mutex_lock(ngx_posted_events_mutex);  
  8.   
  9.     for (i = 0; i < events; i++) {  
  10.         c = event_list[i].data.ptr;  
  11.   
  12. 。。。 。。。  
  13.   
  14.         rev = c->read;  
  15.   
  16.         if ((revents & EPOLLIN) && rev->active) {  
  17. 。。。 。。。  
  18. //有NGX_POST_EVENTS标志的话，就把accept事件放到ngx_posted_accept_events队列中，把正常的事件放到ngx_posted_events队列中延迟处理  
  19.             if (flags & NGX_POST_EVENTS) {  
  20.                 queue = (ngx_event_t **) (rev->accept ?  
  21.                                &ngx_posted_accept_events : &ngx_posted_events);  
  22.   
  23.                 ngx_locked_post_event(rev, queue);  
  24.   
  25.             } else {  
  26.                 rev->handler(rev);  
  27.             }  
  28.         }  
  29.   
  30.         wev = c->write;  
  31.   
  32.         if ((revents & EPOLLOUT) && wev->active) {  
  33. 。。。 。。。  
  34. //同理，有NGX_POST_EVENTS标志的话，写事件延迟处理，放到ngx_posted_events队列中  
  35.             if (flags & NGX_POST_EVENTS) {  
  36.                 ngx_locked_post_event(wev, &ngx_posted_events);  
  37.   
  38.             } else {  
  39.                 wev->handler(wev);  
  40.             }  
  41.         }  
  42.     }  
  43.   
  44.     ngx_mutex_unlock(ngx_posted_events_mutex);  
  45.   
  46.     return NGX_OK;  
  47. }  


看看ngx_use_accept_mutex在何种情况下会被打开：

 

 

[cpp]  view plain copy
 
  1. if (ccf->master && ccf->worker_processes > 1 && ecf->accept_mutex) {  
  2.     ngx_use_accept_mutex = 1;  
  3.     ngx_accept_mutex_held = 0;  
  4.     ngx_accept_mutex_delay = ecf->accept_mutex_delay;  
  5.   
  6. } else {  
  7.     ngx_use_accept_mutex = 0;  
  8. }  


当nginx worker数量大于1时，也就是多个进程可能accept同一个监听的句柄，这时如果配置文件中accept_mutex开关打开了，就将ngx_use_accept_mutex置为1。

 

再看看有些负载均衡作用的ngx_accept_disabled是怎么维护的，在ngx_event_accept函数中：

 

[cpp]  view plain copy
 
  1. ngx_accept_disabled = ngx_cycle->connection_n / 8  
  2.                       - ngx_cycle->free_connection_n;  


表明，当已使用的连接数占到在nginx.conf里配置的worker_connections总数的7/8以上时，ngx_accept_disabled为正，这时本worker将ngx_accept_disabled减1，而且本次不再处理新连接。

 

 

最后，我们看下ngx_trylock_accept_mutex函数是怎么玩的：

 

[cpp]  view plain copy
 
  1. ngx_int_t  
  2. ngx_trylock_accept_mutex(ngx_cycle_t *cycle)  
  3. {  
  4. //ngx_shmtx_trylock是非阻塞取锁的，返回1表示成功，0表示没取到锁  
  5.     if (ngx_shmtx_trylock(&ngx_accept_mutex)) {  
  6.   
  7. //ngx_enable_accept_events会把监听的句柄都塞入到本worker进程的epoll中  
  8.         if (ngx_enable_accept_events(cycle) == NGX_ERROR) {  
  9.             ngx_shmtx_unlock(&ngx_accept_mutex);  
  10.             return NGX_ERROR;  
  11.         }  
  12. //ngx_accept_mutex_held置为1，表示拿到锁了，返回  
  13.         ngx_accept_events = 0;  
  14.         ngx_accept_mutex_held = 1;  
  15.   
  16.         return NGX_OK;  
  17.     }  
  18.   
  19. //处理没有拿到锁的逻辑，ngx_disable_accept_events会把监听句柄从epoll中取出  
  20.     if (ngx_accept_mutex_held) {  
  21.         if (ngx_disable_accept_events(cycle) == NGX_ERROR) {  
  22.             return NGX_ERROR;  
  23.         }  
  24.   
  25.         ngx_accept_mutex_held = 0;  
  26.     }  
  27.   
  28.     return NGX_OK;  
  29. }                                


OK，关于锁的细节是如何实现的，这篇限于篇幅就不说了，下篇帖子再来讲。现在大家清楚nginx是怎么处理惊群了吧？简单了说，就是同一时刻只允许一个nginx worker在自己的epoll中处理监听句柄。它的负载均衡也很简单，当达到最大connection的7/8时，本worker不会去试图拿accept锁，也不会去处理新连接，这样其他nginx worker进程就更有机会去处理监听句柄，建立新连接了。而且，由于timeout的设定，使得没有拿到锁的worker进程，去拿锁的频繁更高。

 转载：http://blog.csdn.net/russell_tao/article/details/7204260

 

文章标签：
应用服务中间件
Linux
nginx
C++
负载均衡
消息中间件
网络协议
程序员
调度
指尖的舞曲
目录
相关文章
Sunny_yiyi
|
7月前
|
JavaScript 应用服务中间件 nginx
Nginx问题分析
Nginx问题分析
Sunny_yiyi
42 1
麒麟改bug
|
7月前
|
负载均衡 前端开发 应用服务中间件
Nginx的作用是什么？有什么用？
Nginx (engine x) 是一个高性能的HTTP和反向代理服务器，也是一个IMAP/POP3/SMTP服务器。Nginx是由伊戈尔·赛索耶夫为俄罗斯访问量第二的Rambler.ru站点（俄文：Рамблер）开发的。由于其非常好用，渐渐被越来越多的人所接受。俄罗斯人的编程能力确实厉害。
麒麟改bug
87 0
pbeskoyq7ffm4
|
4月前
|
安全 应用服务中间件 网络安全
Nginx要怎么配置才算安全
Nginx要怎么配置才算安全
pbeskoyq7ffm4
55 0
蓝易云
|
缓存 Ubuntu 应用服务中间件
Nginx详解（一文带你搞懂Nginx）
Nginx是一款高性能、轻量级的Web服务器软件，它还可以作为反向代理服务器、负载均衡器和HTTP缓存器。在本文中，我们将详细讲解Nginx的基础知识、配置文件、安装和使用方法。
蓝易云
1002 0
Nginx详解（一文带你搞懂Nginx）
叫我默语
|
应用服务中间件 数据库 nginx
Nginx的原理
Nginx的原理
叫我默语
112 1
小小工匠
|
前端开发 应用服务中间件 测试技术
Nginx - 记一次Nginx端口转发失败案例
Nginx - 记一次Nginx端口转发失败案例
小小工匠
387 0
愿天堂没有BUG（公众号同名）
|
监控 负载均衡 算法
Nginx底层原理：一文解析Nginx为什么并发数可以达到3w！
Nginx 以其高性能，稳定性，丰富的功能，简单的配置和低资源消耗而闻名。本文从底层原理分析 Nginx 为什么这么快！
愿天堂没有BUG（公众号同名）
256 0
我是咔咔
|
负载均衡 网络协议 应用服务中间件
【Nginx】第二节 Nginx的优点
【Nginx】第二节 Nginx的优点
我是咔咔
115 0
【Nginx】第二节 Nginx的优点
馒头~
|
前端开发 应用服务中间件 nginx
【Nginx优化】Nginx openresty操作
【Nginx优化】Nginx openresty操作
馒头~
581 0
【Nginx优化】Nginx openresty操作
云栖号资讯小哥
|
缓存 tengine 负载均衡
Nginx是什么 ? 能干嘛 ？
想必大家一定听说过Nginx，若没听说过它？那么一定听过它的"同行"Apache吧！Nginx同Apache一样都是一种WEB服务器。基于REST架构风格，以统一资源描述符(Uniform Resources Identifier)URI或者统一资源定位符(Uniform Resources Locator)URL作为沟通依据，通过HTTP协议提供各种网络服务。
云栖号资讯小哥
4945 2

热门文章

最新文章

  • 1
    使用MaxCompute访问TableStore（OTS） 简明手册
  • 2
    从超模转职成为程序媛是一种怎样的体验
  • 3
    阿里巴巴NACOS（6）- 在k8s上部署Nacos
  • 4
    将任意应用窗口置顶显示，这个工具太强了。
  • 5
    Wi-Fi物联网设备配网的N种方式
  • 6
    WCF分布式安全开发实践(8):消息安全模式之用户名身份验证:Message_UserName_WSHttpBinding
  • 7
    TechED2010与我（二）—— Windows Phone 7 Develop
  • 8
    华尔街认为Twitter出售毫无悬念 只是不会在今年发生
  • 9
    迂者趣事之——下错楼层
  • 10
    Unix Regex
  • 1
    检测指定TCP端口开放状态免费API接口教程
    22
  • 2
    Python 语言：强大、灵活与高效的编程之选
    28
  • 3
    发现一肉鸡接口，快来围攻啦~
    28
  • 4
    深入解析PID控制算法：从理论到实践的完整指南
    26
  • 5
    《C++ 模型训练之早停法：有效预防过拟合的关键策略》
    24
  • 6
    C++构建 GAN 模型：生成器与判别器平衡训练的关键秘籍
    22
  • 7
    通过matlab分别对比PSO,反向学习PSO,多策略改进反向学习PSO三种优化算法
    24
  • 8
    【C语言】宏定义详解
    22
  • 9
    【C语言】进程和线程详解
    17
  • 10
    【C语言】宏定义详解
    20

    • 相关课程

    更多
  • Linux Web服务器Nginx搭建与配置
  • Nginx企业级Web服务实战

    • 相关电子书

    更多
  • 《Nginx 代理系统常用手册》
  • CentOS Nginx PHP JAVA 多语言镜像使用手
  • CentOS Nginx PHP JAVA多语言镜像使用手册

    • 相关实验场景

    更多
  • 日志服务之使用Nginx模式采集日志
    • 下一篇
    阿里云无影云电脑免费试用，最长可试用3个月