共计 3476 个字符，预计需要花费 9 分钟才能阅读完成。
Nginx 才短短几年，就拿下了 Web 服务器大壁江山，家喻户晓，Nginx 在解决大并发动态申请方面，效率显著高于 Httpd，甚至能轻松解决 C10K 问题。
在高并发连贯的状况下，Nginx 是 Apache 服务器不错的替代品。Nginx 同时也能够作为 7 层负载平衡服务器来应用。依据我的测试后果，Nginx + PHP(FastCGI) 能够接受 3 万以上的并发连接数，相当于等同环境下 Apache 的 10 倍。
一般来说，4GB 内存的服务器 +Apache（prefork 模式）个别只能解决 3000 个并发连贯，因为它们将占用 3GB 以上的内存，还得为零碎预留 1GB 的内存。我已经就有两台 Apache 服务器，因为在配置文件中设置的 MaxClients 为 4000，当 Apache 并发连接数达到 3800 时，导致服务器内存和 Swap 空间用满而解体。
而这台 Nginx + PHP(FastCGI) 服务器在 3 万并发连贯下，开启的 10 个 Nginx 过程耗费 150M 内存（15M*10=150M），开启的 64 个 php-cgi 过程耗费 1280M 内存（20M*64=1280M），加上零碎本身耗费的内存，总共耗费不到 2GB 内存。如果服务器内存较小，齐全能够只开启 25 个 php-cgi 过程，这样 php-cgi 耗费的总内存数才 500M。
在 3 万并发连贯下，拜访 Nginx+ PHP(FastCGI) 服务器的 PHP 程序，依然速度飞快。
为什么 Nginx 在解决高并发方面要优于 httpd，咱们先从两种 web 服务器的工作原理以及工作模式说起。
一、Apache 三种工作模式
咱们都晓得 Apache 有三种工作模块，别离为：prefork、worker、event。
- prefork： 多过程，每个申请用一个过程响应，这个过程会用到 select 机制来告诉。
- worker： 多线程，一个过程能够生成多个线程，每个线程响应一个申请，但告诉机制还是 select 不过能够承受更多的申请。
- event： 基于异步 I / O 模型，一个过程或线程，每个过程或线程响应多个用户申请，它是基于事件驱动（也就是 epoll 机制）实现的。
1、prefork 的工作原理
如果不必“–with-mpm”显式指定某种 MPM，prefork 就是 Unix 平台上缺省的 MPM。它所采纳的预派生子过程形式也是 Apache1.3 中采纳的模式。
prefork 自身并没有应用到线程，2.0 版应用它是为了与 1.3 版放弃兼容性；另一方面，prefork 用独自的子过程来解决不同的申请，过程之间是彼此独立的, 这也使其成为最稳固的 MPM 之一。
2、worker 的工作原理
绝对于 prefork，worker 是 2.0 版中全新的反对多线程和多过程混合模型的 MPM。因为应用线程来解决，所以能够解决绝对海量的申请，而系统资源的开销要小于基于过程的服务器。
然而，worker 也应用了多过程, 每个过程又生成多个线程，以取得基于过程服务器的稳定性，这种 MPM 的工作方 式将是 Apache2.0 的发展趋势。
3、event 基于事件机制的个性
一个过程响应多个用户申请，利用 callback 机制，让套接字复用，申请过去后过程并不解决申请，而是间接交由其余机制来解决，通过 epoll 机制来告诉申请是否实现；在这个过程中，过程自身始终处于闲暇状态，能够始终接管用户申请。能够实现一个过程程响应多个用户申请。反对持海量并发连接数，耗费更少的资源。
二、如何进步 Web 服务器的并发连贯解决能力
有几个根本条件：
1、基于线程，即一个过程生成多个线程，每个线程响应用户的每个申请。
2、基于事件的模型，一个过程解决多个申请，并且通过 epoll 机制来告诉用户申请实现。
3、基于磁盘的 AIO（异步 I /O）
4、反对 mmap 内存映射，mmap 传统的 web 服务器，进行页面输出时，都是将磁盘的页面先输出到内核缓存中，再由内核缓存中复制一份到 web 服务器上，mmap 机制就是让内核缓存与磁盘进行映射，web 服务器，间接复制页面内容即可。不须要先把磁盘的上的页面先输出到内核缓存去。
刚好，Nginx 反对以上所有个性。所以 Nginx 官网上说，Nginx 反对 50000 并发，是有根据的。
三、Nginx 优异之处
传统上基于过程或线程模型架构的 Web 服务通过每过程或每线程解决并发连贯申请，这势必会在网络和 I / O 操作时产生阻塞，其另一个必然结果则是对内存或 CPU 的利用率低下。
生成一个新的过程 / 线程须要当时备好其运行时环境，这包含为其调配堆内存和栈内存，以及为其创立新的执行上下文等。这些操作都须要占用 CPU，而且过多的过程 / 线程还会带来线程抖动或频繁的上下文切换，零碎性能也会由此进一步降落。
另一种高性能 web 服务器 /Web 服务器反向代理：Nginx，Nginx 的次要着眼点就是其高性能以及对物理计算资源的高密度利用，因而其采纳了不同的架构模型。受启发于多种操作系统设计中基于“事件”的高级解决机制，Nginx 采纳了模块化、事件驱动、异步、单线程及非阻塞的架构，并大量采纳了多路复用及事件告诉机制。
在 Nginx 中，连贯申请由为数不多的几个仅蕴含一个线程的过程 Worker 以高效的回环 (run-loop) 机制进行解决，而每个 Worker 能够并行处理数千个的并发连贯及申请。
四、Nginx 工作原理
Nginx 会按需同时运行多个过程：一个主过程 (master) 和几个工作过程 (worker)，配置了缓存时还会有缓存加载器过程(cache loader) 和缓存管理器过程 (cache manager) 等。所有过程均是仅含有一个线程，并次要通过“共享内存”的机制实现过程间通信。主过程以 root 用户身份运行，而 worker、cache loader 和 cache manager 均应以非特权用户身份运行。
在高连贯并发的状况下，Nginx 是 Apache 服务器不错的替代品。
Nginx 装置十分的简略 , 配置文件十分简洁（还可能反对 perl 语法）,Bugs 非常少的服务器: Nginx 启动特地容易, 并且简直能够做到 7 *24 不间断运行，即便运行数个月也不须要重新启动. 你还可能 不间断服务的状况下进行软件版本的降级。
五、Nginx 的诞生次要解决 C10K 问题
最初咱们从各自应用的多路复用 IO 模型来剖析：
1、select 模型：（apache 应用，因为受模块等限度，用的不多）；
单个过程可能 监督的文件描述符的数量存在最大限度；
select()所保护的 存储大量文件描述符的数据结构，随着文件描述符数量的增长，其在用户态和内核的地址空间的复制所引发的开销也会线性增长；
因为网络响应工夫的提早使得大量 TCP 连贯处于非沉闷状态，但调用 select()还是会对 所有的 socket 进行一次线性扫描，会造成肯定的开销；
2、poll：poll 是 unix 沿用 select 本人从新实现了一遍，惟一解决的问题是 poll 没有最大文件描述符数量的限度；
3、epoll 模型：（Nginx 应用）
epoll 带来了两个劣势，大幅度晋升了性能：
1）基于事件的就绪告诉形式，select/poll 形式，过程只有在调用肯定的办法后，内核才会对所有监督的文件描述符进行扫描，而 epoll 事件通过 epoll_ctl()注册一个文件描述符，一旦某个文件描述符就绪时，内核会采纳相似 call back 的回调机制，迅速激活这个文件描述符，epoll_wait()便会失去告诉
2）调用一次 epoll_wait()取得就绪文件描述符时，返回的并不是理论的描述符，而是一个代表就绪描述符数量的值，拿到这些值去 epoll 指定的一个数组中顺次获得相应数量的文件描述符即可，这里应用内存映射（mmap）技术，防止了复制大量文件描述符带来的开销
3）当然 epoll 也有肯定的局限性，epoll 只有 Linux2.6 才有实现，而其余平台都没有，这和 apache 这种优良的跨平台服务器，显然是有些南辕北辙了。
4）简略来说 epoll 是 select 的升级版，单过程治理的文件描述符没有最大限度。但 epoll 只有 linux 平台可应用。作为跨平台的 Apache 没有应用
起源：http://codebay.cn/post/8557.html
近期热文举荐：
1.600+ 道 Java 面试题及答案整顿(2021 最新版)
2. 终于靠开源我的项目弄到 IntelliJ IDEA 激活码了，真香！
3. 阿里 Mock 工具正式开源，干掉市面上所有 Mock 工具！
4.Spring Cloud 2020.0.0 正式公布，全新颠覆性版本！
5.《Java 开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞 + 转发哦！
