Nginx 多进程连接请求/事件分发流程分析

Nginx使用多进程的方法进行任务处理,每个worker进程只有一个线程,单线程循环处理全部监听的事件。本文重点分析一下多进程间的负载均衡问题以及Nginx多进程事件处理流程,方便大家自己写程序的时候借鉴。

一、监听建立流程

整个建立监听socket到accept的过程如下图:

说明:

1.main里面调用ngx_init_cycle(src/core/ngx_cycle.c),ngx_init_cycle里面完成很多基本的配置,如文件,共享内存,socket等。

2.上图左上角是ngx_init_cycle里面调用的ngx_open_listening_sockets(src/core/ngx_connection.c)主要完成的工作,包括基本的创建socket,setsockopt,bind和listen等。

3.然后是正常的子进程生成过程。在每个子worker进程的ngx_worker_process_cycle中,在调用ngx_worker_process_init里面调用各模块的初始化操作init_process。一epoll module为例,这里调用ngx_event_process_init,里面初始化多个NGX_EVENT_MODULE类型的module.NGX_EVENT_MODULE类型的只有ngx_event_core_module和ngx_epoll_module。前一个module的actions部分为空。ngx_epoll_module里面的init函数就是ngx_epoll_init。ngx_epoll_init函数主要完成epoll部分相关的初始化,包括epoll_create,设置ngx_event_actions等。

4.初始化完ngx_epoll_module,继续ngx_event_process_init,然后循环设置每个listening socket的read handler为ngx_event_accept.最后将每个listening socket的READ事件添加到epoll进行等待。

5.ngx_event_process_init初始化完成后,每个worker process开始循环处理events&timers。最终调用的是epoll_wait。由于之前listening socket以及加入到epoll,所以如果监听字有read消息,那么久调用rev->handler进行处理,监听字的handler之前已经设置为ngx_event_accept。ngx_event_accept主要是调用accept函数来接受新的客户端套接字client socket。

下面是监听字的处理函数ngx_event_accept流程图:

说明:

1.前半部分主要是通过accept接受新连接字,生成并设置相关结构,然后添加到epoll中。

2.后半部分调用connection中的listening对应的handler,即ngx_xxx_init_connection,其中xxx可以是mail,http和stream。顾名思义,该函数主要是做新的accepted连接字的初始化工作。上图以http module为例,初始化设置了连接字的read handler等。

二、负载均衡问题

Nginx里面通过一个变量ngx_accept_disabled来实施进程间获取客户端连接请求的负载均衡策略。ngx_accept_disabled使用流程图:

说明:

1.ngx_process_events_and_timers函数中,通过ngx_accept_disabled的正负判断当前进程负载高低(大于0,高负载;小于0,低负载)。如果低负载时,不做处理,进程去申请accept锁,监听并接受新的连接。

2.如果是高负载时,ngx_accept_disabled就发挥作用了。这时,不去申请accept锁,让出监听和接受新连接的机会。同时ngx_accept_disabled减1,表示通过让出一次accept申请的机会,该进程的负载将会稍微减轻,直到ngx_accept_disabled最后小于0,重新进入低负载的状态,开始新的accept锁竞争。

参考链接:http://www.jb51.net/article/52177.htm

三、“惊群”问题

“惊群”问题:多个进程同时监听一个套接字,当有新连接到来时,会同时唤醒全部进程,但只能有一个进程与客户端连接成功,造成资源的浪费。

Nginx通过进程间共享互斥锁ngx_accept_mutex来控制多个worker进程对公共监听套接字的互斥访问,获取锁后调用accept取出与客户端已经建立的连接加入epoll,然后释放互斥锁。

Nginx处理流程示意图:

说明:

1.ngx_accept_disabled作为单个进程负载较高(最大允许连接数的7/8)的标记,计算公式:

ngx_accept_disabled = ngx_cycle->connection_n/8 - ngx_cycle->free_connection_n;

即进程可用连接数free_connection_n小于总连接数connection_n的1/8时ngx_accept_disabled大于0;否则小于0.或者说ngx_accept_disabled小于0时,表示可用连接数较多,负载较低;ngx_accept_disabled大于0时,说明可用连接数较少,负载较高。

2.如果进程负载较低时,即ngx_accept_disabled 小于0,进程允许竞争accept锁。

3.如果进程负载较高时,放弃竞争accept锁,同时ngx_accept_disabled 减1,即认为由于让出一次竞争accept锁的机会,负载稍微减轻(ngx_accept_disabled 小于0可用)。由于负载较高时(ngx_accept_disabled >0)只是将ngx_accept_disabled 减1,这里不申请accept锁,所以后续的accept函数会遭遇“惊群”问题,返回错误errno=EAGAIN,直接返回(个人觉得这里有改进的空间,见补充部分)。

