引言

在上文《HTTP/HTTPS》中曾談到了代理伺服器的概念，其主要作用之一就是用於負載均衡與請求分發，那麼先來看看為何需要做請求負載。

早期的業務都是基於單體節點部署，由於前期訪問流量不大，因此單體結構也可滿足需求，但隨著業務增長，流量也越來越大，那麼最終單臺伺服器受到的訪問壓力也會逐步增高。時間一長，單臺伺服器效能無法跟上業務增長，就會造成線上頻繁宕機的現象發生，最終導致系統癱瘓無法繼續處理使用者的請求。

從上面的描述中，主要存在兩個問題：
①單體結構的部署方式無法承載日益增長的業務流量。
②當後端節點宕機後，整個系統會陷入癱瘓，導致整個專案不可用。

因此在這種背景下，引入負載均衡技術可帶來的收益：
- 系統的高可用：當某個節點宕機後可以迅速將流量轉移至其他節點。 - 系統的高效能：多臺伺服器共同對外提供服務，為整個系統提供了更高規模的吞吐。 - 系統的拓展性：當業務再次出現增長或萎靡時，可再加入/減少節點，靈活伸縮。

OK~，既然引入負載均衡技術可給我們帶來如此巨大的好處，那麼又有那些方案可供選擇呢？主要有兩種負載方案，硬體層面與軟體層面，比較常用的硬體負載器有A10、F5等，但這些機器動輒大幾萬乃至幾十萬的成本，因此一般大型企業會採用該方案，如銀行、國企、央企等。
而成本有限，但依舊想做負載均衡的專案，那麼可在軟體層面實現，如典型的Nginx等，軟體層的負載也是本文的重點，畢竟Boss們的準則之一就是：能靠技術實現的就儘量不花錢。

當然，如果你認為本文對你而言有幫助，記得點贊、收藏、關注三連噢！

一、效能怪獸-Nginx概念深入淺出

Nginx是目前負載均衡技術中的主流方案，幾乎絕大部分專案都會使用它，Nginx是一個輕量級的高效能HTTP反向代理伺服器，同時它也是一個通用型別的代理伺服器，支援絕大部分協議，如TCP、UDP、SMTP、HTTPS等。
Nginx-LOGO
Nginx與之前談及的《Redis》相同，都是基於多路複用模型構建出的產物，因此它與Redis同樣具備資源佔用少、併發支援高的特點，在理論上單節點的Nginx同時支援5W併發連線，而實際生產環境中，硬體基礎到位再結合簡單調優後確實能達到該數值。

先來看看Nginx引入前後，客戶端請求處理流程的對比：
Nginx前後區別
原本客戶端是直接請求目標伺服器，由目標伺服器直接完成請求處理工作，但加入Nginx後，所有的請求會先經過Nginx，再由其進行分發到具體的伺服器處理，處理完成後再返回Nginx，最後由Nginx將最終的響應結果返回給客戶端。

瞭解了Nginx的基本概念後，再來快速搭建一下環境，以及瞭解一些Nginx的高階特性，如動靜分離、資源壓縮、快取配置、IP黑名單、高可用保障等。

二、Nginx環境搭建

❶首先建立Nginx的目錄並進入： shell [[email protected]]# mkdir /soft && mkdir /soft/nginx/ [[email protected]]# cd /soft/nginx/

❷下載Nginx的安裝包，可以通過FTP工具上傳離線環境包，也可通過wget命令線上獲取安裝包：
shell [[email protected]]# wget https://nginx.org/download/nginx-1.21.6.tar.gz 沒有wget命令的可通過yum命令安裝：
shell [[email protected]]# yum -y install wget

❸解壓Nginx的壓縮包： shell [[email protected]]# tar -xvzf nginx-1.21.6.tar.gz

❹下載並安裝Nginx所需的依賴庫和包：
shell [[email protected]]# yum install --downloadonly --downloaddir=/soft/nginx/ gcc-c++ [[email protected]]# yum install --downloadonly --downloaddir=/soft/nginx/ pcre pcre-devel4 [[email protected]]# yum install --downloadonly --downloaddir=/soft/nginx/ zlib zlib-devel [[email protected]]# yum install --downloadonly --downloaddir=/soft/nginx/ openssl openssl-devel 也可以通過yum命令一鍵下載（推薦上面哪種方式）：
shell [[email protected]]# yum -y install gcc zlib zlib-devel pcre-devel openssl openssl-devel 執行完成後，然後ls檢視目錄檔案，會看一大堆依賴：
Nginx-依賴包
緊接著通過rpm命令依次將依賴包一個個構建，或者通過如下指令一鍵安裝所有依賴包：
shell [[email protected]]# rpm -ivh --nodeps *.rpm

❺進入解壓後的nginx目錄，然後執行Nginx的配置指令碼，為後續的安裝提前配置好環境，預設位於/usr/local/nginx/目錄下（可自定義目錄）：
shell [[email protected]]# cd nginx-1.21.6 [[email protected]]# ./configure --prefix=/soft/nginx/

❻編譯並安裝Nginx： shell [[email protected]]# make && make install

❼最後回到前面的/soft/nginx/目錄，輸入ls即可看見安裝nginx完成後生成的檔案。

❽修改安裝後生成的conf目錄下的nginx.conf配置檔案：
shell [[email protected]]# vi conf/nginx.conf 修改埠號：listen 80; 修改IP地址：server_name 你當前機器的本地IP(線上配置域名);

❾制定配置檔案並啟動Nginx：
shell [[email protected]]# sbin/nginx -c conf/nginx.conf [[email protected]]# ps aux | grep nginx Nginx其他操作命令： shell sbin/nginx -t -c conf/nginx.conf # 檢測配置檔案是否正常 sbin/nginx -s reload -c conf/nginx.conf # 修改配置後平滑重啟 sbin/nginx -s quit # 優雅關閉Nginx，會在執行完當前的任務後再退出 sbin/nginx -s stop # 強制終止Nginx，不管當前是否有任務在執行

❿開放80埠，並更新防火牆： shell [[email protected]]# firewall-cmd --zone=public --add-port=80/tcp --permanent [[email protected]]# firewall-cmd --reload [[email protected]]# firewall-cmd --zone=public --list-ports

⓫在Windows/Mac的瀏覽器中，直接輸入剛剛配置的IP地址訪問Nginx：

最終看到如上的Nginx歡迎介面，代表Nginx安裝完成。

三、Nginx反向代理-負載均衡

首先通過SpringBoot+Freemarker快速搭建一個WEB專案：springboot-web-nginx，然後在該專案中，建立一個IndexNginxController.java檔案，邏輯如下：
```java @Controller public class IndexNginxController { @Value("${server.port}") private String port;

@RequestMapping("/")
public ModelAndView index(){
    ModelAndView model = new ModelAndView();
    model.addObject("port", port);
    model.setViewName("index");
    return model;
}

} `` 在該Controller類中，存在一個成員變數：port，它的值即是從application.properties配置檔案中獲取server.port值。當出現訪問/資源的請求時，跳轉前端index`頁面，並將該值攜帶返回。

