寫給高級前端的 Nginx 知識，一網打盡！！

引言

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

❝

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

❞

因此在這種背景下，引入負載均衡技術可帶來的收益：

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

❞

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

Nginx是目前負載均衡技術中的主流方案，幾乎絕大部分項目都會使用它，Nginx是一個輕量級的高性能HTTP反向代理服務器，同時它也是一個通用類型的代理服務器，支持絕大部分協議，如TCP、UDP、SMTP、HTTPS等。

Nginx與 Redis 相同，都是基於多路複用模型構建出的產物，因此它與Redis同樣具備 「「資源佔用少、併發支持高」」 的特點，在理論上單節點的Nginx同時支持5W併發連接，而實際生產環境中，硬件基礎到位再結合簡單調優後確實能達到該數值。

先來看看Nginx引入前後，客戶端請求處理流程的對比：

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

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

二、Nginx 環境搭建

❶首先創建Nginx的目錄並進入：

[root@localhost]# mkdir /soft && mkdir /soft/nginx/  
[root@localhost]# cd /soft/nginx/

❷下載Nginx的安裝包，可以通過FTP工具上傳離線環境包，也可通過wget命令在線獲取安裝包：

[root@localhost]# wget https://nginx.org/download/nginx-1.21.6.tar.gz

沒有wget命令的可通過yum命令安裝：

[root@localhost]# yum -y install wget

❸解壓Nginx的壓縮包：

[root@localhost]# tar -xvzf nginx-1.21.6.tar.gz

❹下載並安裝Nginx所需的依賴庫和包：

[root@localhost]# yum install --downloadonly --downloaddir=/soft/nginx/ gcc-c++  
[root@localhost]# yum install --downloadonly --downloaddir=/soft/nginx/ pcre pcre-devel4  
[root@localhost]# yum install --downloadonly --downloaddir=/soft/nginx/ zlib zlib-devel  
[root@localhost]# yum install --downloadonly --downloaddir=/soft/nginx/ openssl openssl-devel

也可以通過yum命令一鍵下載（推薦上面哪種方式）：

[root@localhost]# yum -y install gcc zlib zlib-devel pcre-devel openssl openssl-devel

執行完成後，然後ls查看目錄文件，會看一大堆依賴：

緊接着通過rpm命令依次將依賴包一個個構建，或者通過如下指令一鍵安裝所有依賴包：

[root@localhost]# rpm -ivh --nodeps *.rpm

❺進入解壓後的nginx目錄，然後執行Nginx的配置腳本，爲後續的安裝提前配置好環境，默認位於/usr/local/nginx/目錄下（可自定義目錄）：

[root@localhost]# cd nginx-1.21.6  
[root@localhost]# ./configure --prefix=/soft/nginx/

❻編譯並安裝Nginx：

[root@localhost]# make && make install

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

❽修改安裝後生成的conf目錄下的nginx.conf配置文件：

[root@localhost]# vi conf/nginx.conf  
    修改端口號：listen    80;  
 修改IP地址：server_name  你當前機器的本地IP(線上配置域名);

❾制定配置文件並啓動Nginx：

[root@localhost]# sbin/nginx -c conf/nginx.conf  
[root@localhost]# ps aux | grep nginx

Nginx其他操作命令：

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端口，並更新防火牆：

[root@localhost]# firewall-cmd --zone=public --add-port=80/tcp --permanent  
[root@localhost]# firewall-cmd --reload  
[root@localhost]# firewall-cmd --zone=public --list-ports

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

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

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

首先通過SpringBoot+Freemarker快速搭建一個WEB項目：springboot-web-nginx，然後在該項目中，創建一個IndexNginxController.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>  
    <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的配置即可：

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 動靜分離

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

淘寶首頁

當瀏覽器輸入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匹配規則：

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爲後綴的所有資源請求。

「最後提一嘴，也可以將靜態資源上傳到文件服務器中，然後**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中簡單配置一下：

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選項，可以根據系統的實際情況決定，總共存在多種選項：

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

<script type="text/javascript" src="jquery-3.6.0.js"></script>

分別來對比下壓縮前後的區別：

從圖中可以很明顯看出，未開啓壓縮機制前訪問時，js文件的原始大小爲230K，當配置好壓縮後再重啓Nginx，會發現文件大小從230KB→69KB，效果立竿見影！

❝

注意點：①對於圖片、視頻類型的數據，會默認開啓壓縮機制，因此一般無需再次開啓壓縮。②對於.js文件而言，需要指定壓縮類型爲application/javascript，而並非text/javascript、application/x-javascript。

❞

六、Nginx 緩衝區

