百万并发下的Nginx优化，看这一篇就够了！

本文做者主要分享在 Nginx 性能方面的实践经验，但愿能给你们带来一些系统化思考，帮助你们更有效地去作 Nginx。

优化方法论

我重点分享以下两个问题：

• 保持并发链接数，怎么样作到内存有效使用。
• 在高并发的同时保持高吞吐量的重要要点。

实现层面主要是三方面优化，主要聚焦在应用、框架、内核。

硬件限制可能有的同窗也都听过，把网卡调到万兆、10G 或者 40G 是最好的，磁盘会根据成本的预算和应用场景来选择固态硬盘或者机械式硬盘，关注 IOPS 或者 BPS。

CPU 是咱们重点看的一个指标。实际上它是把操做系统的切换代价换到了进程内部，因此它从一个链接器到另一个链接器的切换成本很是低，它性能很好，协程 Openresty 实际上是同样的。

资源的高效使用，下降内存是对咱们增大并发性有帮助的，减小 RTT、提高容量。

Reuseport 都是围绕着提高 CPU 的机核性。还有 Fast Socket，由于我以前在阿里云的时候还作过阿里云的网络，因此它可以带来很大的性能提高，可是问题也很明显，就是把内核自己的那套东西绕过去了。

请求的“一辈子”

下面我首先会去聊一下怎么看“请求”，了解完这个之后再去看怎么优化就会很清楚了。

说这个以前必须再说一下 Nginx 的模块结构，像 Nginx 之外，任何一个外部框架都有个特色，若是想造成整个生态必须容许第三方的代码接进来，构成一个序列，让一个请求挨个被模块共同处理。

那 Nginx 也同样，这些模块会串成一个序列，一个请求会被挨个的处理。在核心模块里有两个，分别是 Steam 和 NGX。

请求到来

一个链接开始刚刚创建请求到来的时候会发生什么事情？先是操做系统内核中有一个队列，等着咱们的进程去系统调用，这时候由于有不少工做进程，谁会去调用呢，这有个负载均衡策略。

如今有一个事件模块，调用了 Epoll Wait 这样的接口，Accept 创建好一个新链接，这时会分配到链接内存池，这个内存池不一样于全部的内存池，它在链接刚建立的时候会分配，何时会释放呢？

只有这个链接关闭的时候才会去释放。接下来就到了 NGX 模块，这时候会加一个 60 秒的定时器。

就是在创建好链接之后 60 秒以内没有接到客户端发来的请求就自动关闭，若是 60 秒过来以后会去分配内存，读缓冲区。什么意思呢？

如今操做系统内核已经收到这个请求了，可是个人应用程序处理不了，由于没有给它读到用户态的内存里去，因此这时候要分配内存。

从链接内存池这里分配，那要分配多大呢？会扩到 1K。

收到请求

当收到请求之后，接收 Url 和 Header，分配请求内存池，这时候 Request Pool Size 是 4K，你们发现是否是和刚才的有一个 8 倍的差距，这是由于利用态的内存是很是消耗资源的。

再看为何会消耗资源，首先会用状态机解去形容，所谓状态机解就是把它当作一个序列，一个支节一个支节往下解，若是发现换行了那就是请求行解完了。

但若是这个请求特别长的时候，就会去再分配更大的，刚刚 1K 不够用了，为何是 4 乘 8K 呢？

就是由于当 1K 不够了不会一次性分配 32K，而是一次性分配 8K。若是 8K 之后尚未解析到刚才的标识符，就会分配第二个 8K。

我以前收到的全部东西都不会释放，只是放一个指针，指到 Url 或者指到那个协议，标识它有多长就能够了。

接下来解决 Header，这个流程如出一辙的没有什么区别，这时候还会有一个不够用的状况，当我接收完全部的 Header 之后，会把刚刚的定时器给移除，移除后接下来作 11 个阶段的处理。

也就是说刚刚全部的外部服务器都是经过不少的模块串成在一块儿处理一个请求的。

像刚刚两页 PPT 都在说蓝色的区域，那么请求接下来 11 个阶段是什么意思呢？这个黄色的、绿色的，还有右边这个都是在 11 阶段之中。

这 11 个阶段你们也不用记，很是简单，只要掌握三个关键词就能够。

刚刚读完 Header 要作处理，因此这时候第一阶段是 Post-Read。接下来会有 Rewrite，还有 Access 和 Preaccess。

先看左手边，当咱们下载完 Nginx 源码编之后会有一个 Referer，全部的第三方数据都会在这里呈现有序排列。

这些序列中并非简单的一个请求给它再给它，先是分为 11 个阶段，每一个阶段以内你们是有序一个个日后来的，但在 11 个阶段中是按阶段来的。

