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

在学习如何优化和配置 Nginx 之前，首先需要提前掌握一些基础知识，包括：

• 熟悉linux 的基础操作；

• 了解 Nginx 安装和基础配置；

• 对 HTTP 请求过程有一定了解。

Nginx 的优化主要分为基础优化和缓存优化，我们先来看一下基础优化。

基础配置优化主要包括：

• CPU 亲和性优化；

• Nginx 模型优化；

• Nginx 传输方式优化；

• Nginx 文件压缩优化。

在 Nginx 用于普通的绝大部分 Web 服务时这些优化场景都是需要了解的。

CPU 亲和性

所谓的 CPU 亲和性是做什么呢？现在的CPU通常都是多核的，而且可以通过超线程来虚拟更多核数 ，那亲和力就是让 Nginx 充分发挥多核 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 的核心有 8 个，如果我们设置成 auto 后，那么 Nginx 会将 8 个 worker 线程一对一地按照推荐策略绑定到 CPU 核心上，这样避免 CPU 频繁对 worker 线程进行调度，从而降低 CPU 损耗。

IO 流事件模型

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

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

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

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

那么 epoll 相比于 select 模型到底具备哪些优势呢？

• epoll 处理事件流模型是线程安全的；

• epoll 跟 select 模型相比调用 fd 文件描述符时使用了 mmap 共享用户和内核的部分空间，提高了效率；

• epoll 是基于事件驱动的，相比 select 需要扫描整个文件描述符的相关状态，epoll 基于事件驱动避免频繁扫描文件描述符，可以直接调用 callback 回调函数，效率更高；

• 取消了 select 模型里面单个进程能够监视的文件描述符的数量存在的最大限制（1024），如果你有使用过早期的 Apache 版本的，它使用的select 模型，当请求超过 1000 以后就会出现延迟或者请求错误，而改用 Nginx 的话性能会得到明显的改善。

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

零拷贝

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

 

如图所示，如果我们没有使用零拷贝时文件传输是什么样子的？首先 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_min_length 256 表示只有大于最小的 256 字节长度时才进行压缩，如果小于该长度就不进行压缩；

• 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 浏览器请求过来的压缩，以上就是对文件压缩的典型配置，你可以根据具体情况做一些细节上的调整。

上面就是我们讲了基础优化，但是我们在使用 Nginx 作为代理入口的时候，对于网站优化有效的方式除了需要考虑基础配置优化外，更有用的方式就是优化缓存。用到缓存优化主要期望提高网站服务访问效率，减少服务端的性能使用。

缓存配置优化大致可以分为几个部分，分别是浏览器缓存优化、代理缓存优化、HTTPS SSL 缓存优化、KV 服务缓存优化等。

首先我们需要了解一个问题，客户端如何直观的看到大部分缓存（浏览器缓存、代理缓存、ssl缓存）优化效果呢？推荐你用 Chrome 浏览器中的开发者工具，打开浏览器并点击视图-开发者工具。例如我们在 URL 地址栏中输入 www.baidu.com。这个时候我们会看到在 Network 标签栏中会出现对应的访问名称、路径。然后点击某一个路径，这时会在 Headers 中看到相应的头信息内容。

我们刚用浏览器打开 www..com 这个网站，表示浏览器发送一次 HTTP 请求，我们能看到服务端会返回给客户端代码经过渲染后的一个效果展示。如果点击右键查看源代码，这样就可以看到网站返回的 body 内容。除了 body 之外，一个完整的 HTTP 响应，服务端返回给客户端还有一部分就是 Response Headers，表示服务端返回给客户端的头信息内容。

上面就是一次 HTTP 请求和响应的过程，如果我们想判断服务端有没有做缓存，缓存的时间是多长。这些内容都会在头信息中通过服务端展示给客户端，我们可以在 Response Headers 查看头信息。

比如expires 头信息是控制在什么时间点生成的缓存元素，Cache Control 负责保存这个元素需要缓存多长时间。

通过使用Chrome 开发者工具我们就能够非常清晰的看到一次页面的打开效果，了解它的请求了是什么（请求头），服务端返回了什么（ body及返回 头信息），通过这个工具详细的查看数据并对一个页面缓存情况进行分析，对于开发和运维人员而言是必须要掌握的。

缓存优化

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

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

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

如果只考虑缓存最优的话，那么参考以下三点即可：

• 缓存越靠前越好，通常情况下整个网站的元素内容越靠前越好，也就是说能放在客户端的就放在客户端，而不要放到后端去频繁请求。

• 缓存的数据越多越好，也就是能在本层级缓存的数据越多，就越可以减少对后端的请求。

• 缓存的命中率越高越好，如果设置了很多缓存，但命中率不高，同样还是会造成穿透到后端访问，此时还需要考虑将缓存的命中率设置的越高，这时观察指标，会发现缓存效果越优。

通常而言，一个网站如果做了缓存优化可以比没做缓存优化的性能提升几倍以上。下面我们就来具体介绍一下 Nginx 如何来设置缓存。

浏览器缓存

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

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

HTTPS 配置优化

现在几乎大部分网站都已经开启了 HTTPS，当开启https后客户端访问服务端打开一次浏览器，通过 HTTPS 方式会比 HTTP 请求握手会要增加很多次从而延迟也增加了。这时就需要考虑 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 分钟需要重新再进行一次建联，这是一个在服务端的超时时间。

好了，上面就是对 HTTPS 在会话层进行的缓存优化示例。

打开文件缓存

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

 

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

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

location / {
  index index.htm index.html;
  expires max;  
  open_file_cache max=1000 inactive=20s; 
  open_file_cache_valid 30s; 
  open_file_cache_min_uses 2; 
  open_file_cache_errors on;
}

代理缓存优化

最后就是代理缓存的优化了，代理缓存比较常见，比如说代理访问 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=60mlocation / {

        proxy_cache my_cache;

        …

}

proxy_cache_path 表示在本地分配哪个路径来存储并缓存后台返回数据；cache levels 表示存放文件的分层方式；my_cache:10m max_size=10g 分别表示是开辟一个名为my_cache共享块（用于统计访问次数）及缓存的单个文件的最大大小等。这些都是做对应的缓存在本地的文件目录相关属性的一些设置。另外一块的设置表示在proxy_cache 的时候，通过 location 引用到 cache 的名称。

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

缓存使用注意问题

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

• 文件更新策略问题。文件后端做缓存的配置策略的时候，要考虑到缓存的删除策略、更新策略，怎么保证它的后端数据更新对于前端用户能够及时的感知。

• 缓存命中率失败给后端造成的瞬间压力。我们知道，当前端缓存的元素越多，命中率越高，对于后台的压力就越少。当一旦前端的缓存失效，或者某个节点迁移，或者某一部分的前端头信息失效，造成后端缓存瞬间压力，就可能会造成比较灾难性的后果。所以你在网站设计的时候也需要考虑，怎么去避免这种缓存失效？一旦前端缓存失效，你怎么保证后端服务的高可用而不受影响？

• 多节点缓存一致性。你在做缓存设置的时候也需要考虑到，假设前端有很多个节点，保存同样的一部分内容的时候，怎么保证这些数据是能够达到一致性，这个时候也涉及缓存架构的设计，前端的缓存节点的更新策略，这些也是你在实际使用缓存时应该注意的问题。

总结

以上就是我们介绍的 Nginx 基础配置优化和缓存配置优化，下一次我们说一下 Nginx 的负载均衡优化配置。