先來思考一個問題，接入Nginx的項目一般請求流程爲：“客戶端→Nginx→服務端”，在這個過程中存在兩個連接：“客戶端→Nginx、Nginx→服務端”，那麼兩個不同的連接速度不一致，就會影響用戶的體驗（比如瀏覽器的加載速度跟不上服務端的響應速度）。

其實也就類似電腦的內存跟不上CPU速度，所以對於用戶造成的體驗感極差，因此在CPU設計時都會加入三級高速緩衝區，用於緩解CPU和內存速率不一致的矛盾。在Nginx也同樣存在緩衝區的機制，主要目的就在於：「「用來解決兩個連接之間速度不匹配造成的問題」」 ，有了緩衝後，Nginx代理可暫存後端的響應，然後按需供給數據給客戶端。先來看看一些關於緩衝區的配置項：

具體的nginx.conf配置如下：

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];

是的，你沒有看錯，就是這麼長....，解釋一下每個參數項的含義：

「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」：記錄了緩存是否命中的信息，存在多種情況：

❝

PS：這個和之前的不同，之前的都是參數項，這個是一個 Nginx 內置變量。

❞

OK~，對於Nginx中的緩存配置項大概瞭解後，接着來配置一下Nginx代理緩存：

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目錄：

[root@localhost]# mkdir cache_purge && cd cache_purge

②通過wget指令從github上拉取安裝包的壓縮文件並解壓：

[root@localhost]# wget https://github.com/FRiCKLE/ngx_cache_purge/archive/2.3.tar.gz  
[root@localhost]# tar -xvzf 2.3.tar.gz

③再次去到之前Nginx的解壓目錄下：

[root@localhost]# cd /soft/nginx/nginx1.21.6

④重新構建一次Nginx，通過--add-module的指令添加剛剛的第三方模塊：

[root@localhost]# ./configure --prefix=/soft/nginx/ --add-module=/soft/nginx/cache_purge/ngx_cache_purge-2.3/

⑤重新根據剛剛構建的Nginx，再次編譯一下，「但切記不要****make install」 ：

[root@localhost]# make

⑥刪除之前Nginx的啓動文件，不放心的也可以移動到其他位置：

[root@localhost]# rm -rf /soft/nginx/sbin/nginx

⑦從生成的objs目錄中，重新複製一個Nginx的啓動文件到原來的位置：

[root@localhost]# cp objs/nginx /soft/nginx/sbin/nginx

至此，第三方緩存清除模塊ngx_cache_purge就安裝完成了，接下來稍微修改一下nginx.conf配置，再添加一條location規則：

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：

# --------黑名單：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中導入：

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中稍微添加一點配置即可：

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的防盜鏈機制實現，跟一個頭部字段：Referer有關，該字段主要描述了當前請求是從哪兒發出的，那麼在Nginx中就可獲取該值，然後判斷是否爲本站的資源引用請求，如果不是則不允許訪問。Nginx中存在一個配置項爲valid_referers，正好可以滿足前面的需求，語法如下：

valid_referers none | blocked | server_names | string ...;

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

# 在動靜分離的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 大文件傳輸配置

在某些業務場景中需要傳輸一些大文件，但大文件傳輸時往往都會會出現一些Bug，比如文件超出限制、文件傳輸過程中請求超時等，那麼此時就可以在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端口的請求，HTTPS爲了確保通信安全，所以服務端需配置對應的數字證書，當項目使用Nginx作爲網關時，那麼證書在Nginx中也需要配置，接下來簡單聊一下關於SSL證書配置過程：

①先去 CA 機構或從雲控制檯中申請對應的SSL證書，審覈通過後下載Nginx版本的證書。

②下載數字證書後，完整的文件總共有三個：.crt、.key、.pem：

③在Nginx目錄下新建certificate目錄，並將下載好的證書 / 私鑰等文件上傳至該目錄。

④最後修改一下nginx.conf文件即可，如下：

# ----------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到Linux中並解壓：

[root@localhost]# mkdir /soft/keepalived && cd /soft/keepalived  
[root@localhost]# wget https://www.keepalived.org/software/keepalived-2.2.4.tar.gz  
[root@localhost]# tar -zxvf keepalived-2.2.4.tar.gz

②進入解壓後的keepalived目錄並構建安裝環境，然後編譯並安裝：

[root@localhost]# cd keepalived-2.2.4  
[root@localhost]# ./configure --prefix=/soft/keepalived/  
[root@localhost]# make && make install

③進入安裝目錄的/soft/keepalived/etc/keepalived/並編輯配置文件：

[root@localhost]# cd /soft/keepalived/etc/keepalived/  
[root@localhost]# vi keepalived.conf

④編輯主機的keepalived.conf核心配置文件，如下：

