因为 Nginx 运行在企业内网的最外层也就是边缘节点，那么他处理的的流量是其他应用服务器处理流量的数倍，甚至几个数量级，我们知道任何一种问题在不同的数量级下，他的解决方案是完全不同的，所以在 Nginx 它所处理的应用场景中，所有的问题都会被放大，所以我们必须要去理解，为什么 Nginx 采用 master-worker 这样的一种架构模型，为什么 worker 进程的数量要和 CPU 的核数相匹配？当我们需要在多个 worker 进程之间共享数据的时候，为什么在 TLS 或者说限流、限速这样的场景，他们的共享方式是有所不同的，那么这些都需要我们对 Nginx 的架构有一个清晰的了解。
下面我们先来看一下 Nginx 的请求处理流程。
为什么要去看 Nginx 中的请求处理流程呢？因为其实在之前中我们了解到 Nginx 会记录 access 日志和 error 日志，也可以处理静态的资源，那么也可以做反向代理，那么这些东西我们从 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 的请求处理流程。