相信做過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)，這就是瀏覽器緩存。

對于瀏覽器這部分緩存數據，我們通?？梢园鸯o態元素，比如用戶請求的圖片、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 來處理，再把后端動態數據適當作緩存。通常做這種代理+緩存的架構，是能有效的提高整體網站的訪問并發性能。

緩存使用注意問題

對于緩存的整體使用，之前說的緩存越多越好，越靠前越好，命中率越高越好，但是同時我們也需要綜合考慮，并且注意緩存在使用時遇到的一些實際問題。

文件更新策略問題。文件后端做緩存的配置策略的時候，要考慮到緩存的刪除策略、更新策略，怎么保證它的后端數據更新對于前端用戶能夠及時的感知。

緩存命中率失敗給后端造成的瞬間壓力。我們知道，當前端緩存的元素越多，命中率越高，對于后臺的壓力就越少。當一旦前端的緩存失效，或者某個節點遷移，或者某一部分的前端頭信息失效，造成后端緩存瞬間壓力，就可能會造成比較災難性的后果。所以你在網站設計的時候也需要考慮，怎么去避免這種緩存失效？一旦前端緩存失效，你怎么保證后端服務的高可用而不受影響？