global_defs {  
    # 自帶的郵件提醒服務，建議用獨立的監控或第三方SMTP，也可選擇配置郵件發送。  
    notification_email {  
        root@localhost  
    }  
    notification_email_from root@localhost  
    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文件，如下：

global_defs {  
    # 自帶的郵件提醒服務，建議用獨立的監控或第三方SMTP，也可選擇配置郵件發送。  
    notification_email {  
        root@localhost  
    }  
    notification_email_from root@localhost  
    smtp_server localhost  
    smtp_connect_timeout 30  
    # 高可用集羣主機身份標識(集羣中主機身份標識名稱不能重複，建議配置成本機IP)  
 router_id 192.168.12.130   
}  
  
# 定時運行的腳本文件配置  
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 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：

[root@localhost]# mkdir /soft/scripts /soft/scripts/keepalived  
[root@localhost]# touch /soft/scripts/keepalived/check_nginx_pid_restart.sh  
[root@localhost]# 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

⑦編寫的腳本文件需要更改編碼格式，並賦予執行權限，否則可能執行失敗：

[root@localhost]# vi /soft/scripts/keepalived/check_nginx_pid_restart.sh  
  
:set fileformat=unix # 在vi命令裏面執行，修改編碼格式  
:set ff # 查看修改後的編碼格式  
  
[root@localhost]# chmod +x /soft/scripts/keepalived/check_nginx_pid_restart.sh

⑧由於安裝keepalived時，是自定義的安裝位置，因此需要拷貝一些文件到系統目錄中：

[root@localhost]# mkdir /etc/keepalived/  
[root@localhost]# cp /soft/keepalived/etc/keepalived/keepalived.conf /etc/keepalived/  
[root@localhost]# cp /soft/keepalived/keepalived-2.2.4/keepalived/etc/init.d/keepalived /etc/init.d/  
[root@localhost]# cp /soft/keepalived/etc/sysconfig/keepalived /etc/sysconfig/

⑨將keepalived加入系統服務並設置開啓自啓動，然後測試啓動是否正常：

[root@localhost]# chkconfig keepalived on  
[root@localhost]# systemctl daemon-reload  
[root@localhost]# systemctl enable keepalived.service  
[root@localhost]# 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：

[root@localhost]# 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機制已經搭建成功，在上個階段中主要做了幾件事：

由於前面沒有域名的原因，因此最初server_name配置的是當前機器的IP，所以需稍微更改一下nginx.conf的配置：

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的性能優化，主要就簡單說說收益最高的幾個優化項，在這塊就不再展開敘述了，畢竟影響性能都有多方面原因導致的，比如網絡、服務器硬件、操作系統、後端服務、程序自身、數據庫服務等。

優化一：打開長連接配置

通常 Nginx 作爲代理服務，負責分發客戶端的請求，那麼建議開啓HTTP長連接，用戶減少握手的次數，降低服務器損耗，具體如下：

upstream xxx {  
    # 長連接數  
    keepalive 32;  
    # 每個長連接提供的最大請求數  
    keepalived_requests 100;  
    # 每個長連接沒有新的請求時，保持的最長時間  
    keepalive_timeout 60s;  
}

優化二、開啓零拷貝技術

零拷貝這個概念，在大多數性能較爲不錯的中間件中都有出現，例如Kafka、Netty等，而Nginx中也可以配置數據零拷貝技術，如下：

sendfile on; # 開啓零拷貝機制

零拷貝讀取機制與傳統資源讀取機制的區別：

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

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

在Nginx中有兩個較爲關鍵的性能參數，即tcp_nodelay、tcp_nopush，開啓方式如下：

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 核數開啓對應數量的工作進程，以此來提升整體的併發量支持，如下：

# 自動根據CPU核心數調整Worker進程數量  
worker_processes auto;

❝

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

❞

同時也可以稍微調整一下每個工作進程能夠打開的文件句柄數：

# 每個Worker能打開的文件描述符，最少調整至1W以上，負荷較高建議2-3W  
worker_rlimit_nofile 20000;

❝

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

❞

優化五、開啓 CPU 親和機制

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

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

worker_cpu_affinity auto;

優化六、開啓 epoll 模型及調整併發連接數

在最開始就提到過：Nginx、Redis都是基於多路複用模型去實現的程序，但最初版的多路複用模型select/poll最大隻能監聽1024個連接，而epoll則屬於select/poll接口的增強版，因此採用該模型能夠大程度上提升單個Worker的性能，如下：

events {  
    # 使用epoll網絡模型  
    use epoll;  
    # 調整每個Worker能夠處理的連接數上限  
    worker_connections  10240;  
}

❝

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

❞

十五、放在最後的結尾

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

作者：竹子愛熊貓

來源：juejin.cn/post/711282665429191885

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/36eKvucS-OaP1L4OGpJmVA

猜你喜歡