前端的index.ftl檔案程式碼如下：
html <html> <head> <title>Nginx演示頁面</title> <link href="nginx_style.css" rel="stylesheet" type="text/css"/> </head> <body> <div style="border: 2px solid red;margin: auto;width: 800px;text-align: center"> <div id="nginx_title"> <h1>歡迎來到熊貓高階會所，我是竹子${port}號！</h1> </div> </div> </body> </html> 從上可以看出其邏輯並不複雜，僅是從響應中獲取了port輸出。

OK~，前提工作準備就緒後，再簡單修改一下nginx.conf的配置即可： ```shell upstream nginx_boot{ # 30s內檢查心跳傳送兩次包，未回覆就代表該機器宕機，請求分發權重比為1:2 server 192.168.0.000:8080 weight=100 max_fails=2 fail_timeout=30s; server 192.168.0.000:8090 weight=200 max_fails=2 fail_timeout=30s; # 這裡的IP請配置成你WEB服務所在的機器IP }

server { location / { root html; # 配置一下index的地址，最後加上index.ftl。 index index.html index.htm index.jsp index.ftl; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # 請求交給名為nginx_boot的upstream上 proxy_pass http://nginx_boot; } } ```

至此，所有的前提工作準備就緒，緊接著再啟動Nginx，然後再啟動兩個web服務，第一個WEB服務啟動時，在application.properties配置檔案中，將埠號改為8080，第二個WEB服務啟動時，將其埠號改為8090。

最終來看看效果：
負載均衡效果-動圖演示
因為配置了請求分發的權重，8080、8090的權重比為2:1，因此請求會根據權重比均攤到每臺機器，也就是8080一次、8090兩次、8080一次......

Nginx請求分發原理

客戶端發出的請求192.168.12.129最終會轉變為：http://192.168.12.129:80/，然後再向目標IP發起請求，流程如下：
請求分發原理
- 由於Nginx監聽了192.168.12.129的80埠，所以最終該請求會找到Nginx程序； - Nginx首先會根據配置的location規則進行匹配，根據客戶端的請求路徑/，會定位到location /{}規則； - 然後根據該location中配置的proxy_pass會再找到名為nginx_boot的upstream； - 最後根據upstream中的配置資訊，將請求轉發到執行WEB服務的機器處理，由於配置了多個WEB服務，且配置了權重值，因此Nginx會依次根據權重比分發請求。

四、Nginx動靜分離

動靜分離應該是聽的次數較多的效能優化方案，那先思考一個問題：為什麼需要做動靜分離呢？它帶來的好處是什麼？ 其實這個問題也並不難回答，當你搞懂了網站的本質後，自然就理解了動靜分離的重要性。先來以淘寶為例分析看看：

當瀏覽器輸入www.taobao.com訪問淘寶首頁時，開啟開發者除錯工具可以很明顯的看到，首頁載入會出現100+的請求數，而正常專案開發時，靜態資源一般會放入到resources/static/目錄下：
IDEA工程結構
在專案上線部署時，這些靜態資源會一起打成包，那此時思考一個問題：假設淘寶也是這樣乾的，那麼首頁載入時的請求最終會去到哪兒被處理？ 答案毋庸置疑，首頁100+的所有請求都會來到部署WEB服務的機器處理，那則代表著一個客戶端請求淘寶首頁，就會對後端伺服器造成100+的併發請求。毫無疑問，這對於後端伺服器的壓力是尤為巨大的。

但此時不妨分析看看，首頁100+的請求中，是不是至少有60+是屬於*.js、*.css、*.html、*.jpg.....這類靜態資源的請求呢？答案是Yes。

既然有這麼多請求屬於靜態的，這些資源大概率情況下，長時間也不會出現變動，那為何還要讓這些請求到後端再處理呢？能不能在此之前就提前處理掉？當然OK，因此經過分析之後能夠明確一點：做了動靜分離之後，至少能夠讓後端服務減少一半以上的併發量。 到此時大家應該明白了動靜分離能夠帶來的效能收益究竟有多大。

OK~，搞清楚動靜分離的必要性之後，如何實現動靜分離呢？其實非常簡單，實戰看看。

①先在部署Nginx的機器，Nginx目錄下建立一個目錄static_resources：

mkdir static_resources

②將專案中所有的靜態資源全部拷貝到該目錄下，而後將專案中的靜態資源移除重新打包。

③稍微修改一下nginx.conf的配置，增加一條location匹配規則：
shell location ~ .*\.(html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css){ root /soft/nginx/static_resources; expires 7d; } 然後照常啟動nginx和移除了靜態資源的WEB服務，你會發現原本的樣式、js效果、圖片等依舊有效，如下：
移除靜態資源
其中static目錄下的nginx_style.css檔案已被移除，但效果依舊存在（綠色字型+藍色大邊框）：
移除後效果動圖

最後解讀一下那條location規則：
location ~ .*\.(html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css)
~代表匹配時區分大小寫
.*代表任意字元都可以出現零次或多次，即資源名不限制
\.代表匹配字尾分隔符.
(html|...|css)代表匹配括號裡所有靜態資源型別
綜上所述，簡單一句話概述：該配置表示匹配以.html~.css為字尾的所有資源請求。

最後提一嘴，也可以將靜態資源上傳到檔案伺服器中，然後location中配置一個新的upstream指向。

五、Nginx資源壓縮

建立在動靜分離的基礎之上，如果一個靜態資源的Size越小，那麼自然傳輸速度會更快，同時也會更節省頻寬，因此我們在部署專案時，也可以通過Nginx對於靜態資源實現壓縮傳輸，一方面可以節省頻寬資源，第二方面也可以加快響應速度並提升系統整體吞吐。

在Nginx也提供了三個支援資源壓縮的模組ngx_http_gzip_module、ngx_http_gzip_static_module、ngx_http_gunzip_module，其中ngx_http_gzip_module屬於內建模組，代表著可以直接使用該模組下的一些壓縮指令，後續的資源壓縮操作都基於該模組，先來看看壓縮配置的一些引數/指令：

