Nginx学习笔记之Nginx事件驱动模型

Nginx事件驱动模型

---

• 在我们了解了网络事件以及事件分发收集器以后，再看Nginx是怎么处理事件的。
• 当我们Nginx刚刚启动时，实际上在WAIT FOR EVENTS CONNECTIONS这一块，也就是说我们打开了80或者443端口，这个时候我们在等待新的事件进来。
• 什么样的事件呢？
  • 比如说新的客户端连上了我们的Nginx，它向我们发起来连接，我们在等这样的事件。
• 这样一步，往往对应着我们epoll当中的epoll_wait这样一个方法。
• 这时我们的Nginx其实是处于一个sleep这样一个进程状态。
• 当操作系统接到了一个建立TCP 连接的握手报文，并且处理完握手流程以后，操作系统就会通知我们epoll_wait这个阻塞方法，告诉它你可以往下走了，同时唤醒我们的Nginx的worker进程。
• 我们往下走完以后就去问操作系统要事件。这里的kernel就是操作系统的内核，操作系统会把它准备好的事件放在事件队列中。从这个事件队列中，我们可以获取到我们要处理的一个一个事件，比如建立连接，比如我们收到一个TCP的请求报文我们都可以从这里取出来。取出来以后，我们就会处理这么一个事件。

• 在处理这个事件，我们看右边图，就是处理事件的一个循环。我们发现队列中不为空，我们就把事件取出来，开始处理这个事件。
• 在处理事件的过程中，我可能又会生成新的事件。
  • 比如说，我发现一个连接新建立，那么我可能要添加一个超时时间，比如默认60秒。也就是说60秒之内浏览器不向我发送请求的话，我就会把连接关掉；又比如说，当我发现我收完了完整的http请求以后，我已经可以生成http相应了。这个新生成的响应是需要我可以向操作系统的写缓存区里面去把响应写进去，要求操作系统尽快地把这段响应内容发到浏览器上，其实我期待一个写事件，等等。也就是说我们在处理事件的过程中生成新的事件。
• 也就是说我们下面的队列（左边图下面队列）。生成新的队列放在这里，等待下一次来处理。
• 如果说所以的事件都处理完成以后，我们又会返回到WAIT FOR EVENTS CONNECTIONS这样一个流程。
• 知道Nginx事件循环有什么好处呢？
  • 这个时候我们再去理解，有时候使用一些第三方模块，这些第三方模块可能会做大量的CPU运算，这样的计算任务会导致我处理一个事件的时间非常的长。在我们刚刚所说的这样一个流程图里面，它会导致后续这个队列中的大量事件长时间得不到处理，从而引发恶性循环。也就是它们的操作时间可能已经到了，我们大量的CPU，我们的Nginx的任务都消耗在处理连接，不正常的断开。所以Nginx不能容忍有些第三方模块长时间的消耗大量的CPU进行计算任务就是这么一个原因。我们可以看到如Gzip这样的模块都是不会一次使用大量的CPU，而是分段使用，都与这是有关系的。