原文地址：https://www.cnblogs.com/shitoufengkuang/p/4910333.html

一、前言

1、Nignx版本：1.7.11 以上

2、NGINX采用了异步、事件驱动的方法来处理连接。这种处理方式无需（像使用传统架构的服务器一样）为每个请求创建额外的专用进程或者线程，而是在一个工作进程中处理多个连接和请求。

3、NGINX工作在非阻塞的socket模式下，并使用了epoll 和 kqueue这样有效的方法。

4、NGINX可以非常好地处理百万级规模的并发请求。

5、阻塞操作可以毁掉NGINX的性能，我们必须不惜一切代价避免使用阻塞。

6、即使在当前官方的NGINX代码中，依然无法在全部场景中避免使用阻塞，NGINX1.7.11中实现的线程池机制解决了这个问题

二、问题

1、通常情况下，NGINX是一个事件处理器，即一个接收来自内核的所有连接事件的信息，然后向操作系统发出做什么指令的控制器。

2、所谓“阻塞操作”是指任何导致事件处理循环显著停止一段时间的操作

3、操作可以由于各种原因成为阻塞操作

三、线程池

1、对NGINX而言，线程池执行的就是配货服务的功能。它由一个任务队列和一组处理这个队列的线程组成。

2、当工作进程需要执行一个潜在的长操作时，工作进程不再自己执行这个操作，而是将任务放到线程池队列中，任何空闲的线程都可以从队列中获取并执行这个任务。

3、磁盘的读取速度不能比磁盘产生数据的速度快。

4、“从磁盘读取”这个操作通常是阻塞操作最常见的示例，但是实际上，NGINX中实现的线程池可用于处理任何不适合在主循环中执行的任务。

5、线程池中执行的两个基本操作是大多数操作系统中的read()系统调用和Linux中的sendfile()。