运维高手二：nginx高性能优化配置实战

本文我们聊一下关于Nginx配置优化的内容，相信对于Nginx你一定并不陌生，它是一款轻量级的开源Web服务及代理程序。在Nginx出现之前市场上主流两款Web服务，一款是Windows系统上的IIS，另外一款是Linux系统上的Apache。而在Nginx诞生后，因其轻量化、支持高并发等特性，逐渐蚕食了这两款Web服务的市场份额。目前国内大量企业早已广泛的使用 Nginx。既然 Nginx 使用这么广泛，那么我们在运维工作中如何对其进行优化和配置便成了重中之重。

你在阅读本文之前，我们需要提前掌握一些基础知识，包括：

熟悉Linux 的基础操作；
了解 Nginx 安装和基础配置；
对 HTTP 请求过程有一定了解。

Nginx 的优化主要分为两部分，一部分是基础配置优化，另外一部分是缓存配置优化。

基础配置优化主要包括：

CPU亲和性优化；
Nginx 模型优化；
Nginx 传输方式优化；
Nginx 文件压缩优化。

缓存配置优化主要包括：

浏览器缓存优化
代理缓存优化
HTTPS SSL 缓存优化
KV 服务缓存优化

基础配置优化

CPU 亲和性

所谓的 CPU 亲和性是做什么的呢？现在的CPU通常是多核的，并可以通过超线程来虚拟更多核数，那亲和力就是为多核 CPU 需做到让 Nginx 服务充分的配合使用，从而提高性能。 Nginx运行时会启用 1 个 master 进程及多个 worker 进程，worker 进程负责处理请求，如果 worker 进程在多核 CPU中发生频繁的调度就会损耗性能。在这种情况下，我们希望减少这种频繁调度，让每一个 Nginx 的worker 线程都能够固定到具体的 CPU核心上，所以就需要配置 Nginx 的 CPU 亲和性来解决这个问题。

由于 Nginx CPU亲和性配置本身有多套配置方案，这里推荐你直接将配置项设置成auto（worker_cpu_affinity），即采用了 Nginx 推荐的 CPU 绑核策略方式。另外的一个方式是手动绑定，将 worker 线程数量与 CPU 核心数一一绑定方式设置。我们设置成auto Nginx 会自动识别并按照推荐策略来分配worker 线程和 CPU。

CPU

如图所示，我们看到 CPU 的核心有 8 个，即CPU0~CPU7，如果我们设置成 auto 后，那么Nginx会将 8 个 worker 线程一对一地按照推荐策略绑定到 CPU 核心上，这样避免 CPU 频繁对 worker 线程进行调度，从而降低 CPU 损耗。

IO 流事件模型

我们经常可以在 Nginx 下面看到的 events 配置模块中默认设置了 use epoll，表示 Nginx 使用 epoll 这个 IO 流事件模型，那为什么Nginx 会选择使用 epoll 呢？这是因为 epoll有以下这些得天独厚的优势。

首先，Linux 系统下一切皆文件，比如我们打开一个设备，它便会产生一个文件描述符。在产生一个进程时，这个进程便需要一个进程描述符，这个进程描述符也是一个文件。所以在 Nginx 处理请求的时候，每一个请求都会产生处理请求的描述符。

其次，在 Nginx 处理大规模请求的时候，为了提高并发效率需要采用异步非阻塞模型，这又和 epoll有什么关系呢？epoll 本身是以异步非阻塞模型来处理请求流中的事件流。

这里还需要注意一点，并不是所有的 Linux 操作系统都可以使用epoll，它是在 kernel 2.6 版本以后提出的，早期内核使用的 select\poll 模型，select 模型比 epoll 模型性能要低很多，有经验的运维同学一定深有体会。

通过上面的背景铺垫，我们再来详细介绍下epoll 相比于 select 模型具备的优势:

epoll 处理事件流模型是线程安全的；
epoll 跟 select 模型相比调用 fd 文件描述符时使用了 mmap 共享用户和内核的部分空间，提高了效率；
epoll 是基于事件驱动的，相比 select 需要扫描整个文件描述符的相关状态，epoll 基于事件驱动避免频繁扫描文件描述符，可以直接调用callback 回调函数，效率更高；
取消了select模型里面单个进程能够监视的文件描述符的数量存在的最大限制（1024），如果你有使用过早期的Apache版本的，它使用的select模型，当请求超过1000以后就会出现延迟或者请求错误，而改用 Nginx 的话性能会得到明显的改善。

另外补充下，在 events{} 配置中还涉及一个优化的地方就是 worker_connections，这个也是在events 里面来进行设置的，通过上面的学习我们知道了 worker 线程作用，那每一个 work线程所支持的连接是有限的，这里会默认设置成 1024，而我们在处理高并发的场景时，单个 worker 线程设置成 1024 的话往往偏低，这里建议你将worker_connections 调大一些，你可以参考实际业务所需 Nginx 处理最大峰值来调大这个设置值。

零拷贝

