# Nginx 靜態文件服務 我們先來看看最簡單的本地靜態文件服務配置示例： ~~~ server { listen 80; server_name www.test.com; charset utf-8; root /data/www.test.com; index index.html index.htm; } ~~~ 就這些？恩，就這些！如果只是提供簡單的對外靜態文件，它真的就可以用了。可是他不完美，遠遠沒有發揮 Nginx 的半成功力，為什么這么說呢，看看下面的配置吧，為了大家看著方便，我們把每一項的作用都做了注釋。 ~~~ http { # 這個將為打開文件指定緩存，默認是沒有啟用的，max 指定緩存數量， # 建議和打開文件數一致，inactive 是指經過多長時間文件沒被請求后刪除緩存。 open_file_cache max=204800 inactive=20s; # open_file_cache 指令中的inactive 參數時間內文件的最少使用次數， # 如果超過這個數字，文件描述符一直是在緩存中打開的，如上例，如果有一個 # 文件在inactive 時間內一次沒被使用，它將被移除。 open_file_cache_min_uses 1; # 這個是指多長時間檢查一次緩存的有效信息 open_file_cache_valid 30s; # 默認情況下，Nginx的gzip壓縮是關閉的， gzip壓縮功能就是可以讓你節省不 # 少帶寬，但是會增加服務器CPU的開銷哦，Nginx默認只對text/html進行壓縮 ， # 如果要對html之外的內容進行壓縮傳輸，我們需要手動來設置。 gzip on; gzip_min_length 1k; gzip_buffers 4 16k; gzip_http_version 1.0; gzip_comp_level 2; gzip_types text/plain application/x-javascript text/css application/xml; server { listen 80; server_name www.test.com; charset utf-8; root /data/www.test.com; index index.html index.htm; } } ~~~ 我們都知道，應用程序和網站一樣，其性能關乎生存。但如何使你的應用程序或者網站性能更好，并沒有一個明確的答案。代碼質量和架構是其中的一個原因，但是在很多例子中我們看到，你可以通過關注一些十分基礎的應用內容分發技術（basic application delivery techniques），來提高終端用戶的體驗。其中一個例子就是實現和調整應用棧（application stack）的緩存。 #### 文件緩存漫談 一個web緩存坐落于客戶端和“原始服務器（origin server）”中間，它保留了所有可見內容的拷貝。如果一個客戶端請求的內容在緩存中存儲，則可以直接在緩存中獲得該內容而不需要與服務器通信。這樣一來，由于web緩存距離客戶端“更近”，就可以提高響應性能，并更有效率的使用應用服務器，因為服務器不用每次請求都進行頁面生成工作。 在瀏覽器和應用服務器之間，存在多種“潛在”緩存，如：客戶端瀏覽器緩存、中間緩存、內容分發網絡（CDN）和服務器上的負載平衡和反向代理。緩存，僅在反向代理和負載均衡的層面，就對性能提高有很大的幫助。 舉個例子說明，去年，我接手了一項任務，這項任務的內容是對一個加載緩慢的網站進行性能優化。首先引起我注意的事情是，這個網站差不多花費了超過1秒鐘才生成了主頁。經過一系列調試，我發現加載緩慢的原因在于頁面被標記為不可緩存，即為了響應每一個請求，頁面都是動態生成的。由于頁面本身并不需要經常性的變更，并且不涉及個性化，那么這樣做其實并沒有必要。為了驗證一下我的結論，我將頁面標記為每5秒緩存一次，僅僅做了這一個調整，就能明顯的感受到性能的提升。第一個字節到達的時間降低到幾毫秒，同時頁面的加載明顯要更快。 并不是只有大規模的內容分發網絡（CDN）可以在使用緩存中受益——緩存還可以提高負載平衡器、反向代理和應用服務器前端web服務的性能。通過上面的例子，我們看到，緩存內容結果，可以更高效的使用應用服務器，因為不需要每次都去做重復的頁面生成工作。此外，Web緩存還可以用來提高網站可靠性。當服務器宕機或者繁忙時，比起返回錯誤信息給用戶，不如通過配置Nginx將已經緩存下來的內容發送給用戶。這意味著，網站在應用服務器或者數據庫故障的情況下，可以保持部分甚至全部的功能運轉。 下一部分討論如何安裝和配置Nginx的基礎緩存（Basic Caching）。 #### 如何安裝和配置基礎緩存 我們只需要兩個命令就可以啟用基礎緩存： [proxy_cache_path](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_path) 和 [proxy_cache](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache) 。proxy_cache_path用來設置緩存的路徑和配置，proxy_cache用來啟用緩存。 ~~~ proxy_cache_path/path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off; server { ... location / { proxy_cachemy_cache; proxy_pass http://my_upstream; } } ~~~ proxy_cache_path 命令中的參數及對應配置說明如下： 1. 用于緩存的本地磁盤目錄是 /path/to/cache/ 1. levels 在 /path/to/cache/ 設置了一個兩級層次結構的目錄。將大量的文件放置在單個目錄中會導致文件訪問緩慢，所以針對大多數部署，我們推薦使用兩級目錄層次結構。如果levels參數沒有配置，則 Nginx 會將所有的文件放到同一個目錄中。 1. keys_zone設置一個共享內存區，該內存區用于存儲緩存鍵和元數據，有些類似計時器的用途。將鍵的拷貝放入內存可以使 Nginx 在不檢索磁盤的情況下快速決定一個請求是`HIT`還是`MISS`，這樣大大提高了檢索速度。一個1MB的內存空間可以存儲大約8000個key，那么上面配置的10MB內存空間可以存儲差不多80000個key。 1. max_size設置了緩存的上限（在上面的例子中是10G）。這是一個可選項；如果不指定具體值，那就是允許緩存不斷增長，占用所有可用的磁盤空間。當緩存達到這個上線，處理器便調用cache manager來移除最近最少被使用的文件，這樣把緩存的空間降低至這個限制之下。 1. inactive指定了項目在不被訪問的情況下能夠在內存中保持的時間。在上面的例子中，如果一個文件在60分鐘之內沒有被請求，則緩存管理將會自動將其在內存中刪除，不管該文件是否過期。該參數默認值為10分鐘（10m）。注意，非活動內容有別于過期內容。 Nginx 不會自動刪除由緩存控制頭部指定的過期內容（本例中Cache-Control:max-age=120）。過期內容只有在inactive指定時間內沒有被訪問的情況下才會被刪除。如果過期內容被訪問了，那么 Nginx 就會將其從原服務器上刷新，并更新對應的inactive計時器。 1. Nginx 最初會將注定寫入緩存的文件先放入一個臨時存儲區域，use_temp_path=off命令指示 Nginx 將在緩存這些文件時將它們寫入同一個目錄下。我們強烈建議你將參數設置為off來避免在文件系統中不必要的數據拷貝。use_temp_path在 Nginx 1.7版本和 Nginx Plus R6中有所介紹。 最終，proxy_cache 命令啟動緩存那些URL與location部分匹配的內容（本例中，為`/`）。你同樣可以將proxy_cache命令添加到server部分，這將會將緩存應用到所有的那些location中未指定自己的proxy_cache命令的服務中。 #### 陳舊總比沒有強 Nginx 內容緩存的一個非常強大的特性是：當無法從原始服務器獲取最新的內容時， Nginx 可以分發緩存中的陳舊（stale，編者注：即過期內容）內容。這種情況一般發生在關聯緩存內容的原始服務器宕機或者繁忙時。比起對客戶端傳達錯誤信息， Nginx 可發送在其內存中的陳舊的文件。 Nginx 的這種代理方式，為服務器提供額外級別的容錯能力，并確保了在服務器故障或流量峰值的情況下的正常運行。為了開啟該功能，只需要添加 [proxy_cache_use_stale](http://nginx.org/en/docs/http/ngx_http_proxy_module.html?&_ga=1.14624247.1568941527.1438257987#proxy_cache_use_stale) 命令即可： ~~~ location / { ... proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504; } ~~~ 按照上面例子中的配置，當 Nginx 收到服務器返回的error，timeout或者其他指定的5xx錯誤，并且在其緩存中有請求文件的陳舊版本，則會將這些陳舊版本的文件而不是錯誤信息發送給客戶端。 #### 緩存微調 Nginx 提供了豐富的可選項配置用于緩存性能的微調。下面是使用了幾個配置的例子： ~~~ proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off; server { ... location / { proxy_cache my_cache; proxy_cache_revalidateon; proxy_cache_min_uses3; proxy_cache_use_staleerror timeoutupdatinghttp_500 http_502 http_503 http_504; proxy_cache_lockon; proxy_pass http://my_upstream; } } ~~~ 這些命令配置了下列的行為： 1. [proxy_cache_revalidate](http://nginx.org/r/proxy_cache_revalidate?_ga=1.80437143.1235345339.1438303904) 指示 Nginx 在刷新來自服務器的內容時使用GET請求。如果客戶端的請求項已經被緩存過了，但是在緩存控制頭部中定義為過期，那么 Nginx 就會在GET請求中包含If-Modified-Since字段，發送至服務器端。這項配置可以節約帶寬，因為對于 Nginx 已經緩存過的文件，服務器只會在該文件請求頭中Last-Modified記錄的時間內被修改時才將全部文件一起發送。 1. [proxy_cache_min_uses](http://nginx.org/r/proxy_cache_min_uses?_ga=1.82886422.1235345339.1438303904) 設置了在 Nginx 緩存前，客戶端請求一個條目的最短時間。當緩存不斷被填滿時，這項設置便十分有用，因為這確保了只有那些被經常訪問的內容才會被添加到緩存中。該項默認值為1。 1. [proxy_cache_use_stale](http://nginx.org/en/docs/http/ngx_http_proxy_module.html?&_ga=1.13131319.1235345339.1438303904#proxy_cache_use_stale) 中的updating參數告知 Nginx 在客戶端請求的項目的更新正在原服務器中下載時發送舊內容，而不是向服務器轉發重復的請求。第一個請求陳舊文件的用戶不得不等待文件在原服務器中更新完畢。陳舊的文件會返回給隨后的請求直到更新后的文件被全部下載。4.當 [proxy_cache_lock](http://nginx.org/en/docs/http/ngx_http_proxy_module.html?&_ga=1.86844376.1568941527.1438257987#proxy_cache_lock) 被啟用時，當多個客戶端請求一個緩存中不存在的文件（或稱之為一個MISS），只有這些請求中的第一個被允許發送至服務器。其他請求在第一個請求得到滿意結果之后在緩存中得到文件。如果不啟用proxy_cache_lock，則所有在緩存中找不到文件的請求都會直接與服務器通信。 #### 跨多硬盤分割緩存 使用 Nginx ，不需要建立一個RAID（磁盤陣列）。如果有多個硬盤， Nginx 可以用來在多個硬盤之間分割緩存。下面是一個基于請求URI跨越兩個硬盤之間均分緩存的例子： ~~~ proxy_cache_path /path/to/hdd1 levels=1:2 keys_zone=my_cache_hdd1:10m max_size=10g inactive=60m use_temp_path=off; proxy_cache_path /path/to/hdd2 levels=1:2 keys_zone=my_cache_hdd2:10m max_size=10g inactive=60m use_temp_path=off; split_clients $request_uri $my_cache { 50% "my_cache_hdd1"; 50% "my_cache_hdd2"; } server { ... location / { proxy_cache $my_cache; proxy_pass http://my_upstream; } } ~~~