ngx_process_events_and_timers函数部分代码如下:

 1 if (ngx_use_accept_mutex) {
 2         if (ngx_accept_disabled > 0) {
 3             ngx_accept_disabled--;
 4
 5         } else {
 6             if (ngx_trylock_accept_mutex(cycle) == NGX_ERROR) {
 7                 return;
 8             }
 9
10             if (ngx_accept_mutex_held) {
11                 flags |= NGX_POST_EVENTS;
12
13             } else {
14                 if (timer == NGX_TIMER_INFINITE
15                     || timer > ngx_accept_mutex_delay)
16                 {
17                     timer = ngx_accept_mutex_delay;
18                 }
19             }
20         }
21     }

4.如果竞争加锁失败(6-7行),直接返回,返回到ngx_worker_process_cycle的for循环里面,此次不参与事件处理,进行下一次循环。

5.如果竞争加锁成功,设置NGX_POST_EVENTS标记,表示将事件先放入队列中,稍后处理,优先释放ngx_accept_mutex,防止单个进程过多占用锁时间,影响事件处理效率。ngx_epoll_process_events函数有如下部分(写事件wev部分也一样):

1 if (flags & NGX_POST_EVENTS) {
2     queue = rev->accept ? &ngx_posted_accept_events
3                         : &ngx_posted_events;
4
5     ngx_post_event(rev, queue);//先将event放入队列,稍后处理
6
7 } else {
8     rev->handler(rev);
9 }

6.从ngx_epoll_process_events返回ngx_process_events_and_timers,然后是处理accept事件(下面代码10行);处理完accept事件,马上释放锁(下面代码13-15行),给其他进程机会去监听连接事件。最后处理一般的连接事件。

 1 delta = ngx_current_msec;
 2
 3 (void) ngx_process_events(cycle, timer, flags);
 4
 5 delta = ngx_current_msec - delta;
 6
 7 ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0,
 8                    "timer delta: %M", delta);
 9
10 ngx_event_process_posted(cycle, &ngx_posted_accept_events);//这里处理ngx_process_events 里面post的accept事件
11
12 //处理完accept事件,马上释放锁
13 if (ngx_accept_mutex_held) {
14     ngx_shmtx_unlock(&ngx_accept_mutex);
15 }
16
17 //在处理一般的connection事件之前,先处理超时。
18 if (delta) {
19     ngx_event_expire_timers();
20 }
21
22 //处理普通的connection事件请求
23 ngx_event_process_posted(cycle, &ngx_posted_events);

7.在处理accept事件时,handler是ngx_event_accept(src/event/ngx_event_accept.c),在这个函数里面,每accept一个新的连接,就更新ngx_accept_disabled。

 1 do {
 2 ...
 3 //接受新连接
 4 accept();
 5 ...
 6 //更新ngx_accept_disabled
 7 ngx_accept_disabled = ngx_cycle->connection_n / 8
 8                               - ngx_cycle->free_connection_n;
 9
10 ...
11
12 }while(ev->available)

补充:

ngx_accept_disabled 减1这条路径很明显没有申请accept锁,所以后面的epoll_wait和accept函数会出现“惊群”问题。建议按如下图改进:

说明:

添加红色框步骤,在负载过高时,ngx_accept_disabled 减1进行均衡操作同时,将accept事件从当前进程epoll中清除。这样epoll当前循环只处理自己的普通connection事件。当然,左侧路径可能执行多次,ngx_disable_accept_events操作只需要执行一次即可。

如果过了一段时间,该进程负载降低,进入右侧路径,在申请accept锁的函数中ngx_trylock_accept_mutex中,申请加锁成功后,会调用ngx_enable_accept_events将accept事件再次加入到epoll中,这样就可以监听accept事件和普通connection事件了。

以上补充部分为个人理解,有错误之处,欢迎指正。

四、多进程(每个进程单线程)高效的原因

一点思考:

1.master/worker多进程模式,保证了系统的稳定。master对多个worker子进程和其他子进程的管理比较方便。由于一般worker进程数与cpu内核数一致,所以不存在大量的子进程生成和管理任务,避免了大量子进程的数据IPC共享开销和切换竞争开销。各worker进程之间也只是重复拷贝了监听字,除了父子进程间传递控制消息,基本没有IPC需求。

2.每个worker单线程,不存在大量线程的生成和同步开销。

以上两个方面都使Nginx避免了过多的同步、竞争、切换和IPC数据传递,即尽可能把cpu从不必要的计算开销中解放出来,只专注于业务计算和流程处理。

解放了CPU之后,就是内存的高效操作了。像cache_manager_process,内存池ngx_pool_t等等。还有可以设置进程的affinity来绑定cpu单个内核等。

这样的模型更简单,大连接量扩展性更好。

“伟大的东西,总是简单的”,此言不虚。

注:引用本人文章请注明出处,谢谢。

时间: 2024-11-10 10:47:55

Nginx 多进程连接请求/事件分发流程分析的相关文章