第三个基础配置优化是零拷贝，所谓零拷贝的配置是在 Nginx 中的 HTTP 配置模块中添加一个sendfile on 配置项，它便是一个零拷贝，所谓零拷贝并不代表不拷贝了，而是说它做到了文件的内核态到用户态的零拷贝。

kenal

如图所示，我们先来看下没有零拷贝时文件传输是什么样子的？首先 Nginx 在处理文件时，会将文件传入操作系统内核态的 Buffer Cache，然后传递到操作系统上层的用户态，经用户态的 Buffer
Cache 再传回内核态中，最后通过 Socket 将文件转发出去。

这个时候你会发现一个问题，对于静态文件并不需要流转到用户态中，直接通过内核态效率更高，所以这时我们就需要在 Nginx 中开启 sendfile on，这样静态文件就可以通过红色的路径在内核态中完成转发，而不用再去绕道用户态，提高了效率。

文件压缩

我们希望做到 Nginx 服务端往客户端发送的数据越小，占用的延迟越低用户体验便会越好。所以往往在代理或 Nginx 中会设置文件压缩，我们主要通过gzip 方式进行设置，主要的设置项如下：

gzip on 负责打开后端的压缩功能；
gzip_buffer 16 8k 表示设置 Nginx 在处理文件压缩时的内存空间；
gzip_comp_level 6 表示 Nginx 在处理压缩时的压缩等级，通常等级越高它的压缩比就越大,但并不是说压缩比越大越好，还是需要根据实际情况来选择合适的压缩比，压缩比太大影响性能，压缩比太小起不到应有的效果，一般来说推荐你设置成 6 就比较合适；
gzip_http_version 1.1 表示只对 HTTP 1.1 版本的协议进行压缩；
gzip_proxied any 代表 Nginx 作为反向代理时依据后端服务器时返回信息设置一些 gzip 压缩策略；
gzip_vary on 表示是否发送Vary：Accept_Encoding 响应头字段，实现通知接收方服务端作了gzip 压缩；
application/vnd.ms-fontobject image/x-icon; gip 压缩类型；
gzip_disable “msie6”; 关闭 IE6 的压缩。

最后这两项表示设置 zip 的压缩类型及是否关闭客户端使用 IE6 浏览器请求过来的压缩，以上就是对文件压缩的典型配置，你可以根据具体情况做一些细节上的调整。

缓存配置优化

缓存优化

我们先讲解缓存优化配置，基于缓存元素存放的位置，再对我们所需要讲的缓存作一个分类。

如果缓存的元素在客户端的，那么主要有浏览器缓存和 HTTPS 缓存，你可别认为缓存文件是在客户端，这两部分缓存效果都可以 Nginx 这种代理来进行设置并作主要优化。

另外一个种类代理端的缓存（也就是缓存文件存放在代理服务的节点中），那Nginx 作为反向代理服务的时候，可以支持代理缓存设置。

最后一个种类是将缓存文件放入后台服务（通过后台服务中程序逻辑来实现）,例如我们可以将一部分数据通过此方式缓存，比如将用户最长查看的数据（网站中登录状态、连接数等）缓存到Memcache、Redis 中，避免直接请求关系型数据库或其他服务，因为效用效率更高所以可以降低后端的延迟，也减少请求对数据库的依赖度，从而整个网站的性能也会有很大的提升。

只考虑缓存最优的话，我有三点经验可以分享给你：

缓存越靠前越好，通常情况下整个网站的元素内容越靠前越好，也就是说能放在客户端的就放在客户端，而不要放到后端去频繁请求。
缓存的数据越多越好，也就是能在本层级缓存的数据越多，就越可以减少对后端的请求。
缓存的命中率越高越好，如果设置了很多缓存，但命中率不高，同样还是会造成穿透到后端访问，此时还需要考虑将缓存的命中率设置的越高，这时观察指标，会发现缓存效果越优。

通常而言，一个网站如果做了缓存优化可以比没做缓存优化的性能提升几倍以上。

浏览器缓存

第一个就是浏览器缓存，浏览器缓存通常是缓存到客户端(如：浏览器、客户端app)，这就是浏览器缓存。

对于浏览器这部分缓存数据，我们通常可以把静态元素，比如用户请求的图片、CSS 、JS 等元素缓存到客户端。这种缓存可以通过 Nginx配置中的expires 配置项进行设置，expires 后面可以加具体的时间，也可以加对应的特定意义的数值，比如 -1 表示永久缓存，max 设置最大周期缓存（默认缓存周期为 10 年），需要做具体的时间的设置可以写入具体的时间周期，比如一个小时或是一天。

HTTPS 配置优化

当前我们很多网站通常在开启HTTPS ，当开启https后客户端访问服务端打开一次浏览器，通过https方式会比 HTTP 请求握手会要增加很多次从而延迟也增加了。这时就需要考虑 HTTPS 是否有更好的优化方案来减少客户端和服务端请求。

https

如图中是一个https请求过程，实际在进行HTTPS 请求之前的需要进行TCP 的三次握手过程，而这里我只是描述 HTTPS 的建连过程，客户端发送hello 报文，服务端发送证书，客户端进行加密，服务端验证加密。这时开始进行服务端与客户端的传输。我们看到整个 HTTPS 建连增加了部分的证书加密的协商。

