Nginx5之事件

一.Nginx工作流程

1.Nginx是基于事件驱动的框架,那么什么是事件了?比如在浏览器访问:https://blog.csdn.net/yts1115084429,涉及流程如下:
注:Nginx的每条进程都会存在2个网络事件,也就是读事件跟写事件

• 1.首先向blog.csdn.net建立tcp连接(也就是3次握手),此时对于blog.csdn.net而言,是一个读事件,这个读事件就是建立新连接。
• 2.blog.csdn.net根据用户请求的资源返回资源并断开连接,此时对于blog.csdn.net而言,是一个写事件,这个事件就是返回响应。

2.读事件跟写事件的区别:

• 读事件也就是只读取消息,不返回任何资源,具体操作:建立tcp连接,读取浏览数发送的关闭信息
• 写事件就是只返回响应，具体操作:Nginx需要给浏览器返回响应时,Nginx就把消息写入操作系统,然后发送给用户浏览器。

3.Nginx怎么知道这个信息是事件了?

• 事件收集器/分发器是由Nginx的ngx_event_core_module模块提供的,通过事件分发器/分发者,nginx就可以有效的区分事件,将其归类,并且调用相应的模块进行处理事件。

4.Nginx事件循环


事件循环流程:

• 1.启动Nginx,Nginx会启动80或者443端口等待用户连接,(此时Nginx处于sleep状态)
• 2.sever收到client的tcp连接并处理完握手环节,就会通知我们的epoll wait,告诉它你可以接着进行下一步了，并同时唤醒Nginx worker进程。对应步骤:1步—>2步。
• 3.Nginx会前往操作系统获取事件,操作系统同时会把事件放在队列中,事件就是Nginx从事件队列中获取事件(这个是由epoll wait完成的)。对应步骤:1—> 3，4—>3
• 4.Nginx就开始循环的处理事件,同时也会产生新的事件,此时会把事件存放到事件队列中,等待循环处理,直至事件被处理完成。
• 5.所有事件全部处理完成后,会重新返回到第2步,等待事件中

事件循环处理流程：

• 1.开始处理事件
• 2.为空:判断事件队列是否为空,为空则表示事件已处理完成返回等待事件步骤,等待新的事件。
• 3.不为空:那就把事件拿出来一件件的进行处理,并在处理事件的过程中,又会产生新的事件,此时会把新的事件放入到队列里面,等待前面事件处理完成后再进行处理,然后无限重复这种步骤,直至事件被处理完成。
• 注:通过上述就可以看到,如果事件处理事件过长,就会导致其他事件得不到有效的处理,从而引发恶性循环,导致Nginx没法工作等待,所以Nginx处理事件的效率就决定了当前Nginx的性能,当我们有些需要大量cpu计算的工作时,需要Nginx交给后端去完成,而不是Nginx自己去完成。这也是Nginx作为轻量级web的原因。

5.epoll简单介绍

• 1.epoll是Linux内核为处理大批量文件描述符而作了改进的poll，是Linux下多路复用IO接口select/poll的增强版本，它能显著提高程序在大量并发连接中只有少量活跃的情况下的系统CPU利用率。
• 2.epoll在处理事件的时候,只需遍历存储活跃连接的队列,然后将事件交给Nginx进行处理。
• 参考链接:https://blog.csdn.net/daaikuaichuan/article/details/83862311

6.Nginx处理请求与其他web服务处理请求的区别

• 示例:比如我们访问:https://blog.csdn.net/yts1115084429,此时这条请求分为3个部分: 请求头(request headers),响应头(response headers),响应体(body),默认情况下一条进程同一时间只能处理一个请求。
• 1.首先是接收request headers,对它进行处理,这个时候我就知道把当前请求交给上游的哪个服务器或者模块进行处理
• 2.如果本地处理,就需要判断这个request headers种的Content-Length有没有指定body,如果有,则需要产生一个读事件去对它进行处理
• 3.处理完body之后,返回响应
• 4.如果使用Apache和tTomcat进行处理请求,以上面为例,当进程1在处理headers时,rug 如果出现网络事件不足的情况下,会切换到进程2处理第二步骤,如果此时出现缓存区已满,队列很长的情况,就会切换到进程3来返回响应。默认情况下,每次进行绿色箭头的切换时间是5微秒,当数据量大的时候,cpu的消耗也成指数级增长,也是没法处理大并发的原因。
• 5.如果使用Nginx进行处理,在子进程处理请求时,如果蓝色部分的网络事件已经不满足,那么会自动的从用户态切换到绿色箭头，最终完成请求,你会发现所有的步骤都是在一个进程间完成,就减少了cpu切换事件,提升效率。
• 6.制约Nginx的切换的因素:除非是我们nginx的worker进程所使用的时间片已经到了,而时间片的长度一般是5毫秒到800毫秒;所以我们在nginx的worker的配置上往往会把它的优先级加到最高,比如说我们通常会加到负的19,这样我们的静态优先级提高的比较高的的时候,往往操作系统给我们分的时间片是比较大的;这样我们的nginx才能比较好的在用户态完成请求的切换;使得CPU少做无用功