声明：图片来自 github：https://github.com/russelltao/geektime-nginx
Nginx请求处理流程
- Nginx运行在企业内网的最外层，也就是边缘节点，它处理的流量是其它服务器处理流量的数倍，甚至是几个数量级。任何问题在不同的数量级之下，解决方案是不同的。所以在Nginx处理的场景中，所有的问题都会被放大。因此我们要去理解为什么Nginx要采用master-worker这种架构模型，为什么worker的数量要和CPU的核数相匹配，当我们需要在多个worker进程之间共享数据的时候，为什么在TLS，或者对一些限流限速这样的场景，他们的共享方式是有所不同的，这些需要我们对Nginx架构有一个清晰地了解。
- Nginx请求处理流程图
- 为什么需要看Nginx请求处理流程？
- 前面了解到Nginx会记录Access日志，Error日志，可以处理静态的资源，可以做反向代理，这些东西，我们从Nginx内部去看，它究竟是怎样处理这些请求，它包含一些什么样的部分？
- 从图左侧开始分析，WEB，EMAIL,TCP大致有三种流量进入Nginx以后，Nginx有三个大的状态机
- 处理TCP，UDP四层的传输层状态机
- 处理应用层的HTTP状态机
- 处理邮件的MAIL状态机。
- 为什么要叫状态机呢？
- 是因为Nginx核心的深绿色的框是用非阻塞的事件驱动处理引擎，也就是我们所熟知的epoll，但我们是用这种异步处理引擎以后，通常需要状态机把请求正确地识别和处理。
- 基于这样一种事件 - 状态处理机，我们在解析出请求，要访问静态资源的时候，走图中左下方的箭头，就找到了静态资源。如果去做反向代理的时候，对反向代理的内容可以做磁盘缓存，缓存到磁盘上，也是走左下方这条线。
- 但是我们在处理静态资源的时候，会有一个问题，当整个内存已经不足以完全地缓存住所有的文件缓存信息的时候，像AIO会退化成阻塞的磁盘调用。所以，在这里，我们需要一个线程池来处理，如图中“使用线程池处理磁盘阻塞调用”。
- 对于每一个处理完成的请求，我们会记录Access日志和Error日志，这里也是记录到磁盘中的
- 也可以通过syslog协议，记录到远程机器上。
- 更多的时候，Nginx是作为负载均衡和反向代理来使用的。这个时候，我们可以把请求通过协议传输给后面的后面的服务器，也可以应用层的一些协议，如FastCGI，uWSGI，SCGI等等代理到应用服务器。