在学习如何优化和配置 Nginx 之前，首先须要提前节制一些根本知识，包括：
熟习Linux 的根本操作；理解 Nginx 安装和根本配置；对 HTTP 要求过程有一定理解。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 版本往后提出的，早期内核利用的 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 线程浸染，那每一个 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=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 根本配置优化和缓存配置优化，下一次我们说一下 Nginx 的负载均衡优化配置。
（此处已添加圈子卡片，请到今日头条客户端查看）
