nginx为什么性能这么优越？

　　所谓没有对比就没有伤害！
　　在nginx横空出世之前，Apache服务器一直占据web服务器的垄断地位，所以就用对比的方式来解释nginx那么强！
　　两者性能差别的主要原因在于网络IO模型选择不同，apache使用了select，而nginx使用了epoll模型！
　　举个例子:一个万人村里面选村长，有两种方式:
　　①，让每个人在纸条上写下自己的名字，然后前村长去收集纸条(一个线程去遍历)，然后得到村长推荐候选人的名单(需要处理的连接)，这就相当于select模型，去轮询每一个连接，并对需要进行处理的连接进行处理！
　　②，每个人都可以毛遂自荐(每个连接都有可能活跃)，想要竞选的在旁边站成一排(事件触发，放入队列中)，然后就在这几个人中选择(几个待处理的任务)，相当于只要对少量的事件进行处理！
　　一个是从上万人中循环得到几个进行处理，一个是几个自己站出来直接处理，这种效率相差不是一般的大吧？
　　nginx是基于epoll模型开发的，而epoll是基于JAVA NIO的同步非阻塞开发，在高并发情况下能支持更多的连接！
　　nginx是事件驱动的，一个主进程跟多个工作进程组成的工作模式，主线程负责循环分配事件，多个工作线程负责事件的处理！
　　我们通常使用nginx做什么呢？
　　nginx作为高性能的http服务器和反向代理服务器，通常用做负载均衡组件，负责接受大量的连接然后基于一定的规则(轮询，权重等)分发连接给不同的应用服务器进行处理！
　　而且负载均衡配置十分简单，只需要在安装好nginx之后，通过修改配置文件nginx.conf，将不同的连接分发到不同的服务器上(通过配置server)，配置十分简单！
　　一般来说，企业中使用nginx作为负载均衡组件的场景还是很多的，同时为了避免单点故障带来的不稳定性，通常会使用keepalive搭建高可用的集群方案！
　　nginx搭建比较简单，大家自己可以多玩一玩！更多的技术分享，敬请关注…
　　看到下面回答中＂nginx是基于epoll模型开发的，而epoll是基于JAVA NIO的同步非阻塞开发＂， 忍不住想这回答还真是无畏啊，错的离谱，竟还有那么多点赞。应该说Epoll机制仅仅是nginx在Linux上实现事件驱动的一种技术而已，说nginx基于epoll开发那就错了，说nginx基于java nio开发就更不知所云了。
　　当我们说性能优越的时候，我们在说什么呢？首先让我们看看有哪些衡量性能的性能指标吧。
　　性能指标一般包括响应时间、吞吐量、并发用户数等。
　　响应时间指功能完成的时间，和客观环境、数据量级、主观感受等都有关系。客观环境中硬件包括服务器配置、客户端机器配置等，软件包括数据库部署方式、客户端使用的浏览器等，另外还有网络环境。
　　吞吐量是给定时间内系统可处理的事务/请求的数量等，例如网络传输的数据流量。这个指标对于互联网软件更为关键，目前我们尚未进行定量分析和测试。
　　并发用户数用来衡量系统的同步协调能力，我们更关注多个用户同时操作同一功能或数据时，对系统性能的影响。
　　总的来说，nginx的性能是指其低延迟、高吞吐、高并发能力。
　　下面我们就从架构设计的角度，来分析nginx是如何做到低延迟、高吞吐、高并发能力的。
　　Nginx采用一个Master管理进程，多个worker工作进程的设计方式。如下图所示，Master进程管理了完全相同的worker进程，一个cache manager进程和cache loader进程。
　　这种多进程的架构可以充分利用多核系统的并发处理能力。同时，多个worker进程间可以实现负载均衡，一个请求到来时更容易被分配到负载较轻的worker进程中处理。这将降低请求的延迟，也提高了网络处理的性能。
　　Nginx进程内部采用了非阻塞方式的事件驱动架构模式，这也是Nginx不同于传统Web服务器的地方。传统的Web服务器而言，采用的所谓事件驱动往往局限于TCP建立连接、关闭事件上，一个连接建立以后，在关闭之前的所有操作都不再是事件驱动，这时会退化成按序执行每个操作的批处理模式，这样每个请求在连接建立之后都将始终占用系统资源，直到关闭才会释放。
　　nginx的异步事件驱动实际上是请求的多阶段异步处理的过程。nginx实际把请求处理流程划分为了11个阶段，这样划分的原因是将请求的执行逻辑细分，各阶段按照处理时机定义了清晰的执行语义，开发者可以很容易分辨自己需要开发的模块应该定义在什么阶段。
　　nginx做为一个异步高效的事件驱动型web服务器，在linux平台中当系统支持epoll时nginx默认采用epoll 来高效的处理事件。Epoll实际上是 poll 的一种改进，它可以处理大批量的句柄。而 poll 又是select 的一种改进。在select 中对所打开的文件描述符个数有一定的限制，该限制由 FD_SETSIZE 设置（一般为 1024 或 2048）， 而且内核中的 select 的实现是采用轮询来处理描文件描述符集，因此效率低。当文件描述符集中的某个描述符处于可读、可写或异常状态时，select 采用内存拷贝方法通知用户空间。因此， 在select 模型中文件描述符个数受限且效率低的问题就很明显。为了解决select 对文件描述符个数的限制，采用了 poll 模型，但是 poll 依然不能解决 select 的效率问题。所以，最终epoll 模型重新对poll 模型进行改进 。
　　epoll 的优点如下所示：
　　处理大批量文件句柄：一个进程可以处理大批量的文件句柄，可处理文件描述符的个数远大于 2048；
　　高效率：内核实现中 epoll 是根据每个描述符上面的回调函数实现的，并且只有处于活动状态的套接字才会主动调用该回调函数，其他不活动的套接字并不会去调用，因此，epoll 不必扫描整个文件描述符集，只需要扫描处于活动状态的文件描述符。所有大大减低了效率。
　　加快内核与用户的消息传递：epoll 是通过内核与用户空间mmap 同一块内存实现内核与用户之间消息的传递。
　　内核微调：可以根据运行时所需内存动态调整内存大小。
　　Nginx的高性能有赖于其高效内存管理，下面我们看看其内存池设计。
　　Nginx 使用内存池对内存进行管理，把内存分配归结为大内存分配和小内存分配。若申请的内存大小比同页的内存池最大值 max 还大，则是大内存分配，否则为小内存分配。大块内存的分配请求不会直接在内存池上分配内存来满足请求，而是直接向系统申请一块内存（就像直接使用 malloc 分配内存一样），然后将这块内存挂到内存池头部的 large 字段下。小块内存分配，则是从已有的内存池数据区中分配出一部分内存。
　　这样设计的好处就是减少了内存碎片，提升了内存分配的效率。
　　总结一下，nginx优越的性能得益于其多进程、异步事件处理的架构，得益于其高效的内存管理。
　　本回答的内容参考了nginx官网上的内容，截图也来自于https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/
　　这个问题要从本质来看，NGINX本质上是不实现业务的，不是容器，而是一个看门+转发的服务器，这个定位决定了NGINX可以做得高效，如果不是NGINX，也会有另一个服务器来实现得这么高效。
　　1.NGINX采用了的构架极其简单，采用了多进程，每个进程的核心业务其实是单线程的，在执行上，代码逻辑可以极其简化。同时也可以把多核机器的性能发挥出来。
　　2.采用了EPOLL的这个异步IO模型，在面对大并发时，系统在处理网络事件上，占用的CPU极低，为高性能提供了可能。
　　3.在内存使用上，NGINX不像传统的写法，在池里面分配，然后再释放，而是为每个连接生成一个临时池，这个池上的申请小块内存不进锁，同时这个池上的内存也不释放，而是在完成请求后，这个池一次性释放。
　　01 基本原理
　　1.1 Nginx 的进程模型
　　Nginx 服务器，正常运行过程中：多进程：一个 Master 进程、多个 Worker 进程Master 进程：管理 Worker 进程对外接口：接收外部的操作（信号）对内转发：根据外部的操作的不同，通过信号管理 Worker监控：监控 worker 进程的运行状态，worker 进程异常终止后，自动重启 worker 进程Worker 进程：所有 Worker 进程都是平等的实际处理：网络请求，由 Worker 进程处理；Worker 进程数量：在 nginx.conf 中配置，一般设置为核心数，充分利用 CPU 资源，同时，避免进程数量过多，避免进程竞争 CPU 资源，增加上下文切换的损耗。
　　思考：请求是连接到 Nginx，Master 进程负责处理和转发？如何选定哪个 Worker 进程处理请求？请求的处理结果，是否还要经过 Master 进程？
　　HTTP 连接建立和请求处理过程：Nginx 启动时，Master 进程，加载配置文件Master 进程，初始化监听的 socketMaster 进程，fork 出多个 Worker 进程Worker 进程，竞争新的连接，获胜方通过三次握手，建立 Socket 连接，并处理请求
　　Nginx 高性能、高并发：Nginx 采用：多进程 + 异步非阻塞方式（IO 多路复用 epoll）请求的完整过程：建立连接读取请求：解析请求处理请求响应请求请求的完整过程，对应到底层，就是：读写 socket 事件
　　1.2 Nginx 的事件处理模型
　　request：Nginx 中 http 请求。
　　基本的 HTTP Web Server 工作模式：接收请求：逐行读取请求行和请求头，判断段有请求体后，读取请求体处理请求返回响应：根据处理结果，生成相应的 HTTP 请求（响应行、响应头、响应体）
　　Nginx 也是这个套路，整体流程一致。
　　1.3 模块化体系结构
　　nginx的模块根据其功能基本上可以分为以下几种类型：event module: 搭建了独立于操作系统的事件处理机制的框架，及提供了各具体事件的处理。包括ngx_events_module， ngx_event_core_module和ngx_epoll_module等。nginx具体使用何种事件处理模块，这依赖于具体的操作系统和编译选项。phase handler: 此类型的模块也被直接称为handler模块。主要负责处理客户端请求并产生待响应内容，比如ngx_http_static_module模块，负责客户端的静态页面请求处理并将对应的磁盘文件准备为响应内容输出。output filter: 也称为filter模块，主要是负责对输出的内容进行处理，可以对输出进行修改。例如，可以实现对输出的所有html页面增加预定义的footbar一类的工作，或者对输出的图片的URL进行替换之类的工作。upstream: upstream模块实现反向代理的功能，将真正的请求转发到后端服务器上，并从后端服务器上读取响应，发回客户端。upstream模块是一种特殊的handler，只不过响应内容不是真正由自己产生的，而是从后端服务器上读取的。load-balancer: 负载均衡模块，实现特定的算法，在众多的后端服务器中，选择一个服务器出来作为某个请求的转发服务器。
　　02 常见问题剖析
　　2.1 Nginx vs. Apache
　　nginx vs. apache：
　　网络 IO 模型：nginx：IO 多路复用，epoll(freebsd 上是 kqueue )高性能高并发占用系统资源少apache：阻塞 + 多进程/多线程更稳定，bug 少模块更丰富
　　场景：
　　处理多个请求时，可以采用：IO 多路复用 或者 阻塞 IO +多线程IO 多路服用：一个 线程，跟踪多个 socket 状态，哪个就绪，就读写哪个；阻塞 IO + 多线程：每一个请求，新建一个服务线程
　　思考：IO 多路复用 和 多线程 的适用场景？IO 多路复用：单个连接的请求处理速度没有优势，适合 IO 密集型 场景，事件驱动大并发量：只使用一个线程，处理大量的并发请求，降低上下文环境切换损耗，也不需要考虑并发问题，相对可以处理更多的请求；消耗更少的系统资源（不需要线程调度开销）适用于长连接的情况（多线程模式长连接容易造成线程过多，造成频繁调度）阻塞IO + 多线程：实现简单，可以不依赖系统调用，适合 CPU 密集型 场景每个线程，都需要时间和空间；线程数量增长时，线程调度开销指数增长
　　2.2 Nginx 最大连接数
　　基础背景：Nginx 是多进程模型，Worker 进程用于处理请求；单个进程的连接数（文件描述符 fd），有上限（nofile）：ulimit -nNginx 上配置单个 worker 进程的最大连接数：worker_connections 上限为 nofileNginx 上配置 worker 进程的数量：worker_processes
　　因此，Nginx 的最大连接数：Nginx 的最大连接数：Worker 进程数量 x 单个 Worker 进程的最大连接数上面是 Nginx 作为通用服务器时，最大的连接数Nginx 作为反向代理服务器时，能够服务的最大连接数：（Worker 进程数量 x 单个 Worker 进程的最大连接数）/ 2。Nginx 反向代理时，会建立 Client 的连接和后端 Web Server 的连接，占用 2 个连接
　　思考：每打开一个 socket 占用一个 fd为什么，一个进程能够打开的 fd 数量有限制？
　　03 附录
　　3.1 HTTP 请求和响应HTTP 请求：请求行：method、uri、http version请求头请求体HTTP 响应：响应行：http version、status code响应头响应体
　　3.2 IO 模型
　　场景：
　　处理多个请求时，可以采用：IO 多路复用 或者 阻塞 IO +多线程IO 多路服用：一个 线程，跟踪多个 socket 状态，哪个就绪，就读写哪个；阻塞 IO + 多线程：每一个请求，新建一个服务线程
　　思考：IO 多路复用 和 多线程 的适用场景？IO 多路复用：单个连接的请求处理速度没有优势大并发量：只使用一个线程，处理大量的并发请求，降低上下文环境切换损耗，也不需要考虑并发问题，相对可以处理更多的请求；消耗更少的系统资源（不需要线程调度开销）适用于长连接的情况（多线程模式长连接容易造成线程过多，造成频繁调度）
　　阻塞IO + 多线程：实现简单，可以不依赖系统调用。每个线程，都需要时间和空间；线程数量增长时，线程调度开销指数增长
　　select/poll 和 epoll 比较select/poll 系统调用：
　　// select 系统调用int select(int maxfdp,fd_set *readfds,fd_set *writefds,fd_set *errorfds,struct timeval *timeout); // poll 系统调用int poll(struct pollfd fds[], nfds_t nfds, int timeout)；select：查询 fd_set 中，是否有就绪的 fd，可以设定一个超时时间，当有 fd (File descripter) 就绪或超时返回；fd_set 是一个位集合，大小是在编译内核时的常量，默认大小为 1024特点：连接数限制，fd_set 可表示的 fd 数量太小了；线性扫描：判断 fd 是否就绪，需要遍历一边 fd_set；数据复制：用户空间和内核空间，复制连接就绪状态信息
　　poll：解决了连接数限制：poll 中将 select 中的 fd_set 替换成了一个 pollfd 数组解决 fd 数量过小的问题数据复制：用户空间和内核空间，复制连接就绪状态信息
　　epoll： event 事件驱动事件机制：避免线性扫描为每个 fd，注册一个监听事件fd 变更为就绪时，将 fd 添加到就绪链表fd 数量：无限制（OS 级别的限制，单个进程能打开多少个 fd）
　　select，poll，epoll：I/O多路复用的机制；I/O多路复用就通过一种机制，可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。监视多个文件描述符但select，poll，epoll本质上都是同步I/O：用户进程负责读写（从内核空间拷贝到用户空间），读写过程中，用户进程是阻塞的；异步 IO，无需用户进程负责读写，异步IO，会负责从内核空间拷贝到用户空间；
　　3.3 Nginx 的并发处理能力
　　关于 Nginx 的并发处理能力：并发连接数，一般优化后，峰值能保持在 1~3w 左右。（内存和 CPU 核心数不同，会有进一步优化空间）
　　我做过深入测试，windows下面最强者是iis，linux下最强者是nginx，nginx在win下性能很差，还不如apache
　　部署架构上支持负载均衡
　　设计上采用进程池概念
　　网络模块在linux上支持非阻塞epoll模型