android事件分发流程

1.描述 说到android事件的分发机制,真的是感觉既熟悉又陌生,因为每次需要用到的时候查看相关的源码,总能找到一些所以然来,但是要根据自己理解从头到尾说一遍,却一点都说不上.总结原因吧,感觉是自己不善于总结,过目就忘,并没有把心思放在上面,自然也就没有一点概念咯~~所以在这里主要是把自己理解的一些东西记录下来,不涉及源代码. 好吧,接下来简单说说android事件分发流程吧,说到事件分发,首先应该想到的是两个类,View和ViewGroup,ViewGroup是继承自View实现的,View

android源码解析(三十)-->触摸事件分发流程

前面一篇文章中我们分析了App返回按键的分发流程,从Native层到ViewRootImpl层到DocorView层到Activity层,以及在Activity中的dispatchKeyEvent方法中分发事件,最终调用了Activity的finish方法,即销毁Activity,所以一般情况下假如我们不重写Activity的onBackPress方法或者是onKeyDown方法,当我们按下并抬起返回按键的时候默认都是销毁当前Activity.而本文中我们主要介绍触摸事件的分发流程,从Nativ

Android View 按键事件分发流程 onTouch onTouchEvent onClick onLongClick 和 onKey onKeyDown onClick

1.为了测试,我们同时将View 设置 onTouch  onTouchEvent  onClick onLongClick 四个事件,经过加打印测试发现,按键分发流程是这样的 如果是短按:onTouch-->>onTouchEvent--->>onClick .长按:onTouch-->>onTouchEvent--->>onLongClick-->>onClick.为什么会是这样? 我们看View 源码 public boolean disp

Touch事件派发流程分析

分native侧事件派发到java侧和Framework派发事件到UI,流程看源码即可,此处不赘叙, Native侧上报事件的干活类图如下: Framework侧派发事件给UI的类图如下:

android touch事件分发流程

韩梦飞沙  韩亚飞  [email protected]  yue31313  han_meng_fei_sha 三个方法:分发触摸事件dispatchTouchEvent.在触摸事件的时候onTouchEvent.在拦截触摸事件的时候onInterceptTouchEvent. dispatch是派遣的意思. 就是分发的意思.  分发触摸事件. intercept 是拦截的意思. on 不仅有 在什么之上的意思,还有 在什么时候的意思. 触摸事件通常从 活动activity 通过 分发触摸事件

从源码的角度分析ViewGruop的事件分发

从源码的角度分析ViewGruop的事件分发. 首先我们来探讨一下,什么是ViewGroup?它和普通的View有什么区别? 顾名思义,ViewGroup就是一组View的集合,它包含很多的子View和子VewGroup,是Android中所有布局的父类或间接父类,像LinearLayout.RelativeLayout等都是继承自ViewGroup的.但ViewGroup实际上也是一个View,只不过比起View,它多了可以包含子View和定义布局参数的功能.ViewGroup继承结构示意图如

从源码角度带你分析 Android View 事件分发 dispatchTouchEvent,onTouch,onTouchEvent,onClick逻辑顺序过程(一)

关于Android View 事件分发过程的文章网络上可以搜到一把大,这里贴一篇代码性的文章,作者也是个牛人:Android事件分发机制完全解析,带你从源码的角度彻底理解(上). 虽然讲的很好,但是看完之后还是感觉有那么点一知半解,于是自己花了点时间从源码研究android 触摸事件分发流程,以下内容仅仅个人理解,如有差错希望指出. 我们先从一个例子看起,先重写一个MyButton 继承Button,代码如下: public class MyButton extends Button { pub

Android查缺补漏(View篇)--事件分发机制源码分析

在上一篇博文中分析了事件分发的流程及规则,本篇会从源码的角度更进一步理解事件分发机制的原理,如果对事件分发规则还不太清楚的童鞋,建议先看一下上一篇博文 <Android查缺补漏(View篇)--事件分发机制> ,先来看一下本篇的分析思路,一会儿会按照事件传递的顺序,针对以下几点进行源码分析: Activity对点击事件的分发过程 PhoneWindow是如何处理点击事件的 顶级View对点击事件的分发过程 View对点击事件的处理过程 Activity对点击事件的分发过程 通过上一篇博文中我们

Android事件分发机制详解:史上最全面、最易懂

前言 Android事件分发机制是每个Android开发者必须了解的基础知识 网上有大量关于Android事件分发机制的文章,但存在一些问题:内容不全.思路不清晰.无源码分析.简单问题复杂化等等 今天,我将全面总结Android的事件分发机制,我能保证这是市面上的最全面.最清晰.最易懂的 本文秉着"结论先行.详细分析在后"的原则,即先让大家感性认识,再通过理性分析从而理解问题: 所以,请各位读者先记住结论,再往下继续看分析: 文章较长,阅读需要较长时间,建议收藏等充足时间再进行阅读 目