瞭解了Nginx中的基本壓縮配置後，接下來可以在Nginx中簡單配置一下：
shell http{ # 開啟壓縮機制 gzip on; # 指定會被壓縮的檔案型別(也可自己配置其他型別) gzip_types text/plain application/javascript text/css application/xml text/javascript image/jpeg image/gif image/png; # 設定壓縮級別，越高資源消耗越大，但壓縮效果越好 gzip_comp_level 5; # 在頭部中新增Vary: Accept-Encoding（建議開啟） gzip_vary on; # 處理壓縮請求的緩衝區數量和大小 gzip_buffers 16 8k; # 對於不支援壓縮功能的客戶端請求不開啟壓縮機制 gzip_disable "MSIE [1-6]\."; # 低版本的IE瀏覽器不支援壓縮 # 設定壓縮響應所支援的HTTP最低版本 gzip_http_version 1.1; # 設定觸發壓縮的最小閾值 gzip_min_length 2k; # 關閉對後端伺服器的響應結果進行壓縮 gzip_proxied off; } 在上述的壓縮配置中，最後一個gzip_proxied選項，可以根據系統的實際情況決定，總共存在多種選項： - off：關閉Nginx對後臺伺服器的響應結果進行壓縮。 - expired：如果響應頭中包含Expires資訊，則開啟壓縮。 - no-cache：如果響應頭中包含Cache-Control:no-cache資訊，則開啟壓縮。 - no-store：如果響應頭中包含Cache-Control:no-store資訊，則開啟壓縮。 - private：如果響應頭中包含Cache-Control:private資訊，則開啟壓縮。 - no_last_modified：如果響應頭中不包含Last-Modified資訊，則開啟壓縮。 - no_etag：如果響應頭中不包含ETag資訊，則開啟壓縮。 - auth：如果響應頭中包含Authorization資訊，則開啟壓縮。 - any：無條件對後端的響應結果開啟壓縮機制。

OK~，簡單修改好了Nginx的壓縮配置後，可以在原本的index頁面中引入一個jquery-3.6.0.js檔案： ```html

`` 分別來對比下壓縮前後的區別： ![Nginx壓縮前後區別](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2116205a44c941efb06b8fc95c737a54~tplv-k3u1fbpfcp-watermark.image?) 從圖中可以很明顯看出，未開啟壓縮機制前訪問時，js檔案的原始大小為230K，當配置好壓縮後再重啟Nginx，會發現檔案大小從230KB→69KB`，效果立竿見影！

注意點：
①對於圖片、影片型別的資料，會預設開啟壓縮機制，因此一般無需再次開啟壓縮。
②對於.js檔案而言，需要指定壓縮型別為application/javascript，而並非text/javascript、application/x-javascript。

六、Nginx緩衝區

先來思考一個問題，接入Nginx的專案一般請求流程為：“客戶端→Nginx→服務端”，在這個過程中存在兩個連線：“客戶端→Nginx、Nginx→服務端”，那麼兩個不同的連線速度不一致，就會影響使用者的體驗（比如瀏覽器的載入速度跟不上服務端的響應速度）。
其實也就類似電腦的記憶體跟不上CPU速度，所以對於使用者造成的體驗感極差，因此在CPU設計時都會加入三級高速緩衝區，用於緩解CPU和記憶體速率不一致的矛盾。在Nginx也同樣存在緩衝區的機制，主要目的就在於：用來解決兩個連線之間速度不匹配造成的問題，有了緩衝後，Nginx代理可暫存後端的響應，然後按需供給資料給客戶端。先來看看一些關於緩衝區的配置項：
- proxy_buffering：是否啟用緩衝機制，預設為on關閉狀態。 - client_body_buffer_size：設定緩衝客戶端請求資料的記憶體大小。 - proxy_buffers：為每個請求/連線設定緩衝區的數量和大小，預設4 4k/8k。 - proxy_buffer_size：設定用於儲存響應頭的緩衝區大小。 - proxy_busy_buffers_size：在後端資料沒有完全接收完成時，Nginx可以將busy狀態的緩衝返回給客戶端，該引數用來設定busy狀態的buffer具體有多大，預設為proxy_buffer_size*2。 - proxy_temp_path：當記憶體緩衝區存滿時，可以將資料臨時存放到磁碟，該引數是設定儲存緩衝資料的目錄。 - 語法：proxy_temp_path path; - path是臨時目錄的路徑。 - proxy_temp_file_write_size：設定每次寫資料到臨時檔案的大小限制。 - proxy_max_temp_file_size：設定臨時的緩衝目錄中允許儲存的最大容量。 - 非緩衝引數項： - proxy_connect_timeout：設定與後端伺服器建立連線時的超時時間。 - proxy_read_timeout：設定從後端伺服器讀取響應資料的超時時間。 - proxy_send_timeout：設定向後端伺服器傳輸請求資料的超時時間。

具體的nginx.conf配置如下： shell http{ proxy_connect_timeout 10; proxy_read_timeout 120; proxy_send_timeout 10; proxy_buffering on; client_body_buffer_size 512k; proxy_buffers 4 64k; proxy_buffer_size 16k; proxy_busy_buffers_size 128k; proxy_temp_file_write_size 128k; proxy_temp_path /soft/nginx/temp_buffer; } 上述的緩衝區引數，是基於每個請求分配的空間，而並不是所有請求的共享空間。當然，具體的引數值還需要根據業務去決定，要綜合考慮機器的記憶體以及每個請求的平均資料大小。

最後提一嘴：使用緩衝也可以減少即時傳輸帶來的頻寬消耗。

七、Nginx快取機制

對於效能優化而言，快取是一種能夠大幅度提升效能的方案，因此幾乎可以在各處都能看見快取，如客戶端快取、代理快取、伺服器快取等等，Nginx的快取則屬於代理快取的一種。對於整個系統而言，加入快取帶來的優勢額外明顯：
- 減少了再次向後端或檔案伺服器請求資源的頻寬消耗。 - 降低了下游伺服器的訪問壓力，提升系統整體吞吐。 - 縮短了響應時間，提升了載入速度，開啟頁面的速度更快。

那麼在Nginx中，又該如何配置代理快取呢？先來看看快取相關的配置項：
- proxy_cache_path：代理快取的路徑。 - 語法：proxy_cache_path path [levels=levels] [use_temp_path=on|off] keys_zone=name:size [inactive=time] [max_size=size] [manager_files=number] [manager_sleep=time] [manager_threshold=time] [loader_files=number] [loader_sleep=time] [loader_threshold=time] [purger=on|off] [purger_files=number] [purger_sleep=time] [purger_threshold=time]; - 是的，你沒有看錯，就是這麼長....，解釋一下每個引數項的含義： - path：快取的路徑地址。 - levels：快取儲存的層次結構，最多允許三層目錄。 - use_temp_path：是否使用臨時目錄。 - keys_zone：指定一個共享記憶體空間來儲存熱點Key(1M可儲存8000個Key)。 - inactive：設定快取多長時間未被訪問後刪除（預設是十分鐘）。 - max_size：允許快取的最大儲存空間，超出後會基於LRU演算法移除快取，Nginx會建立一個Cache manager的程序移除資料，也可以通過purge方式。 - manager_files：manager程序每次移除快取檔案數量的上限。 - manager_sleep：manager程序每次移除快取檔案的時間上限。 - manager_threshold：manager程序每次移除快取後的間隔時間。 - loader_files：重啟Nginx載入快取時，每次載入的個數，預設100。 - loader_sleep：每次載入時，允許的最大時間上限，預設200ms。 - loader_threshold：一次載入後，停頓的時間間隔，預設50ms。 - purger：是否開啟purge方式移除資料。 - purger_files：每次移除快取檔案時的數量。 - purger_sleep：每次移除時，允許消耗的最大時間。 - purger_threshold：每次移除完成後，停頓的間隔時間。 - proxy_cache：開啟或關閉代理快取，開啟時需要指定一個共享記憶體區域。 - 語法：proxy_cache zone | off; - zone為記憶體區域的名稱，即上面中keys_zone設定的名稱。 - proxy_cache_key：定義如何生成快取的鍵。 - 語法：proxy_cache_key string; - string為生成Key的規則，如$scheme$proxy_host$request_uri。 - proxy_cache_valid：快取生效的狀態碼與過期時間。 - 語法：proxy_cache_valid [code ...] time; - code為狀態碼，time為有效時間，可以根據狀態碼設定不同的快取時間。 - 例如：proxy_cache_valid 200 302 30m; - proxy_cache_min_uses：設定資源被請求多少次後被快取。 - 語法：proxy_cache_min_uses number; - number為次數，預設為1。 - proxy_cache_use_stale：當後端出現異常時，是否允許Nginx返回快取作為響應。 - 語法：proxy_cache_use_stale error; - error為錯誤型別，可配置timeout|invalid_header|updating|http_500...。 - proxy_cache_lock：對於相同的請求，是否開啟鎖機制，只允許一個請求發往後端。 - 語法：proxy_cache_lock on | off; - proxy_cache_lock_timeout：配置鎖超時機制，超出規定時間後會釋放請求。 - proxy_cache_lock_timeout time; - proxy_cache_methods：設定對於那些HTTP方法開啟快取。 - 語法：proxy_cache_methods method; - method為請求方法型別，如GET、HEAD等。 - proxy_no_cache：定義不儲存快取的條件，符合時不會儲存。 - 語法：proxy_no_cache string...; - string為條件，例如$cookie_nocache $arg_nocache $arg_comment; - proxy_cache_bypass：定義不讀取快取的條件，符合時不會從快取中讀取。 - 語法：proxy_cache_bypass string...; - 和上面proxy_no_cache的配置方法類似。 - add_header：往響應頭中新增欄位資訊。 - 語法：add_header fieldName fieldValue; - $upstream_cache_status：記錄了快取是否命中的資訊，存在多種情況： - MISS：請求未命中快取。 - HIT：請求命中快取。 - EXPIRED：請求命中快取但快取已過期。 - STALE：請求命中了陳舊快取。 - REVALIDDATED：Nginx驗證陳舊快取依然有效。 - UPDATING：命中的快取內容陳舊，但正在更新快取。 - BYPASS：響應結果是從原始伺服器獲取的。 - PS：這個和之前的不同，之前的都是引數項，這個是一個Nginx內建變數。

OK~，對於Nginx中的快取配置項大概瞭解後，接著來配置一下Nginx代理快取： ```shell http{ # 設定快取的目錄，並且記憶體中快取區名為hot_cache，大小為128m， # 三天未被訪問過的快取自動清楚，磁碟中快取的最大容量為2GB。 proxy_cache_path /soft/nginx/cache levels=1:2 keys_zone=hot_cache:128m inactive=3d max_size=2g;

server{
    location / {
        # 使用名為nginx_cache的快取空間
        proxy_cache hot_cache;
        # 對於200、206、304、301、302狀態碼的資料快取1天
        proxy_cache_valid 200 206 304 301 302 1d;
        # 對於其他狀態的資料快取30分鐘
        proxy_cache_valid any 30m;
        # 定義生成快取鍵的規則（請求的url+引數作為key）
        proxy_cache_key $host$uri$is_args$args;
        # 資源至少被重複訪問三次後再加入快取
        proxy_cache_min_uses 3;
        # 出現重複請求時，只讓一個去後端讀資料，其他的從快取中讀取
        proxy_cache_lock on;
        # 上面的鎖超時時間為3s，超過3s未獲取資料，其他請求直接去後端
        proxy_cache_lock_timeout 3s;
        # 對於請求引數或cookie中聲明瞭不快取的資料，不再加入快取
        proxy_no_cache $cookie_nocache $arg_nocache $arg_comment;
        # 在響應頭中新增一個快取是否命中的狀態（便於除錯）
        add_header Cache-status $upstream_cache_status;
    }
}

} ``` 接著來看一下效果，如下：
代理快取
第一次訪問時，因為還沒有請求過資源，所以快取中沒有資料，因此沒有命中快取。第二、三次，依舊沒有命中快取，直至第四次時才顯示命中，這是為什麼呢？因為在前面的快取配置中，我們配置了加入快取的最低條件為：資源至少要被請求三次以上才會加入快取。 這樣可以避免很多無效快取佔用空間。

快取清理

當快取過多時，如果不及時清理會導致磁碟空間被“吃光”，因此我們需要一套完善的快取清理機制去刪除快取，在之前的proxy_cache_path引數中有purger相關的選項，開啟後可以幫我們自動清理快取，但遺憾的是：purger系列引數只有商業版的NginxPlus才能使用，因此需要付費才可使用。

不過天無絕人之路，我們可以通過強大的第三方模組ngx_cache_purge來替代，先來安裝一下該外掛：
①首先去到Nginx的安裝目錄下，建立一個cache_purge目錄：
shell [[email protected]]# mkdir cache_purge && cd cache_purge

②通過wget指令從github上拉取安裝包的壓縮檔案並解壓： shell [[email protected]]# wget https://github.com/FRiCKLE/ngx_cache_purge/archive/2.3.tar.gz [[email protected]]# tar -xvzf 2.3.tar.gz

③再次去到之前Nginx的解壓目錄下： shell [root[email protected]]# cd /soft/nginx/nginx1.21.6

④重新構建一次Nginx，通過--add-module的指令新增剛剛的第三方模組： shell [[email protected]]# ./configure --prefix=/soft/nginx/ --add-module=/soft/nginx/cache_purge/ngx_cache_purge-2.3/

⑤重新根據剛剛構建的Nginx，再次編譯一下，但切記不要make install： shell [[email protected]]# make

⑥刪除之前Nginx的啟動檔案，不放心的也可以移動到其他位置： shell [[email protected]]# rm -rf /soft/nginx/sbin/nginx

⑦從生成的objs目錄中，重新複製一個Nginx的啟動檔案到原來的位置： shell [[email protected]]# cp objs/nginx /soft/nginx/sbin/nginx

至此，第三方快取清除模組ngx_cache_purge就安裝完成了，接下來稍微修改一下nginx.conf配置，再新增一條location規則：
shell location ~ /purge(/.*) { # 配置可以執行清除操作的IP（線上可以配置成內網機器） # allow 127.0.0.1; # 代表本機 allow all; # 代表允許任意IP清除快取 proxy_cache_purge $host$1$is_args$args; } 然後再重啟Nginx，接下來即可通過http://xxx/purge/xx的方式清除快取。

八、Nginx實現IP黑白名單

有時候往往有些需求，可能某些介面只能開放給對應的合作商，或者購買/接入API的合作伙伴，那麼此時就需要實現類似於IP白名單的功能。而有時候有些惡意攻擊者或爬蟲程式，被識別後需要禁止其再次訪問網站，因此也需要實現IP黑名單。那麼這些功能無需交由後端實現，可直接在Nginx中處理。

Nginx做黑白名單機制，主要是通過allow、deny配置項來實現： allow xxx.xxx.xxx.xxx; # 允許指定的IP訪問，可以用於實現白名單。 deny xxx.xxx.xxx.xxx; # 禁止指定的IP訪問，可以用於實現黑名單。

要同時遮蔽/開放多個IP訪問時，如果所有IP全部寫在nginx.conf檔案中定然是不顯示的，這種方式比較冗餘，那麼可以新建兩個檔案BlocksIP.conf、WhiteIP.conf： ```shell

--------黑名單：BlocksIP.conf---------

deny 192.177.12.222; # 遮蔽192.177.12.222訪問 deny 192.177.44.201; # 遮蔽192.177.44.201訪問 deny 127.0.0.0/8; # 遮蔽127.0.0.1到127.255.255.254網段中的所有IP訪問

--------白名單：WhiteIP.conf---------

allow 192.177.12.222; # 允許192.177.12.222訪問 allow 192.177.44.201; # 允許192.177.44.201訪問 allow 127.45.0.0/16; # 允許127.45.0.1到127.45.255.254網段中的所有IP訪問 deny all; # 除開上述IP外，其他IP全部禁止訪問分別將要禁止/開放的`IP`新增到對應的檔案後，可以再將這兩個檔案在`nginx.conf`中匯入：shell http{ # 遮蔽該檔案中的所有IP include /soft/nginx/IP/BlocksIP.conf; server{ location xxx { # 某一系列介面只開放給白名單中的IP include /soft/nginx/IP/blockip.conf; } } } `` 對於檔案具體在哪兒匯入，這個也並非隨意的，如果要整站遮蔽/開放就在http中匯入，如果只需要一個域名下遮蔽/開放就在sever中匯入，如果只需要針對於某一系列介面遮蔽/開放IP，那麼就在location`中匯入。

當然，上述只是最簡單的IP黑/白名單實現方式，同時也可以通過ngx_http_geo_module、ngx_http_geo_module第三方庫去實現（這種方式可以按地區、國家進行遮蔽，並且提供了IP庫）。

九、Nginx跨域配置

跨域問題在之前的單體架構開發中，其實是比較少見的問題，除非是需要接入第三方SDK時，才需要處理此問題。但隨著現在前後端分離、分散式架構的流行，跨域問題也成為了每個Java開發必須要懂得解決的一個問題。

跨域問題產生的原因

產生跨域問題的主要原因就在於同源策略，為了保證使用者資訊保安，防止惡意網站竊取資料，同源策略是必須的，否則cookie可以共享。由於http無狀態協議通常會藉助cookie來實現有狀態的資訊記錄，例如使用者的身份/密碼等，因此一旦cookie被共享，那麼會導致使用者的身份資訊被盜取。
同源策略主要是指三點相同，協議+域名+埠 相同的兩個請求，則可以被看做是同源的，但如果其中任意一點存在不同，則代表是兩個不同源的請求，同源策略會限制了不同源之間的資源互動。

Nginx解決跨域問題

弄明白了跨域問題的產生原因，接下來看看Nginx中又該如何解決跨域呢？其實比較簡單，在nginx.conf中稍微新增一點配置即可：
shell location / { # 允許跨域的請求，可以自定義變數$http_origin，*表示所有 add_header 'Access-Control-Allow-Origin' *; # 允許攜帶cookie請求 add_header 'Access-Control-Allow-Credentials' 'true'; # 允許跨域請求的方法：GET,POST,OPTIONS,PUT add_header 'Access-Control-Allow-Methods' 'GET,POST,OPTIONS,PUT'; # 允許請求時攜帶的頭部資訊，*表示所有 add_header 'Access-Control-Allow-Headers' *; # 允許傳送按段獲取資源的請求 add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range'; # 一定要有！！！否則Post請求無法進行跨域！ # 在傳送Post跨域請求前，會以Options方式傳送預檢請求，伺服器接受時才會正式請求 if ($request_method = 'OPTIONS') { add_header 'Access-Control-Max-Age' 1728000; add_header 'Content-Type' 'text/plain; charset=utf-8'; add_header 'Content-Length' 0; # 對於Options方式的請求返回204，表示接受跨域請求 return 204; } } 在nginx.conf檔案加上如上配置後，跨域請求即可生效了。

但如果後端是採用分散式架構開發的，有時候RPC呼叫也需要解決跨域問題，不然也同樣會出現無法跨域請求的異常，因此可以在你的後端專案中，通過繼承HandlerInterceptorAdapter類、實現WebMvcConfigurer介面、新增@CrossOrgin註解的方式實現介面之間的跨域配置。

十、Nginx防盜鏈設計

首先了解一下何謂盜鏈：盜鏈即是指外部網站引入當前網站的資源對外展示，來舉個簡單的例子理解：

好比桌布網站X站、Y站，X站是一點點去購買版權、簽約作者的方式，從而積累了海量的桌布素材，但Y站由於資金等各方面的原因，就直接通過<img src="X站/xxx.jpg" />這種方式照搬了X站的所有桌布資源，繼而提供給使用者下載。

那麼如果我們自己是這個X站的Boss，心中必然不爽，那麼此時又該如何遮蔽這類問題呢？那麼接下來要敘說的防盜鏈 登場了！

Nginx的防盜鏈機制實現，跟上篇文章《HTTP/HTTPS》中分析到的一個頭部欄位：Referer有關，該欄位主要描述了當前請求是從哪兒發出的，那麼在Nginx中就可獲取該值，然後判斷是否為本站的資源引用請求，如果不是則不允許訪問。Nginx中存在一個配置項為valid_referers，正好可以滿足前面的需求，語法如下：
- valid_referers none | blocked | server_names | string ...; - none：表示接受沒有Referer欄位的HTTP請求訪問。 - blocked：表示允許http://或https//以外的請求訪問。 - server_names：資源的白名單，這裡可以指定允許訪問的域名。 - string：可自定義字串，支配萬用字元、正則表示式寫法。

簡單瞭解語法後，接下來的實現如下：
```shell

在動靜分離的location中開啟防盜鏈機制

location ~ .*.(html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css){ # 最後面的值在上線前可配置為允許的域名地址 valid_referers blocked 192.168.12.129; if ($invalid_referer) { # 可以配置成返回一張禁止盜取的圖片 # rewrite ^/ http://xx.xx.com/NO.jpg; # 也可直接返回403 return 403; }

root   /soft/nginx/static_resources;
expires 7d;

} `` 根據上述中的內容配置後，就已經通過Nginx實現了最基本的防盜鏈機制，最後只需要額外重啟一下就好啦！當然，對於防盜鏈機制實現這塊，也有專門的第三方模組ngx_http_accesskey_module`實現了更為完善的設計，感興趣的小夥伴可以自行去看看。

PS：防盜鏈機制也無法解決爬蟲偽造referers資訊的這種方式抓取資料。

十一、Nginx大檔案傳輸配置

在傳輸大檔案時，client_max_body_size、client_header_timeout、proxy_read_timeout、proxy_send_timeout這四個引數值都可以根據自己專案的實際情況來配置。

上述配置僅是作為代理層需要配置的，因為最終客戶端傳輸檔案還是直接與後端進行互動，這裡只是把作為閘道器層的Nginx配置調高一點，調到能夠“容納大檔案”傳輸的程度。
當然，Nginx中也可以作為檔案伺服器使用，但需要用到一個專門的第三方模組nginx-upload-module，如果專案中檔案上傳的作用處不多，那麼建議可以通過Nginx搭建，畢竟可以節省一臺檔案伺服器資源。但如若檔案上傳/下載較為頻繁，那麼還是建議額外搭建檔案伺服器，並將上傳/下載功能交由後端處理。

十二、Nginx配置SLL證書

隨著越來越多的網站接入HTTPS，因此Nginx中僅配置HTTP還不夠，往往還需要監聽443埠的請求，但在上篇《HTTP/HTTPS》中談到過，HTTPS為了確保通訊安全，所以服務端需配置對應的數字證書，當專案使用Nginx作為閘道器時，那麼證書在Nginx中也需要配置，接下來簡單聊一下關於SSL證書配置過程： - ①先去CA機構或從雲控制檯中申請對應的SSL證書，稽核通過後下載Nginx版本的證書。 - ②下載數字證書後，完整的檔案總共有三個：.crt、.key、.pem： - .crt：數字證書檔案，.crt是.pem的拓展檔案，因此有些人下載後可能沒有。 - .key：伺服器的私鑰檔案，及非對稱加密的私鑰，用於解密公鑰傳輸的資料。 - .pem：Base64-encoded編碼格式的源證書文字檔案，可自行根需求修改拓展名。 - ③在Nginx目錄下新建certificate目錄，並將下載好的證書/私鑰等檔案上傳至該目錄。 - ④最後修改一下nginx.conf檔案即可，如下：

```shell

----------HTTPS配置-----------

server { # 監聽HTTPS預設的443埠 listen 443; # 配置自己專案的域名 server_name www.xxx.com; # 開啟SSL加密傳輸 ssl on; # 輸入域名後，首頁檔案所在的目錄 root html; # 配置首頁的檔名 index index.html index.htm index.jsp index.ftl; # 配置自己下載的數字證書 ssl_certificate certificate/xxx.pem; # 配置自己下載的伺服器私鑰 ssl_certificate_key certificate/xxx.key; # 停止通訊時，加密會話的有效期，在該時間段內不需要重新交換金鑰 ssl_session_timeout 5m; # TLS握手時，伺服器採用的密碼套件 ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4; # 伺服器支援的TLS版本 ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # 開啟由伺服器決定採用的密碼套件 ssl_prefer_server_ciphers on; location / { .... } }

---------HTTP請求轉HTTPS-------------

server { # 監聽HTTP預設的80埠 listen 80; # 如果80端口出現訪問該域名的請求 server_name www.xxx.com; # 將請求改寫為HTTPS（這裡寫你配置了HTTPS的域名） rewrite ^(.*)$ https://www.xxx.com; } `` OK~，根據如上配置了Nginx後，你的網站即可通過https://的方式訪問，並且當客戶端使用http://的方式訪問時，會自動將其改寫為HTTPS`請求。

十三、Nginx的高可用

線上如果採用單個節點的方式部署Nginx，難免會出現天災人禍，比如系統異常、程式宕機、伺服器斷電、機房爆炸、地球毀滅....哈哈哈，誇張了。但實際生產環境中確實存在隱患問題，由於Nginx作為整個系統的閘道器層接入外部流量，所以一旦Nginx宕機，最終就會導致整個系統不可用，這無疑對於使用者的體驗感是極差的，因此也得保障Nginx高可用的特性。

接下來則會通過keepalived的VIP機制，實現Nginx的高可用。
VIP並不是只會員的意思，而是指Virtual IP，即虛擬IP。

keepalived在之前單體架構開發時，是一個用的較為頻繁的高可用技術，比如MySQL、Redis、MQ、Proxy、Tomcat等各處都會通過keepalived提供的VIP機制，實現單節點應用的高可用。

Keepalived+重啟指令碼+雙機熱備搭建

①首先建立一個對應的目錄並下載keepalived安裝包（提取碼:s6aq）到Linux中並解壓： shell [[email protected]]# mkdir /soft/keepalived && cd /soft/keepalived [[email protected]]# wget https://www.keepalived.org/software/keepalived-2.2.4.tar.gz [[email protected]]# tar -zxvf keepalived-2.2.4.tar.gz

②進入解壓後的keepalived目錄並構建安裝環境，然後編譯並安裝： shell [[email protected]]# cd keepalived-2.2.4 [[email protected]]# ./configure --prefix=/soft/keepalived/ [[email protected]]# make && make install

③進入安裝目錄的/soft/keepalived/etc/keepalived/並編輯配置檔案： shell [[email protected]]# cd /soft/keepalived/etc/keepalived/ [[email protected]]# vi keepalived.conf

④編輯主機的keepalived.conf核心配置檔案，如下： ```shell global_defs { # 自帶的郵件提醒服務，建議用獨立的監控或第三方SMTP，也可選擇配置郵件傳送。 notification_email { [email protected] } notification_email_from [email protected] smtp_server localhost smtp_connect_timeout 30 # 高可用叢集主機身份標識(叢集中主機身份標識名稱不能重複，建議配置成本機IP) router_id 192.168.12.129 }

定時執行的指令碼檔案配置

vrrp_script check_nginx_pid_restart { # 之前編寫的nginx重啟指令碼的所在位置 script "/soft/scripts/keepalived/check_nginx_pid_restart.sh" # 每間隔3秒執行一次 interval 3 # 如果指令碼中的條件成立，重啟一次則權重-20 weight -20 }

定義虛擬路由，VI_1為虛擬路由的標示符（可自定義名稱）

vrrp_instance VI_1 { # 當前節點的身份標識：用來決定主從（MASTER為主機，BACKUP為從機） state MASTER # 繫結虛擬IP的網路介面，根據自己的機器的網絡卡配置 interface ens33 # 虛擬路由的ID號，主從兩個節點設定必須一樣 virtual_router_id 121 # 填寫本機IP mcast_src_ip 192.168.12.129 # 節點權重優先順序，主節點要比從節點優先順序高 priority 100 # 優先順序高的設定nopreempt，解決異常恢復後再次搶佔造成的腦裂問題 nopreempt # 組播資訊傳送間隔，兩個節點設定必須一樣，預設1s（類似於心跳檢測） advert_int 1 authentication { auth_type PASS auth_pass 1111 } # 將track_script塊加入instance配置塊 track_script { # 執行Nginx監控的指令碼 check_nginx_pid_restart }

virtual_ipaddress {
    # 虛擬IP(VIP)，也可擴充套件，可配置多個。
    192.168.12.111
}

} ```

⑤克隆一臺之前的虛擬機器作為從（備）機，編輯從機的keepalived.conf檔案，如下： ```shell global_defs { # 自帶的郵件提醒服務，建議用獨立的監控或第三方SMTP，也可選擇配置郵件傳送。 notification_email { [email protected] } notification_email_from [email protected] smtp_server localhost smtp_connect_timeout 30 # 高可用叢集主機身份標識(叢集中主機身份標識名稱不能重複，建議配置成本機IP) router_id 192.168.12.130 }

定時執行的指令碼檔案配置

定義虛擬路由，VI_1為虛擬路由的標示符（可自定義名稱）

vrrp_instance VI_1 { # 當前節點的身份標識：用來決定主從（MASTER為主機，BACKUP為從機） state BACKUP # 繫結虛擬IP的網路介面，根據自己的機器的網絡卡配置 interface ens33 # 虛擬路由的ID號，主從兩個節點設定必須一樣 virtual_router_id 121 # 填寫本機IP mcast_src_ip 192.168.12.130 # 節點權重優先順序，主節點要比從節點優先順序高 priority 90 # 優先順序高的設定nopreempt，解決異常恢復後再次搶佔造成的腦裂問題 nopreempt # 組播資訊傳送間隔，兩個節點設定必須一樣，預設1s（類似於心跳檢測） advert_int 1 authentication { auth_type PASS auth_pass 1111 } # 將track_script塊加入instance配置塊 track_script { # 執行Nginx監控的指令碼 check_nginx_pid_restart }

virtual_ipaddress {
    # 虛擬IP(VIP)，也可擴充套件，可配置多個。
    192.168.12.111
}

} ```

⑥新建scripts目錄並編寫Nginx的重啟指令碼，check_nginx_pid_restart.sh： ```shell [[email protected]]# mkdir /soft/scripts /soft/scripts/keepalived [[email protected]]# touch /soft/scripts/keepalived/check_nginx_pid_restart.sh [[email protected]]# vi /soft/scripts/keepalived/check_nginx_pid_restart.sh

!/bin/sh

通過ps指令查詢後臺的nginx程序數，並將其儲存在變數nginx_number中

nginx_number=ps -C nginx --no-header | wc -l

判斷後臺是否還有Nginx程序在執行

if [ nginx_number -eq 0 ];then # 如果後臺查詢不到Nginx程序存在，則執行重啟指令 /soft/nginx/sbin/nginx -c /soft/nginx/conf/nginx.conf # 重啟後等待1s後，再次查詢後臺程序數 sleep 1 # 如果重啟後依舊無法查詢到nginx程序 if [ ps -C nginx --no-header | wc -l -eq 0 ];then # 將keepalived主機下線，將虛擬IP漂移給從機，從機上線接管Nginx服務 systemctl stop keepalived.service fi fi ```

⑦編寫的指令碼檔案需要更改編碼格式，並賦予執行許可權，否則可能執行失敗： ```shell [[email protected]]# vi /soft/scripts/keepalived/check_nginx_pid_restart.sh

:set fileformat=unix # 在vi命令裡面執行，修改編碼格式 :set ff # 檢視修改後的編碼格式

[[email protected]]# chmod +x /soft/scripts/keepalived/check_nginx_pid_restart.sh ```

⑧由於安裝keepalived時，是自定義的安裝位置，因此需要拷貝一些檔案到系統目錄中： shell [[email protected]]# mkdir /etc/keepalived/ [[email protected]]# cp /soft/keepalived/etc/keepalived/keepalived.conf /etc/keepalived/ [[email protected]]# cp /soft/keepalived/keepalived-2.2.4/keepalived/etc/init.d/keepalived /etc/init.d/ [[email protected]]# cp /soft/keepalived/etc/sysconfig/keepalived /etc/sysconfig/

⑨將keepalived加入系統服務並設定開啟自啟動，然後測試啟動是否正常： ```shell [[email protected]]# chkconfig keepalived on [[email protected]]# systemctl daemon-reload [[email protected]]# systemctl enable keepalived.service [[email protected]]# systemctl start keepalived.service

其他命令： systemctl disable keepalived.service # 禁止開機自動啟動 systemctl restart keepalived.service # 重啟keepalived systemctl stop keepalived.service # 停止keepalived tail -f /var/log/messages # 檢視keepalived執行時日誌 ```

⑩最後測試一下VIP是否生效，通過檢視本機是否成功掛載虛擬IP： shell [[email protected]]# ip addr 虛擬IP-VIP

從上圖中可以明顯看見虛擬IP已經成功掛載，但另外一臺機器192.168.12.130並不會掛載這個虛擬IP，只有當主機下線後，作為從機的192.168.12.130才會上線，接替VIP。最後測試一下外網是否可以正常與VIP通訊，即在Windows中直接ping VIP：

Ping-VIP

外部通過VIP通訊時，也可以正常Ping通，代表虛擬IP配置成功。

Nginx高可用性測試

經過上述步驟後，keepalived的VIP機制已經搭建成功，在上個階段中主要做了幾件事： - 一、為部署Nginx的機器掛載了VIP。 - 二、通過keepalived搭建了主從雙機熱備。 - 三、通過keepalived實現了Nginx宕機重啟。

由於前面沒有域名的原因，因此最初server_name配置的是當前機器的IP，所以需稍微更改一下nginx.conf的配置： shell sever{ listen 80; # 這裡從機器的本地IP改為虛擬IP server_name 192.168.12.111; # 如果這裡配置的是域名，那麼則將域名的對映配置改為虛擬IP }

最後來實驗一下效果： Nginx宕機

在上述過程中，首先分別啟動了keepalived、nginx服務，然後通過手動停止nginx的方式模擬了Nginx宕機情況，過了片刻後再次查詢後臺程序，我們會發現nginx依舊存活。

從這個過程中不難發現，keepalived已經為我們實現了Nginx宕機後自動重啟的功能，那麼接著再模擬一下伺服器出現故障時的情況：
伺服器故障

在上述過程中，我們通過手動關閉keepalived服務模擬了機器斷電、硬體損壞等情況（因為機器斷電等情況=主機中的keepalived程序消失），然後再次查詢了一下本機的IP資訊，很明顯會看到VIP消失了！

現在再切換到另外一臺機器：192.168.12.130來看看情況： 130的IP情況

此刻我們會發現，在主機192.168.12.129宕機後，VIP自動從主機飄移到了從機192.168.12.130上，而此時客戶端的請求就最終會來到130這臺機器的Nginx上。

最終，利用Keepalived對Nginx做了主從熱備之後，無論是遇到線上宕機還是機房斷電等各類故障時，都能夠確保應用系統能夠為使用者提供7x24小時服務。

十四、Nginx效能優化

到這裡文章的篇幅較長了，最後再來聊一下關於Nginx的效能優化，主要就簡單說說收益最高的幾個優化項，在這塊就不再展開敘述了，畢竟影響效能都有多方面原因導致的，比如網路、伺服器硬體、作業系統、後端服務、程式自身、資料庫服務等，對於效能調優比較感興趣的可以參考之前《JVM效能調優》中的調優思想。

優化一：開啟長連線配置

通常Nginx作為代理服務，負責分發客戶端的請求，那麼建議開啟HTTP長連線，使用者減少握手的次數，降低伺服器損耗，具體如下：
shell upstream xxx { # 長連線數 keepalive 32; # 每個長連線提供的最大請求數 keepalived_requests 100; # 每個長連線沒有新的請求時，保持的最長時間 keepalive_timeout 60s; }

優化二、開啟零拷貝技術

零拷貝這個概念，在大多數效能較為不錯的中介軟體中都有出現，例如Kafka、Netty等，而Nginx中也可以配置資料零拷貝技術，如下：
shell sendfile on; # 開啟零拷貝機制 零拷貝讀取機制與傳統資源讀取機制的區別： - 傳統方式：硬體-->核心-->使用者空間-->程式空間-->程式核心空間-->網路套接字 - 零拷貝方式：硬體-->核心-->程式核心空間-->網路套接字

從上述這個過程對比，很輕易就能看出兩者之間的效能區別。

優化三、開啟無延遲或多包共發機制

在Nginx中有兩個較為關鍵的效能引數，即tcp_nodelay、tcp_nopush，開啟方式如下：
shell tcp_nodelay on; tcp_nopush on; TCP/IP協議中預設是採用了Nagle演算法的，即在網路資料傳輸過程中，每個資料報文並不會立馬傳送出去，而是會等待一段時間，將後面的幾個資料包一起組合成一個數據報文傳送，但這個演算法雖然提高了網路吞吐量，但是實時性卻降低了。

因此你的專案屬於互動性很強的應用，那麼可以手動開啟tcp_nodelay配置，讓應用程式向核心遞交的每個資料包都會立即傳送出去。但這樣會產生大量的TCP報文頭，增加很大的網路開銷。

相反，有些專案的業務對資料的實時性要求並不高，追求的則是更高的吞吐，那麼則可以開啟tcp_nopush配置項，這個配置就類似於“塞子”的意思，首先將連線塞住，使得資料先不發出去，等到拔去塞子後再發出去。設定該選項後，核心會盡量把小資料包拼接成一個大的資料包（一個MTU）再發送出去.

當然若一定時間後（一般為200ms），核心仍然沒有積累到一個MTU的量時，也必須傳送現有的資料，否則會一直阻塞。

tcp_nodelay、tcp_nopush兩個引數是“互斥”的，如果追求響應速度的應用推薦開啟tcp_nodelay引數，如IM、金融等型別的專案。如果追求吞吐量的應用則建議開啟tcp_nopush引數，如排程系統、報表系統等。

注意：
①tcp_nodelay一般要建立在開啟了長連線模式的情況下使用。
②tcp_nopush引數是必須要開啟sendfile引數才可使用的。

優化四、調整Worker工作程序

Nginx啟動後預設只會開啟一個Worker工作程序處理客戶端請求，而我們可以根據機器的CPU核數開啟對應數量的工作程序，以此來提升整體的併發量支援，如下：
```shell

自動根據CPU核心數調整Worker程序數量

worker_processes auto; ```

工作程序的數量最高開到8個就OK了，8個之後就不會有再大的效能提升。

同時也可以稍微調整一下每個工作程序能夠開啟的檔案控制代碼數：
```shell

每個Worker能開啟的檔案描述符，最少調整至1W以上，負荷較高建議2-3W

worker_rlimit_nofile 20000; ```

作業系統核心（kernel）都是利用檔案描述符來訪問檔案，無論是開啟、新建、讀取、寫入檔案時，都需要使用檔案描述符來指定待操作的檔案，因此該值越大，代表一個程序能夠操作的檔案越多（但不能超出核心限制，最多建議3.8W左右為上限）。

優化五、開啟CPU親和機制

對於併發程式設計較為熟悉的夥伴都知道，因為程序/執行緒數往往都會遠超出系統CPU的核心數，因為作業系統執行的原理本質上是採用時間片切換機制，也就是一個CPU核心會在多個程序之間不斷頻繁切換，造成很大的效能損耗。

而CPU親和機制則是指將每個Nginx的工作程序，繫結在固定的CPU核心上，從而減小CPU切換帶來的時間開銷和資源損耗，開啟方式如下：
shell worker_cpu_affinity auto;

優化六、開啟epoll模型及調整併發連線數

在最開始就提到過：Nginx、Redis都是基於多路複用模型去實現的程式，但最初版的多路複用模型select/poll最大隻能監聽1024個連線，而epoll則屬於select/poll介面的增強版，因此採用該模型能夠大程度上提升單個Worker的效能，如下： shell events { # 使用epoll網路模型 use epoll; # 調整每個Worker能夠處理的連線數上限 worker_connections 10240; }

這裡對於select/poll/epoll模型就不展開細說了，後面的IO模型文章中會詳細剖析。

十五、放在最後的結尾

至此，Nginx的大部分內容都已闡述完畢，關於最後一小節的效能優化內容，其實在前面就談到的動靜分離、分配緩衝區、資源快取、防盜鏈、資源壓縮等內容，也都可歸納為效能優化的方案。

最後，希望諸君收藏的同時不要忘了點個贊支援一下^_^，在此萬分感謝！

(三)Nginx一網打盡：動靜分離、壓縮、快取、黑白名單、跨域、高可用、效能優化...想要的這都有！

引言

一、效能怪獸-Nginx概念深入淺出

二、Nginx環境搭建

三、Nginx反向代理-負載均衡

Nginx請求分發原理

四、Nginx動靜分離

五、Nginx資源壓縮

六、Nginx緩衝區

七、Nginx快取機制

快取清理

八、Nginx實現IP黑白名單

--------黑名單：BlocksIP.conf---------

--------白名單：WhiteIP.conf---------

九、Nginx跨域配置

跨域問題產生的原因

Nginx解決跨域問題

十、Nginx防盜鏈設計

在動靜分離的location中開啟防盜鏈機制

十一、Nginx大檔案傳輸配置

十二、Nginx配置SLL證書

----------HTTPS配置-----------

---------HTTP請求轉HTTPS-------------

十三、Nginx的高可用

Keepalived+重啟指令碼+雙機熱備搭建

定時執行的指令碼檔案配置

定義虛擬路由，VI_1為虛擬路由的標示符（可自定義名稱）

定時執行的指令碼檔案配置

定義虛擬路由，VI_1為虛擬路由的標示符（可自定義名稱）

!/bin/sh

通過ps指令查詢後臺的nginx程序數，並將其儲存在變數nginx_number中

判斷後臺是否還有Nginx程序在執行

Nginx高可用性測試

十四、Nginx效能優化

優化一：開啟長連線配置

優化二、開啟零拷貝技術

優化三、開啟無延遲或多包共發機制

優化四、調整Worker工作程序

自動根據CPU核心數調整Worker程序數量

每個Worker能開啟的檔案描述符，最少調整至1W以上，負荷較高建議2-3W

優化五、開啟CPU親和機制

優化六、開啟epoll模型及調整併發連線數

十五、放在最後的結尾