多次的连接对于用户及服务端而言，性能和延迟都会增加很多。并且如果每一次浏览器跟服务端断开连接以后，又要进行一次整体的建立连接的过程。为了减少客户端和服务端的断开重连过程，这时就需要在Nginx中配置ssl_session_cache 发挥作用。

下面我们来说下这个配置原理，当浏览器跟服务端建立第一次加密证书验证的会话后，服务端会给客户端浏览器缓存一个 SessionKey，如果客户端跟服务端再次断开连接，这时浏览器就可以拿SessionKey 直接跟服务端进行交互。只需要进行一次校验，就可以开始数据传输。我们看到有了SessionKey 这种方式后，就可以避免浏览器跟服务端频繁的进行 HTTPS 会话的建联。

通过在 Nginx 中添加 ssl_session_cache 配置，配置中分配 Nginx 在处理 SSL 会话所需要开辟的共享内存的空间，我这里这里设置值为 10 MB，第二个参数就是设置 SSL SessionKey 的超时时间，这里设置的为 10 分钟，也就是每隔 10 分钟需要重新再进行一次建联，这是一个在服务端的超时时间。

打开文件缓存

打开文件缓存设置在 Nginx 端，通常而言我们会把一些静态元素（如：JPG、CSS、GS）在代理端通过这种方式进行设置，这里 Nginx 缓存的是静态元素的元数据。那么把元数据缓存到 Nginx 端有什么好处？元数据的作用就是缓存打开用户所请求的静态元素的文件路径等信息，那么如果在本地频繁地查找之前请求过的静态元素文件而没有缓存元数据时效率比较低，而如果我们把一部分索引数据缓存到Nginx 的 Cache 下，这种频繁访问就可以很大地提高访问效率。

我们来看 open_file_cache 具体的设置策略，max 表示最大能够缓存的文件个数，inactive 表示最少的用户使用次数。我们结合看一下，这个表示在 20 秒内最小需要使用两次。如果没有使用的话，就会把元数据删掉，也这就是一个淘汰元数据的策略。

open_file_cache_valid 是设置主动更新和检查的时间，表示每隔 30 秒检查缓存文件的元信息有没有对应的更新，如果有更新就需要去做对应的更新，它是一个更新的策略。

代理缓存优化

cache

代理缓存比较常见，比如说代理访问PHP 后台服务并作缓存，也可以代理 JAVA 服务，缓存 JAVA后台服务的返回数据，注意这里不局限于通过 http_proxy来作代理缓存，只要 Nginx 支持的代理模式(UWSGI、SGI)都可以设置代理缓存。你可以来看一下通过http_proxy设置的如下示例：

proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m 
location / {
        proxy_cache my_cache;
        …
}

proxy_cache_path 表示在本地分配哪个路径来存储并缓存后台返回数据；cache levels 表示存放文件的分层方式；my_cache:10m max_size=10g 分别表示是开辟一个名为my_cache共享块（用于统计访问次数）及缓存的单个文件的最大大小等。

这些都是做对应的缓存在本地的文件目录相关属性的一些设置。另外一块的设置表示在proxy_cache 的时候，通过 location 引用到cache 的名称。

代理缓存的特性是什么呢？首先通过 Nginx 作代理，可以支持实现动静态的分离，静态元素直接交给Nginx 来处理，再把后端动态数据适当作缓存。通常做这种代理+缓存的架构，是能有效的提高整体网站的访问并发性能。

对于我们提到的服务端的缓存优化大多交给开发来做这里就不再做非 Nginx 的缓存配置的讲解了。

缓存使用注意问题

对于缓存的整体使用，之前说的缓存越多越好，越靠前越好，命中率越高越好，但是同时我们也需要综合考虑，并且注意缓存在使用时遇到的一些实际问题。

文件更新策略问题。文件后端做缓存的配置策略的时候，要考虑到缓存的删除策略、更新策略。怎么保证它的后端数据更新对于前端用户能够及时的感知。
缓存命中率失败给后端造成的瞬间压力。我们知道，当前端缓存的元素越多，命中率越高，对于后台的压力就越少。当一旦前段的缓存失效，或者某个节点迁移，或者某一部分的前端头信息失效，造成后端缓存瞬间压力，就可能会造成比较灾难性的后果。所以你在网站设计的时候也需要考虑，怎么去避免这种缓存失效？一旦前端缓存失效，你怎么保证后端服务的高可用而不受影响？
多节点缓存一致性。你在做缓存设置的时候也需要考虑到，假设前端有很多个节点，保存同样的一部分内容的时候，怎么保证这些数据是能够达到一致性，这个时候也涉及缓存架构的设计，前端的缓存节点的更新策略，这些也是你在实际使用缓存时应该注意的问题。

未完待续
文章优先发于公众号运维大师兄，回复资料，更有java，python，go，前端等最新视频教程，等你来拿！
本文禁止转载