Nginx 的请求处理流程，你了解吗？

以前咱们已经讲解了 Nginx 的基础内容，接下来咱们开始介绍 Nginx 的架构基础。

为何咱们要讨论 Nginx 的架构基础？

由于 Nginx 运行在企业内网的最外层也就是边缘节点，那么他处理的的流量是其余应用服务器处理流量的数倍，甚至几个数量级，咱们知道任何一种问题在不一样的数量级下，他的解决方案是彻底不一样的，因此在 Nginx 它所处理的应用场景中，全部的问题都会被放大，因此咱们必需要去理解，为何 Nginx 采用 master-worker 这样的一种架构模型，为何 worker 进程的数量要和 CPU 的核数相匹配？当咱们须要在多个 worker 进程之间共享数据的时候，为何在 TLS 或者说限流、限速这样的场景，他们的共享方式是有所不一样的，那么这些都须要咱们对 Nginx 的架构有一个清晰的了解。

下面咱们先来看一下 Nginx 的请求处理流程。

为何要去看 Nginx 中的请求处理流程呢？由于其实在以前中咱们了解到 Nginx 会记录 access 日志和 error 日志，也能够处理静态的资源，那么也能够作反向代理，那么这些东西咱们从 Nginx 内部去看他到底是怎样处理这些请求，它包含一些什么样的组成部分呢？

Nginx 的请求处理流程

咱们从这张图的最左边来看，最左边在 WEB、EMAIL 和 TCP，也就是说大体有三种流量从这里进入 Nginx 之后，咱们 Nginx 中有三个大的状态机，一个是处理 TCP/UDP 的 4 层的传输层状态机和处理应用层的 HTTP 状态以及处理邮件的 MAIL 状态机。

那么为何咱们叫它状态机呢？是由于 Nginx 核心的这个大绿色的框他是用非阻塞的事件驱动处理引擎就是用咱们所熟知的 epoll，那么一旦咱们使用这种异步处理引擎之后，一般都是须要用状态机来把这个请求正确的识别和处理。

基于这样的一种事件状态处理机，咱们在解析出请求须要访问静态资源的时候，咱们看到走左下方的这个箭头，那么它就找到了静态资源，若是咱们去作反向代理的时候呢，那么对反向代理的内容，我能够作磁盘缓存，缓存到磁盘上，也在下面左下方这条线，可是咱们在处理静态资源的时候，会有一个问题就是当整个内存已经不足以彻底的缓存全部的文件和信息的时候，那么像 send File 这样的调用或者 AIO 会退化成阻塞的磁盘调用，因此在这里咱们须要有一个线程池来处理，对于每个处理完成的请求呢，咱们会进入 access 日志或 error 日志。

那么这里也是进入了磁盘中的，固然咱们能够经过 syslog 协议把它进入到远程的机器上，那么更多的时候咱们的 Nginx 是做为负载均衡或者反向代理来使用的，就是咱们能够把请求经过协议级（HTTP，Mail 及 stream（TCP））传输到后面的服务器，也能够经过例如应用层的一些协议（FastCGI、uWSGI、SCGI、memcached）代理到相应的应用服务器。以上就是 Nginx 的请求处理流程。