我把它分解一下，第一个 Referer 这阶段有不少模块，后面这是有序的。

这个图比刚刚的图多了两个关键点：

• 第一到了某一个模块能够决定继续向这序列后的模块执行，也能够说直接跳到下个阶段，但不能说跳多个阶段。
• 第二是生成了向客户端反映的响应，这时候要对响应作些处理，这里是有序的，先作缩略图再作压缩，因此它是有严格顺序的。

请求的反向代理

请求的反向代理，反向代理这块是咱们 Nginx 的重点应用场景，由于 Nginx 会考虑一种场景，客户端走的是公网，因此网络环境很是差，网速很是慢。

若是简单用一个缓冲区从客户端收一点发给上游服务器，那上游服务器的压力会很大，由于上游服务器每每它的效率高，因此都是一个请求被处理完以前不会再处理下一个请求。

Nginx 考虑到这个场景，它会先把整个请求所有收完之后，再向上游服务器创建链接，因此是默认第一个配置，就是 Proxy Request Buffering On，存放包体至文件，默认 Size 是 8K。

那创建上游链接的时候会放 Time Out，60 秒，添加超时定时器，也是 60 秒的。

发出请求（读取文体包件），若是向上游传一个很大的包体的话，那 Sizk 就是 8K。

默认 Proxy Limit Rate 是打开的，咱们会先把这个请求所有缓存到端来，因此这时候有个 8×8K，若是关掉的话，也就是从上游发一点就往下游发一点。

知道这个流程之后，再说这里的话你们能够感受到这里的内存消耗仍是蛮大的。

返回响应

返回响应，这里面其实内容蛮多的，我给你们简化一下，仍是刚刚官方的那个包，这也是有顺序的从下往上看，若是有大量第三方模块进来的话，数量会很是高。

第一个关键点是上面的 Header Filter，上面是 Write Filter，下面是 Postpone Filter，这里还有一个 Copy Filter，它又分为两类，一类是须要处理，一类是不须要处理的。

OpenResty 的指令，第一代码是在哪里执行的，第二个是 SDK。

应用层优化

协议

作应用层的优化咱们会先看协议层有没有什么优化，好比说编码方式、Header 每次都去传用 Nginx 的架构，以致于浪费了不少的流量。咱们能够改善 Http2，有不少这样的协议会大幅度提高它的性能。

固然若是你改善 Http2 了，会带来其余的问题，好比说 Http2 必须走这条路线。

这条路线又是一个很大的话题，它涉及到安全性和性能，是互相冲突的东西。

压缩

咱们但愿“商”越大越好，压缩这里会有一个重点提出来的动态和静态，好比说咱们用了拷贝，好比说能够从磁盘中直接由内核来发网卡，但一旦作压缩的话就不得不先把这个文件读到 Nginx，交给后面的极内核去作一下处理。

Keepalive 长链接也是同样的，它也涉及到不少东西，简单来看这也就是附用链接。

由于链接有一个慢启动的过程，一开始它的窗口是比较小，一次可能只传送很小的 1K 的，但后面可能会传送几十K，因此你每次新建链接它都会从新开始，这是很慢的。

固然这里还涉及到一个问题，由于 Nginx 内核它默认打开了一个链接空闲的时候，长链接产生的做用也会降低。

提升内存使用率

刚刚在说具体的请求处理过程当中已经比较详细的把这问题说清楚了，这里再总结一下，在我看来有一个角度，Nginx 对下游只是必需要有的这些模块，Client Header、Buffer Size：1K，上游网络 Http 包头和包体。

CPU 经过缓存去取储存上东西的时候，它是一批一批取的，每一批目前是 64 字节，因此默认的是 8K。

若是你配了 32 它会给你上升到 64；若是你配了 65 会升到 128，由于它是一个一个序列化重组的。

因此了解这个东西之后本身再配的时候就不会再犯问题。红黑树这里用的很是多，由于是和具体的模块相关。

限速

大部分咱们在作分公司流控的时候，主要在限什么呢？主要限 Nginx 向客户端发送响应的速度。

这东西很是好用，由于能够和 Nginx 定量链接在一块儿。这不是限上游发请求的速度，而是在限从上游接响应的速度。

Worker 间负载均衡

当时我在用 0.6 版本的时候那时候都在默认用这个，这个“锁”它是在用进程间同步方式去实现负载均衡，这个负载均衡怎么实现呢？

就是保证全部的 Worker 进程，同一时刻只有一个 Worker 进程在处理距离，这里就会有好几个问题，绿色的框表明它的吞吐量，吞吐量不高，因此会致使第二个问题 Requests，也是比较长的，这个方差就很是的大。

若是把这个“锁”关掉之后，能够看到吞吐量是上升的，方差也在降低，可是它的时间在上升，为何会出现这样的状况？

由于会致使一个 Worker 可能会很是忙，它的链接数已经很是高了，可是还有其余的 Worker 进程是很闲的。

若是用了 Requests，它会在内核层面上作负载均衡。这是一个专用场景，若是在复杂应用场景下开 Requests 和不开是能看到明显变化的。

超时

这里我刚刚说了好多，它是一个红黑树在实现的。惟一要说的也就是这里，Nginx 如今作四层的反向代理也很成熟了。

像 UTP 协议是能够作反向代理的，但要把有问题的链接迅速踢掉的话，要遵循这个原则，一个请求对一个响应。

缓存

只要想提高性能必需要在缓存上下工夫。好比说我之前在阿里云作云盘，云盘缓存的时候就会有个概念叫空间维度缓存，在读一块内容的时候可能会把这内容周边的其余内容也读到缓存中。

你们若是熟悉优化的话也会知道有分支预测先把代码读到那空间中，这个用的比较少，基于时间维度用的比较多了。

减小磁盘 IO

其实要作的事也很是多，优化读取，Sendfile 零拷贝、内存盘、SSD 盘。减小写入，AIO，磁盘是远大于内存的，当它把你内存消化完的时候还会退化成一个调用。

像 Thread Pool 只用读文件，当退化成这种模式变多线程能够防止它的主进程被阻塞住，这时候官方的博客上说是有 9 倍的性能提高。

系统优化

提高容量配置

咱们建链接的时候也有，还有些向客户端发起链接的时候会有一个端口范围，还有一些像对于网卡设备的。

CPU缓存的亲和性

CPU缓存的亲和性，这看状况了，如今用 L3 缓存差很少也 20 兆的规模，CPU 缓存的亲和性是一个很是大的话题，这里就再也不展开了。

NUMA 架构的 CPU 亲和性

把内存分红两部分，一部分是靠近这个核，一部分靠近那个核，若是访问本核的话就会很快，靠近另外一边大概会耗费三倍的损耗。对于多核 CPU 的使用对性能提高很大的话就不要在乎这个事情。

网络快速容错

由于 TCP 的链接最麻烦的是在创建链接和关闭链接，这里有不少参数都是在调，每一个地方重发，多长时间重发，重发多少次。

这里给你们展现的是快启动，有好几个概念在里面，第一个概念在快速启动的时候是以两倍的速度。

由于网的带宽是有限的，当你超出网络带宽的时候其中的网络设备是会被丢包的，也就是控制量在往降低，那再恢复就会比较慢。

TCP 协议优化

TCP 协议优化，原本可能差很少要四个来回才能达到每次的传输在网络中有几十 K，那么提早配好的话用增大初始窗口让它一开始就达到最大流量。

提升资源效率

提升资源效率，这一页东西就挺多了，好比说先从 CPU 看，TCP Defer Accept，若是有这个的话，实际上会牺牲一些即时性，但带来的好处是第一次创建好链接没有内容过来的时候是不会激活 Nginx 作切换的。

内存在说的时候是系统态的内存，在内存大和小的时候操做系统作了一次优化，在压力模式和非压力模式下为每个链接分配的系统内存能够动态调整。

网络设备的核心只解决一个问题，变单个处理为批量处理，批量处理后吞吐量必定是会上升的。

由于消耗的资源变少了，切换次数变少了，它们的逻辑是同样的，就这些逻辑和我一直在说的逻辑都是同一个逻辑，只是应用在不一样层面会产生不一样的效果。

端口复用，像 Reals 是很好用的，由于它能够把端口用在上游服务链接的层面上，没有带来隐患。

提高多 CPU 使用效率

提高多 CPU 使用效率，上面不少东西都说到了，重点就两个，一是 CPU 绑定，绑定之后缓存更有效。多队列网卡，从硬件层面上已经可以作到了。

BDP，带宽确定是知道的，带宽和时延就决定了带宽时延积，那吞吐量等于窗口或者时延。

内存分配速度也是咱们关注的重点，当并发量很大的时候内存的分配是比较糟糕的，你们能够看到有不少它的竞品。

PCRE 的优化，这用最新的版本就好。

做者：陶辉

介绍：曾在华为、腾讯公司作底层数据相关的工做，写过一本书叫《深刻理解 Nginx：模块开发与架构解析》，目前在杭州智链达做为联合创始人担任技术总监一职，目前专一于使用互联网技术助力建筑行业实现转型升级。