引言

《HTTP/HTTPS》中曾談到了代理服務器的概念捌刮，其主要作用之一就是用于負載均衡與請求分發(fā)，那么先來看看為何需要做請求負載舒岸。

早期的業(yè)務都是基于單體節(jié)點部署绅作，由于前期訪問流量不大，因此單體結(jié)構也可滿足需求蛾派，但隨著業(yè)務增長俄认，流量也越來越大个少，那么最終單臺服務器受到的訪問壓力也會逐步增高。時間一長眯杏，單臺服務器性能無法跟上業(yè)務增長夜焦，就會造成線上頻繁宕機的現(xiàn)象發(fā)生，最終導致系統(tǒng)癱瘓無法繼續(xù)處理用戶的請求岂贩。

從上面的描述中茫经，主要存在兩個問題：
①單體結(jié)構的部署方式無法承載日益增長的業(yè)務流量。
②當后端節(jié)點宕機后萎津，整個系統(tǒng)會陷入癱瘓卸伞，導致整個項目不可用。

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

• 系統(tǒng)的高可用：當某個節(jié)點宕機后可以迅速將流量轉(zhuǎn)移至其他節(jié)點荤傲。
• 系統(tǒng)的高性能：多臺服務器共同對外提供服務，為整個系統(tǒng)提供了更高規(guī)模的吞吐部念。
• 系統(tǒng)的拓展性：當業(yè)務再次出現(xiàn)增長或萎靡時弃酌，可再加入/減少節(jié)點，靈活伸縮儡炼。

OK~，既然引入負載均衡技術可給我們帶來如此巨大的好處查蓉，那么又有那些方案可供選擇呢乌询？主要有兩種負載方案，硬件層面與軟件層面豌研，比較常用的硬件負載器有A10妹田、F5等，但這些機器動輒大幾萬乃至幾十萬的成本鹃共，因此一般大型企業(yè)會采用該方案鬼佣，如銀行、國企霜浴、央企等晶衷。
而成本有限，但依舊想做負載均衡的項目阴孟，那么可在軟件層面實現(xiàn)晌纫，如典型的Nginx等，軟件層的負載也是本文的重點永丝，畢竟Boss們的準則之一就是：能靠技術實現(xiàn)的就盡量不花錢锹漱。

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

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

Nginx是目前負載均衡技術中的主流方案懈词，幾乎絕大部分項目都會使用它，Nginx是一個輕量級的高性能HTTP反向代理服務器辩诞，同時它也是一個通用類型的代理服務器坎弯，支持絕大部分協(xié)議，如TCP译暂、UDP抠忘、SMTP、HTTPS等外永。

image

Nginx與之前談及的《Redis》相同崎脉，都是基于多路復用模型構建出的產(chǎn)物，因此它與Redis同樣具備資源占用少伯顶、并發(fā)支持高的特點囚灼，在理論上單節(jié)點的Nginx同時支持5W并發(fā)連接，而實際生產(chǎn)環(huán)境中祭衩，硬件基礎到位再結(jié)合簡單調(diào)優(yōu)后確實能達到該數(shù)值灶体。

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

image

原本客戶端是直接請求目標服務器掐暮，由目標服務器直接完成請求處理工作蝎抽，但加入Nginx后，所有的請求會先經(jīng)過Nginx路克，再由其進行分發(fā)到具體的服務器處理樟结，處理完成后再返回Nginx，最后由Nginx將最終的響應結(jié)果返回給客戶端精算。

了解了Nginx的基本概念后瓢宦，再來快速搭建一下環(huán)境，以及了解一些Nginx的高級特性灰羽，如動靜分離驮履、資源壓縮、緩存配置谦趣、IP黑名單疲吸、高可用保障等。

二前鹅、Nginx環(huán)境搭建

?首先創(chuàng)建Nginx的目錄并進入：

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

?下載Nginx的安裝包摘悴，可以通過FTP工具上傳離線環(huán)境包候引，也可通過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

執(zhí)行完成后静浴，然后ls查看目錄文件，會看一大堆依賴：

image

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

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

?進入解壓后的nginx目錄络凿，然后執(zhí)行Nginx的配置腳本算色，為后續(xù)的安裝提前配置好環(huán)境怎囚，默認位于/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 # 優(yōu)雅關閉Nginx蔓彩，會在執(zhí)行完當前的任務后再退出
sbin/nginx -s stop # 強制終止Nginx治笨，不管當前是否有任務在執(zhí)行

?開放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：

image

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

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

首先通過SpringBoot+Freemarker快速搭建一個WEB項目：springboot-web-nginx等孵，然后在該項目中，創(chuàng)建一個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值上枕。當出現(xiàn)訪問/資源的請求時咐熙，跳轉(zhuǎn)前端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內(nèi)檢查心跳發(fā)送兩次包，未回復就代表該機器宕機并扇，請求分發(fā)權重比為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鞋吉。

最終來看看效果：

image

因為配置了請求分發(fā)的權重，8080励烦、8090的權重比為2:1谓着，因此請求會根據(jù)權重比均攤到每臺機器，也就是8080一次坛掠、8090兩次赊锚、8080一次......

Nginx請求分發(fā)原理

客戶端發(fā)出的請求192.168.12.129最終會轉(zhuǎn)變?yōu)椋?code>http://192.168.12.129:80/，然后再向目標IP發(fā)起請求屉栓，流程如下：

image

• 由于Nginx監(jiān)聽了192.168.12.129的80端口舷蒲，所以最終該請求會找到Nginx進程；
• Nginx首先會根據(jù)配置的location規(guī)則進行匹配系瓢，根據(jù)客戶端的請求路徑/阿纤，會定位到location /{}規(guī)則；
• 然后根據(jù)該location中配置的proxy_pass會再找到名為nginx_boot的upstream夷陋；
• 最后根據(jù)upstream中的配置信息欠拾，將請求轉(zhuǎn)發(fā)到運行WEB服務的機器處理，由于配置了多個WEB服務骗绕，且配置了權重值藐窄，因此Nginx會依次根據(jù)權重比分發(fā)請求。

四酬土、Nginx動靜分離

動靜分離應該是聽的次數(shù)較多的性能優(yōu)化方案荆忍，那先思考一個問題：為什么需要做動靜分離呢？它帶來的好處是什么撤缴？ 其實這個問題也并不難回答刹枉，當你搞懂了網(wǎng)站的本質(zhì)后，自然就理解了動靜分離的重要性屈呕。先來以淘寶為例分析看看：

image

當瀏覽器輸入www.taobao.com訪問淘寶首頁時微宝，打開開發(fā)者調(diào)試工具可以很明顯的看到，首頁加載會出現(xiàn)100+的請求數(shù)虎眨，而正常項目開發(fā)時蟋软，靜態(tài)資源一般會放入到resources/static/目錄下：

image

在項目上線部署時，這些靜態(tài)資源會一起打成包嗽桩，那此時思考一個問題：假設淘寶也是這樣干的岳守，那么首頁加載時的請求最終會去到哪兒被處理？ 答案毋庸置疑碌冶，首頁100+的所有請求都會來到部署WEB服務的機器處理湿痢，那則代表著一個客戶端請求淘寶首頁，就會對后端服務器造成100+的并發(fā)請求种樱。毫無疑問蒙袍，這對于后端服務器的壓力是尤為巨大的俊卤。

但此時不妨分析看看，首頁100+的請求中害幅，是不是至少有60+是屬于*.js消恍、*.css、*.html以现、*.jpg.....這類靜態(tài)資源的請求呢狠怨？答案是Yes。

既然有這么多請求屬于靜態(tài)的邑遏，這些資源大概率情況下佣赖，長時間也不會出現(xiàn)變動，那為何還要讓這些請求到后端再處理呢记盒？能不能在此之前就提前處理掉憎蛤？當然OK，因此經(jīng)過分析之后能夠明確一點：做了動靜分離之后纪吮，至少能夠讓后端服務減少一半以上的并發(fā)量俩檬。 到此時大家應該明白了動靜分離能夠帶來的性能收益究竟有多大。

OK~碾盟，搞清楚動靜分離的必要性之后棚辽，如何實現(xiàn)動靜分離呢？其實非常簡單冰肴，實戰(zhàn)看看屈藐。

①先在部署Nginx的機器，Nginx目錄下創(chuàng)建一個目錄static_resources：

mkdir static_resources

②將項目中所有的靜態(tài)資源全部拷貝到該目錄下熙尉，而后將項目中的靜態(tài)資源移除重新打包联逻。

③稍微修改一下nginx.conf的配置，增加一條location匹配規(guī)則：

location ~ .*\.(html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css){
    root   /soft/nginx/static_resources;
    expires 7d;
}

然后照常啟動nginx和移除了靜態(tài)資源的WEB服務检痰，你會發(fā)現(xiàn)原本的樣式遣妥、js效果、圖片等依舊有效攀细，如下：

image

其中static目錄下的nginx_style.css文件已被移除，但效果依舊存在（綠色字體+藍色大邊框）：

image

最后解讀一下那條location規(guī)則：
location ~ .*\.(html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css)
~代表匹配時區(qū)分大小寫
.*代表任意字符都可以出現(xiàn)零次或多次爱态，即資源名不限制
\.代表匹配后綴分隔符.
(html|...|css)代表匹配括號里所有靜態(tài)資源類型
綜上所述谭贪，簡單一句話概述：該配置表示匹配以.html~.css為后綴的所有資源請求。

最后提一嘴锦担，也可以將靜態(tài)資源上傳到文件服務器中俭识，然后location中配置一個新的upstream指向。

五洞渔、Nginx資源壓縮

建立在動靜分離的基礎之上套媚，如果一個靜態(tài)資源的Size越小缚态，那么自然傳輸速度會更快，同時也會更節(jié)省帶寬堤瘤，因此我們在部署項目時玫芦，也可以通過Nginx對于靜態(tài)資源實現(xiàn)壓縮傳輸，一方面可以節(jié)省帶寬資源本辐，第二方面也可以加快響應速度并提升系統(tǒng)整體吞吐桥帆。

在Nginx也提供了三個支持資源壓縮的模塊ngx_http_gzip_module、ngx_http_gzip_static_module慎皱、ngx_http_gunzip_module老虫，其中ngx_http_gzip_module屬于內(nèi)置模塊，代表著可以直接使用該模塊下的一些壓縮指令茫多，后續(xù)的資源壓縮操作都基于該模塊祈匙，先來看看壓縮配置的一些參數(shù)/指令：

了解了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;
    # 處理壓縮請求的緩沖區(qū)數(shù)量和大小
    gzip_buffers 16 8k;
    # 對于不支持壓縮功能的客戶端請求不開啟壓縮機制
    gzip_disable "MSIE [1-6]\."; # 低版本的IE瀏覽器不支持壓縮
    # 設置壓縮響應所支持的HTTP最低版本
    gzip_http_version 1.1;
    # 設置觸發(fā)壓縮的最小閾值
    gzip_min_length 2k;
    # 關閉對后端服務器的響應結(jié)果進行壓縮
    gzip_proxied off;
}

在上述的壓縮配置中扑眉，最后一個gzip_proxied選項，可以根據(jù)系統(tǒng)的實際情況決定赖钞，總共存在多種選項：

• off：關閉Nginx對后臺服務器的響應結(jié)果進行壓縮腰素。
• 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：無條件對后端的響應結(jié)果開啟壓縮機制食绿。

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

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

分別來對比下壓縮前后的區(qū)別：

image

從圖中可以很明顯看出器紧，未開啟壓縮機制前訪問時耀销，js文件的原始大小為230K，當配置好壓縮后再重啟Nginx品洛，會發(fā)現(xiàn)文件大小從230KB→69KB树姨，效果立竿見影！

注意點：
①對于圖片桥状、視頻類型的數(shù)據(jù)帽揪，會默認開啟壓縮機制，因此一般無需再次開啟壓縮辅斟。
②對于.js文件而言转晰，需要指定壓縮類型為application/javascript，而并非text/javascript士飒、application/x-javascript查邢。

六、Nginx緩沖區(qū)

先來思考一個問題酵幕，接入Nginx的項目一般請求流程為：“客戶端→Nginx→服務端”扰藕，在這個過程中存在兩個連接：“客戶端→Nginx、Nginx→服務端”芳撒，那么兩個不同的連接速度不一致邓深，就會影響用戶的體驗（比如瀏覽器的加載速度跟不上服務端的響應速度）。
其實也就類似電腦的內(nèi)存跟不上CPU速度笔刹，所以對于用戶造成的體驗感極差芥备，因此在CPU設計時都會加入三級高速緩沖區(qū)，用于緩解CPU和內(nèi)存速率不一致的矛盾舌菜。在Nginx也同樣存在緩沖區(qū)的機制萌壳，主要目的就在于：用來解決兩個連接之間速度不匹配造成的問題，有了緩沖后日月，Nginx代理可暫存后端的響應袱瓮，然后按需供給數(shù)據(jù)給客戶端。先來看看一些關于緩沖區(qū)的配置項：

• proxy_buffering：是否啟用緩沖機制爱咬，默認為on關閉狀態(tài)懂讯。
• client_body_buffer_size：設置緩沖客戶端請求數(shù)據(jù)的內(nèi)存大小。
• proxy_buffers：為每個請求/連接設置緩沖區(qū)的數(shù)量和大小台颠，默認4 4k/8k。
• proxy_buffer_size：設置用于存儲響應頭的緩沖區(qū)大小。
• proxy_busy_buffers_size：在后端數(shù)據(jù)沒有完全接收完成時串前，Nginx可以將busy狀態(tài)的緩沖返回給客戶端瘫里，該參數(shù)用來設置busy狀態(tài)的buffer具體有多大，默認為proxy_buffer_size*2荡碾。
• proxy_temp_path：當內(nèi)存緩沖區(qū)存滿時谨读，可以將數(shù)據(jù)臨時存放到磁盤，該參數(shù)是設置存儲緩沖數(shù)據(jù)的目錄坛吁。
  • 語法：proxy_temp_path path;
    • path是臨時目錄的路徑劳殖。
• proxy_temp_file_write_size：設置每次寫數(shù)據(jù)到臨時文件的大小限制。
• proxy_max_temp_file_size：設置臨時的緩沖目錄中允許存儲的最大容量拨脉。
• 非緩沖參數(shù)項：
  • proxy_connect_timeout：設置與后端服務器建立連接時的超時時間哆姻。
  • proxy_read_timeout：設置從后端服務器讀取響應數(shù)據(jù)的超時時間。
  • proxy_send_timeout：設置向后端服務器傳輸請求數(shù)據(jù)的超時時間玫膀。

具體的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;
}

上述的緩沖區(qū)參數(shù)矛缨，是基于每個請求分配的空間，而并不是所有請求的共享空間帖旨。當然箕昭，具體的參數(shù)值還需要根據(jù)業(yè)務去決定，要綜合考慮機器的內(nèi)存以及每個請求的平均數(shù)據(jù)大小解阅。

最后提一嘴：使用緩沖也可以減少即時傳輸帶來的帶寬消耗落竹。

七、Nginx緩存機制

對于性能優(yōu)化而言货抄，緩存是一種能夠大幅度提升性能的方案述召，因此幾乎可以在各處都能看見緩存，如客戶端緩存碉熄、代理緩存桨武、服務器緩存等等，Nginx的緩存則屬于代理緩存的一種锈津。對于整個系統(tǒng)而言呀酸，加入緩存帶來的優(yōu)勢額外明顯：

• 減少了再次向后端或文件服務器請求資源的帶寬消耗。
• 降低了下游服務器的訪問壓力琼梆，提升系統(tǒng)整體吞吐性誉。
• 縮短了響應時間，提升了加載速度茎杂，打開頁面的速度更快错览。

那么在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];
  • 是的轧邪，你沒有看錯，就是這么長....羞海，解釋一下每個參數(shù)項的含義：
    • path：緩存的路徑地址忌愚。
    • levels：緩存存儲的層次結(jié)構，最多允許三層目錄却邓。
    • use_temp_path：是否使用臨時目錄硕糊。
    • keys_zone：指定一個共享內(nèi)存空間來存儲熱點Key(1M可存儲8000個Key)。
    • inactive：設置緩存多長時間未被訪問后刪除（默認是十分鐘）腊徙。
    • max_size：允許緩存的最大存儲空間简十，超出后會基于LRU算法移除緩存，Nginx會創(chuàng)建一個Cache manager的進程移除數(shù)據(jù)撬腾，也可以通過purge方式螟蝙。
    • manager_files：manager進程每次移除緩存文件數(shù)量的上限。
    • manager_sleep：manager進程每次移除緩存文件的時間上限时鸵。
    • manager_threshold：manager進程每次移除緩存后的間隔時間胶逢。
    • loader_files：重啟Nginx載入緩存時，每次加載的個數(shù)饰潜，默認100初坠。
    • loader_sleep：每次載入時，允許的最大時間上限彭雾，默認200ms碟刺。
    • loader_threshold：一次載入后，停頓的時間間隔薯酝，默認50ms半沽。
    • purger：是否開啟purge方式移除數(shù)據(jù)。
    • purger_files：每次移除緩存文件時的數(shù)量。
    • purger_sleep：每次移除時，允許消耗的最大時間训堆。
    • purger_threshold：每次移除完成后，停頓的間隔時間占哟。
• proxy_cache：開啟或關閉代理緩存，開啟時需要指定一個共享內(nèi)存區(qū)域酿矢。
  • 語法：proxy_cache zone | off;
    • zone為內(nèi)存區(qū)域的名稱榨乎，即上面中keys_zone設置的名稱。
• proxy_cache_key：定義如何生成緩存的鍵瘫筐。
  • 語法：proxy_cache_key string;
    • string為生成Key的規(guī)則蜜暑，如$scheme$proxy_host$request_uri。
• proxy_cache_valid：緩存生效的狀態(tài)碼與過期時間策肝。
  • 語法：proxy_cache_valid [code ...] time;
    • code為狀態(tài)碼肛捍，time為有效時間隐绵，可以根據(jù)狀態(tài)碼設置不同的緩存時間。
    • 例如：proxy_cache_valid 200 302 30m;
• proxy_cache_min_uses：設置資源被請求多少次后被緩存篇梭。
  • 語法：proxy_cache_min_uses number;
    • number為次數(shù)氢橙，默認為1。
• proxy_cache_use_stale：當后端出現(xiàn)異常時恬偷，是否允許Nginx返回緩存作為響應。
  • 語法：proxy_cache_use_stale error;
    • error為錯誤類型帘睦，可配置timeout|invalid_header|updating|http_500...袍患。
• proxy_cache_lock：對于相同的請求，是否開啟鎖機制竣付，只允許一個請求發(fā)往后端诡延。
  • 語法：proxy_cache_lock on | off;
• proxy_cache_lock_timeout：配置鎖超時機制，超出規(guī)定時間后會釋放請求古胆。
  • 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：命中的緩存內(nèi)容陳舊识啦，但正在更新緩存负蚊。
  • BYPASS：響應結(jié)果是從原始服務器獲取的。
  • PS：這個和之前的不同颓哮，之前的都是參數(shù)項家妆，這個是一個Nginx內(nèi)置變量。

OK~冕茅，對于Nginx中的緩存配置項大概了解后伤极，接著來配置一下Nginx代理緩存：

http{
    # 設置緩存的目錄蛹找，并且內(nèi)存中緩存區(qū)名為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狀態(tài)碼的數(shù)據(jù)緩存1天
            proxy_cache_valid 200 206 304 301 302 1d;
            # 對于其他狀態(tài)的數(shù)據(jù)緩存30分鐘
            proxy_cache_valid any 30m;
            # 定義生成緩存鍵的規(guī)則（請求的url+參數(shù)作為key）
            proxy_cache_key $host$uri$is_args$args;
            # 資源至少被重復訪問三次后再加入緩存
            proxy_cache_min_uses 3;
            # 出現(xiàn)重復請求時金顿，只讓一個去后端讀數(shù)據(jù)，其他的從緩存中讀取
            proxy_cache_lock on;
            # 上面的鎖超時時間為3s鲤桥，超過3s未獲取數(shù)據(jù)揍拆，其他請求直接去后端
            proxy_cache_lock_timeout 3s;
            # 對于請求參數(shù)或cookie中聲明了不緩存的數(shù)據(jù)，不再加入緩存
            proxy_no_cache $cookie_nocache $arg_nocache $arg_comment;
            # 在響應頭中添加一個緩存是否命中的狀態(tài)（便于調(diào)試）
            add_header Cache-status $upstream_cache_status;
        }
    }
}

接著來看一下效果茶凳，如下：

[圖片上傳失敗...(image-d0e486-1673949896618)]

第一次訪問時嫂拴，因為還沒有請求過資源，所以緩存中沒有數(shù)據(jù)贮喧，因此沒有命中緩存筒狠。第二、三次塞淹，依舊沒有命中緩存窟蓝，直至第四次時才顯示命中，這是為什么呢饱普？因為在前面的緩存配置中运挫，我們配置了加入緩存的最低條件為：資源至少要被請求三次以上才會加入緩存。 這樣可以避免很多無效緩存占用空間套耕。

緩存清理

當緩存過多時谁帕，如果不及時清理會導致磁盤空間被“吃光”，因此我們需要一套完善的緩存清理機制去刪除緩存冯袍，在之前的proxy_cache_path參數(shù)中有purger相關的選項匈挖，開啟后可以幫我們自動清理緩存，但遺憾的是：purger系列參數(shù)只有商業(yè)版的NginxPlus才能使用康愤，因此需要付費才可使用儡循。

不過天無絕人之路，我們可以通過強大的第三方模塊ngx_cache_purge來替代征冷，先來安裝一下該插件：
①首先去到Nginx的安裝目錄下择膝，創(chuàng)建一個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/

⑤重新根據(jù)剛剛構建的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規(guī)則：

location ~ /purge(/.*) {
  # 配置可以執(zhí)行清除操作的IP（線上可以配置成內(nèi)網(wǎng)機器）
  # allow 127.0.0.1; # 代表本機
  allow all; # 代表允許任意IP清除緩存
  proxy_cache_purge $host$1$is_args$args;
}

然后再重啟Nginx窃页，接下來即可通過http://xxx/purge/xx的方式清除緩存跺株。

八、Nginx實現(xiàn)IP黑白名單

有時候往往有些需求脖卖，可能某些接口只能開放給對應的合作商帖鸦，或者購買/接入API的合作伙伴，那么此時就需要實現(xiàn)類似于IP白名單的功能胚嘲。而有時候有些惡意攻擊者或爬蟲程序，被識別后需要禁止其再次訪問網(wǎng)站洛二，因此也需要實現(xiàn)IP黑名單馋劈。那么這些功能無需交由后端實現(xiàn)，可直接在Nginx中處理晾嘶。

Nginx做黑白名單機制妓雾，主要是通過allow、deny配置項來實現(xiàn)：

allow xxx.xxx.xxx.xxx; # 允許指定的IP訪問垒迂，可以用于實現(xiàn)白名單械姻。
deny xxx.xxx.xxx.xxx; # 禁止指定的IP訪問，可以用于實現(xiàn)黑名單机断。

要同時屏蔽/開放多個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網(wǎng)段中的所有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網(wǎng)段中的所有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黑/白名單實現(xiàn)方式，同時也可以通過ngx_http_geo_module沉桌、ngx_http_geo_module第三方庫去實現(xiàn)（這種方式可以按地區(qū)谢鹊、國家進行屏蔽算吩，并且提供了IP庫）。

九佃扼、Nginx跨域配置

跨域問題在之前的單體架構開發(fā)中偎巢，其實是比較少見的問題，除非是需要接入第三方SDK時兼耀，才需要處理此問題压昼。但隨著現(xiàn)在前后端分離、分布式架構的流行瘤运，跨域問題也成為了每個Java開發(fā)必須要懂得解決的一個問題窍霞。

跨域問題產(chǎn)生的原因

產(chǎn)生跨域問題的主要原因就在于同源策略，為了保證用戶信息安全拯坟，防止惡意網(wǎng)站竊取數(shù)據(jù)但金，同源策略是必須的，否則cookie可以共享郁季。由于http無狀態(tài)協(xié)議通常會借助cookie來實現(xiàn)有狀態(tài)的信息記錄冷溃，例如用戶的身份/密碼等，因此一旦cookie被共享梦裂，那么會導致用戶的身份信息被盜取似枕。
同源策略主要是指三點相同，協(xié)議+域名+端口 相同的兩個請求年柠，則可以被看做是同源的凿歼，但如果其中任意一點存在不同，則代表是兩個不同源的請求冗恨，同源策略會限制了不同源之間的資源交互答憔。

Nginx解決跨域問題

弄明白了跨域問題的產(chǎn)生原因，接下來看看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' *;
    # 允許發(fā)送按段獲取資源的請求
    add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range';
    # 一定要有！Ｆ坠臁戒幔！否則Post請求無法進行跨域！
    # 在發(fā)送Post跨域請求前土童，會以Options方式發(fā)送預檢請求诗茎，服務器接受時才會正式請求
    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文件加上如上配置后，跨域請求即可生效了敢订。

但如果后端是采用分布式架構開發(fā)的王污，有時候RPC調(diào)用也需要解決跨域問題，不然也同樣會出現(xiàn)無法跨域請求的異常楚午，因此可以在你的后端項目中昭齐，通過繼承HandlerInterceptorAdapter類、實現(xiàn)WebMvcConfigurer接口矾柜、添加@CrossOrgin注解的方式實現(xiàn)接口之間的跨域配置阱驾。

十、Nginx防盜鏈設計

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

好比壁紙網(wǎng)站X站里覆、Y站，X站是一點點去購買版權缆瓣、簽約作者的方式喧枷，從而積累了海量的壁紙素材，但Y站由于資金等各方面的原因弓坞，就直接通過<img src="X站/xxx.jpg" />這種方式照搬了X站的所有壁紙資源割去，繼而提供給用戶下載。

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

Nginx的防盜鏈機制實現(xiàn)，跟上篇文章《HTTP/HTTPS》中分析到的一個頭部字段：Referer有關茬腿，該字段主要描述了當前請求是從哪兒發(fā)出的呼奢，那么在Nginx中就可獲取該值，然后判斷是否為本站的資源引用請求切平，如果不是則不允許訪問握础。Nginx中存在一個配置項為valid_referers，正好可以滿足前面的需求悴品，語法如下：

• valid_referers none | blocked | server_names | string ...;
  • none：表示接受沒有Referer字段的HTTP請求訪問禀综。
  • blocked：表示允許http://或https//以外的請求訪問。
  • server_names：資源的白名單苔严，這里可以指定允許訪問的域名定枷。
  • string：可自定義字符串，支配通配符届氢、正則表達式寫法欠窒。

簡單了解語法后，接下來的實現(xiàn)如下：

# 在動靜分離的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;
}

根據(jù)上述中的內(nèi)容配置后退子，就已經(jīng)通過Nginx實現(xiàn)了最基本的防盜鏈機制岖妄，最后只需要額外重啟一下就好啦型将！當然，對于防盜鏈機制實現(xiàn)這塊荐虐，也有專門的第三方模塊ngx_http_accesskey_module實現(xiàn)了更為完善的設計七兜，感興趣的小伙伴可以自行去看看。

PS：防盜鏈機制也無法解決爬蟲偽造referers信息的這種方式抓取數(shù)據(jù)缚俏。

十一惊搏、Nginx大文件傳輸配置

在某些業(yè)務場景中需要傳輸一些大文件，但大文件傳輸時往往都會會出現(xiàn)一些Bug忧换，比如文件超出限制恬惯、文件傳輸過程中請求超時等，那么此時就可以在Nginx稍微做一些配置亚茬，先來了解一些關于大文件傳輸時可能會用的配置項：

在傳輸大文件時，client_max_body_size刹缝、client_header_timeout碗暗、proxy_read_timeout、proxy_send_timeout這四個參數(shù)值都可以根據(jù)自己項目的實際情況來配置梢夯。

上述配置僅是作為代理層需要配置的言疗，因為最終客戶端傳輸文件還是直接與后端進行交互，這里只是把作為網(wǎng)關層的Nginx配置調(diào)高一點颂砸，調(diào)到能夠“容納大文件”傳輸?shù)某潭取?br> 當然噪奄，Nginx中也可以作為文件服務器使用，但需要用到一個專門的第三方模塊nginx-upload-module人乓，如果項目中文件上傳的作用處不多勤篮，那么建議可以通過Nginx搭建，畢竟可以節(jié)省一臺文件服務器資源色罚。但如若文件上傳/下載較為頻繁碰缔，那么還是建議額外搭建文件服務器，并將上傳/下載功能交由后端處理戳护。

十二金抡、Nginx配置SLL證書

隨著越來越多的網(wǎng)站接入HTTPS，因此Nginx中僅配置HTTP還不夠腌且，往往還需要監(jiān)聽443端口的請求竟终，但在上篇《HTTP/HTTPS》中談到過，HTTPS為了確保通信安全切蟋，所以服務端需配置對應的數(shù)字證書统捶，當項目使用Nginx作為網(wǎng)關時，那么證書在Nginx中也需要配置，接下來簡單聊一下關于SSL證書配置過程：

• ①先去CA機構或從云控制臺中申請對應的SSL證書喘鸟，審核通過后下載Nginx版本的證書匆绣。
• ②下載數(shù)字證書后，完整的文件總共有三個：.crt什黑、.key崎淳、.pem：
  • .crt：數(shù)字證書文件，.crt是.pem的拓展文件愕把，因此有些人下載后可能沒有拣凹。
  • .key：服務器的私鑰文件，及非對稱加密的私鑰恨豁，用于解密公鑰傳輸?shù)臄?shù)據(jù)嚣镜。
  • .pem：Base64-encoded編碼格式的源證書文本文件，可自行根需求修改拓展名橘蜜。
• ③在Nginx目錄下新建certificate目錄菊匿，并將下載好的證書/私鑰等文件上傳至該目錄。
• ④最后修改一下nginx.conf文件即可计福，如下：

# ----------HTTPS配置-----------
server {
    # 監(jiān)聽HTTPS默認的443端口
    listen 443;
    # 配置自己項目的域名
    server_name www.xxx.com;
    # 打開SSL加密傳輸
    ssl on;
    # 輸入域名后跌捆，首頁文件所在的目錄
    root html;
    # 配置首頁的文件名
    index index.html index.htm index.jsp index.ftl;
    # 配置自己下載的數(shù)字證書
    ssl_certificate  certificate/xxx.pem;
    # 配置自己下載的服務器私鑰
    ssl_certificate_key certificate/xxx.key;
    # 停止通信時，加密會話的有效期象颖，在該時間段內(nèi)不需要重新交換密鑰
    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請求轉(zhuǎn)HTTPS-------------
server {
    # 監(jiān)聽HTTP默認的80端口
    listen 80;
    # 如果80端口出現(xiàn)訪問該域名的請求
    server_name www.xxx.com;
    # 將請求改寫為HTTPS（這里寫你配置了HTTPS的域名）
    rewrite ^(.*)$ https://www.xxx.com;
}

OK~，根據(jù)如上配置了Nginx后说订，你的網(wǎng)站即可通過https://的方式訪問可款，并且當客戶端使用http://的方式訪問時，會自動將其改寫為HTTPS請求克蚂。

十三、Nginx的高可用

線上如果采用單個節(jié)點的方式部署Nginx筋讨，難免會出現(xiàn)天災人禍埃叭，比如系統(tǒng)異常、程序宕機悉罕、服務器斷電赤屋、機房爆炸、地球毀滅....哈哈哈壁袄，夸張了类早。但實際生產(chǎn)環(huán)境中確實存在隱患問題，由于Nginx作為整個系統(tǒng)的網(wǎng)關層接入外部流量嗜逻，所以一旦Nginx宕機涩僻，最終就會導致整個系統(tǒng)不可用，這無疑對于用戶的體驗感是極差的，因此也得保障Nginx高可用的特性逆日。

接下來則會通過keepalived的VIP機制嵌巷，實現(xiàn)Nginx的高可用。
VIP并不是只會員的意思室抽，而是指Virtual IP搪哪，即虛擬IP。

keepalived在之前單體架構開發(fā)時坪圾，是一個用的較為頻繁的高可用技術晓折，比如MySQL、Redis兽泄、MQ漓概、Proxy六孵、Tomcat等各處都會通過keepalived提供的VIP機制励幼，實現(xiàn)單節(jié)點應用的高可用险污。

Keepalived+重啟腳本+雙機熱備搭建

①首先創(chuàng)建一個對應的目錄并下載keepalived安裝包（提取碼:s6aq）到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目錄并構建安裝環(huán)境痢畜，然后編譯并安裝：

[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 {
    # 自帶的郵件提醒服務染坯，建議用獨立的監(jiān)控或第三方SMTP筒扒，也可選擇配置郵件發(fā)送忘苛。
    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秒執(zhí)行一次
    interval 3
    # 如果腳本中的條件成立缔莲，重啟一次則權重-20
    weight -20
}

# 定義虛擬路由，VI_1為虛擬路由的標示符（可自定義名稱）
vrrp_instance VI_1 {
    # 當前節(jié)點的身份標識：用來決定主從（MASTER為主機霉旗，BACKUP為從機）
    state MASTER
    # 綁定虛擬IP的網(wǎng)絡接口痴奏，根據(jù)自己的機器的網(wǎng)卡配置
    interface ens33 
    # 虛擬路由的ID號，主從兩個節(jié)點設置必須一樣
    virtual_router_id 121
    # 填寫本機IP
    mcast_src_ip 192.168.12.129
    # 節(jié)點權重優(yōu)先級厌秒，主節(jié)點要比從節(jié)點優(yōu)先級高
    priority 100
    # 優(yōu)先級高的設置nopreempt读拆，解決異常恢復后再次搶占造成的腦裂問題
    nopreempt
    # 組播信息發(fā)送間隔鸵闪，兩個節(jié)點設置必須一樣檐晕，默認1s（類似于心跳檢測）
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    # 將track_script塊加入instance配置塊
    track_script {
        # 執(zhí)行Nginx監(jiān)控的腳本
        check_nginx_pid_restart
    }

    virtual_ipaddress {
        # 虛擬IP(VIP)，也可擴展蚌讼，可配置多個辟灰。
        192.168.12.111
    }
}

⑤克隆一臺之前的虛擬機作為從（備）機，編輯從機的keepalived.conf文件篡石，如下：

global_defs {
    # 自帶的郵件提醒服務芥喇，建議用獨立的監(jiān)控或第三方SMTP，也可選擇配置郵件發(fā)送凰萨。
    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秒執(zhí)行一次
    interval 3
    # 如果腳本中的條件成立械馆，重啟一次則權重-20
    weight -20
}

# 定義虛擬路由，VI_1為虛擬路由的標示符（可自定義名稱）
vrrp_instance VI_1 {
    # 當前節(jié)點的身份標識：用來決定主從（MASTER為主機湿诊，BACKUP為從機）
    state BACKUP
    # 綁定虛擬IP的網(wǎng)絡接口狱杰，根據(jù)自己的機器的網(wǎng)卡配置
    interface ens33 
    # 虛擬路由的ID號，主從兩個節(jié)點設置必須一樣
    virtual_router_id 121
    # 填寫本機IP
    mcast_src_ip 192.168.12.130
    # 節(jié)點權重優(yōu)先級厅须，主節(jié)點要比從節(jié)點優(yōu)先級高
    priority 90
    # 優(yōu)先級高的設置nopreempt仿畸，解決異常恢復后再次搶占造成的腦裂問題
    nopreempt
    # 組播信息發(fā)送間隔朗和，兩個節(jié)點設置必須一樣错沽，默認1s（類似于心跳檢測）
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    # 將track_script塊加入instance配置塊
    track_script {
        # 執(zhí)行Nginx監(jiān)控的腳本
        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進程數(shù)忆植，并將其保存在變量nginx_number中
nginx_number=`ps -C nginx --no-header | wc -l`
# 判斷后臺是否還有Nginx進程在運行
if [ nginx_number -eq 0 ];then
    # 如果后臺查詢不到`Nginx`進程存在放可，則執(zhí)行重啟指令
    /soft/nginx/sbin/nginx -c /soft/nginx/conf/nginx.conf
    # 重啟后等待1s后，再次查詢后臺進程數(shù)
    sleep 1
    # 如果重啟后依舊無法查詢到nginx進程
    if [ `ps -C nginx --no-header | wc -l` -eq 0 ];then
        # 將keepalived主機下線朝刊，將虛擬IP漂移給從機耀里，從機上線接管Nginx服務
        systemctl stop keepalived.service
    fi
fi

⑦編寫的腳本文件需要更改編碼格式，并賦予執(zhí)行權限拾氓，否則可能執(zhí)行失敺肟妗：

[root@localhost]# vi /soft/scripts/keepalived/check_nginx_pid_restart.sh

:set fileformat=unix # 在vi命令里面執(zhí)行，修改編碼格式
:set ff # 查看修改后的編碼格式

[root@localhost]# chmod +x /soft/scripts/keepalived/check_nginx_pid_restart.sh

⑧由于安裝keepalived時咙鞍，是自定義的安裝位置房官，因此需要拷貝一些文件到系統(tǒng)目錄中：

[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加入系統(tǒng)服務并設置開啟自啟動，然后測試啟動是否正常：

[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

image

從上圖中可以明顯看見虛擬IP已經(jīng)成功掛載翰守，但另外一臺機器192.168.12.130并不會掛載這個虛擬IP，只有當主機下線后疲酌，作為從機的192.168.12.130才會上線蜡峰，接替VIP。最后測試一下外網(wǎng)是否可以正常與VIP通信徐勃，即在Windows中直接ping VIP：

image

外部通過VIP通信時，也可以正常Ping通早像，代表虛擬IP配置成功僻肖。

Nginx高可用性測試

經(jīng)過上述步驟后，keepalived的VIP機制已經(jīng)搭建成功卢鹦，在上個階段中主要做了幾件事：

• 一臀脏、為部署Nginx的機器掛載了VIP劝堪。
• 二、通過keepalived搭建了主從雙機熱備揉稚。
• 三秒啦、通過keepalived實現(xiàn)了Nginx宕機重啟。

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

sever{
    listen    80;
    # 這里從機器的本地IP改為虛擬IP
    server_name 192.168.12.111;
    # 如果這里配置的是域名，那么則將域名的映射配置改為虛擬IP
}

最后來實驗一下效果：

image

在上述過程中灌诅，首先分別啟動了keepalived芳来、nginx服務，然后通過手動停止nginx的方式模擬了Nginx宕機情況猜拾，過了片刻后再次查詢后臺進程即舌，我們會發(fā)現(xiàn)nginx依舊存活。

從這個過程中不難發(fā)現(xiàn)挎袜，keepalived已經(jīng)為我們實現(xiàn)了Nginx宕機后自動重啟的功能顽聂，那么接著再模擬一下服務器出現(xiàn)故障時的情況：

image

在上述過程中，我們通過手動關閉keepalived服務模擬了機器斷電盯仪、硬件損壞等情況（因為機器斷電等情況=主機中的keepalived進程消失）紊搪，然后再次查詢了一下本機的IP信息，很明顯會看到VIP消失了磨总！

現(xiàn)在再切換到另外一臺機器：192.168.12.130來看看情況：

image

此刻我們會發(fā)現(xiàn)嗦明，在主機192.168.12.129宕機后，VIP自動從主機飄移到了從機192.168.12.130上蚪燕，而此時客戶端的請求就最終會來到130這臺機器的Nginx上娶牌。

最終，利用Keepalived對Nginx做了主從熱備之后馆纳，無論是遇到線上宕機還是機房斷電等各類故障時诗良，都能夠確保應用系統(tǒng)能夠為用戶提供7x24小時服務。

十四鲁驶、Nginx性能優(yōu)化

到這里文章的篇幅較長了鉴裹，最后再來聊一下關于Nginx的性能優(yōu)化，主要就簡單說說收益最高的幾個優(yōu)化項钥弯，在這塊就不再展開敘述了径荔，畢竟影響性能都有多方面原因?qū)е碌模热缇W(wǎng)絡脆霎、服務器硬件总处、操作系統(tǒng)、后端服務睛蛛、程序自身鹦马、數(shù)據(jù)庫服務等胧谈，對于性能調(diào)優(yōu)比較感興趣的可以參考之前《JVM性能調(diào)優(yōu)》中的調(diào)優(yōu)思想。

優(yōu)化一：打開長連接配置

通常Nginx作為代理服務荸频，負責分發(fā)客戶端的請求菱肖，那么建議開啟HTTP長連接，用戶減少握手的次數(shù)旭从，降低服務器損耗稳强，具體如下：

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

優(yōu)化二遇绞、開啟零拷貝技術

零拷貝這個概念键袱，在大多數(shù)性能較為不錯的中間件中都有出現(xiàn)，例如Kafka摹闽、Netty等蹄咖，而Nginx中也可以配置數(shù)據(jù)零拷貝技術，如下：

sendfile on; # 開啟零拷貝機制

零拷貝讀取機制與傳統(tǒng)資源讀取機制的區(qū)別：

• 傳統(tǒng)方式：硬件-->內(nèi)核-->用戶空間-->程序空間-->程序內(nèi)核空間-->網(wǎng)絡套接字
• 零拷貝方式：硬件-->內(nèi)核-->程序內(nèi)核空間-->網(wǎng)絡套接字

從上述這個過程對比付鹿，很輕易就能看出兩者之間的性能區(qū)別澜汤。

優(yōu)化三、開啟無延遲或多包共發(fā)機制

在Nginx中有兩個較為關鍵的性能參數(shù)舵匾，即tcp_nodelay俊抵、tcp_nopush，開啟方式如下：

tcp_nodelay on;
tcp_nopush on;

TCP/IP協(xié)議中默認是采用了Nagle算法的坐梯，即在網(wǎng)絡數(shù)據(jù)傳輸過程中徽诲，每個數(shù)據(jù)報文并不會立馬發(fā)送出去，而是會等待一段時間吵血，將后面的幾個數(shù)據(jù)包一起組合成一個數(shù)據(jù)報文發(fā)送谎替，但這個算法雖然提高了網(wǎng)絡吞吐量，但是實時性卻降低了蹋辅。

因此你的項目屬于交互性很強的應用钱贯，那么可以手動開啟tcp_nodelay配置，讓應用程序向內(nèi)核遞交的每個數(shù)據(jù)包都會立即發(fā)送出去侦另。但這樣會產(chǎn)生大量的TCP報文頭秩命，增加很大的網(wǎng)絡開銷。

相反褒傅，有些項目的業(yè)務對數(shù)據(jù)的實時性要求并不高弃锐，追求的則是更高的吞吐，那么則可以開啟tcp_nopush配置項殿托，這個配置就類似于“塞子”的意思霹菊，首先將連接塞住，使得數(shù)據(jù)先不發(fā)出去碌尔，等到拔去塞子后再發(fā)出去浇辜。設置該選項后，內(nèi)核會盡量把小數(shù)據(jù)包拼接成一個大的數(shù)據(jù)包（一個MTU）再發(fā)送出去.

當然若一定時間后（一般為200ms）唾戚，內(nèi)核仍然沒有積累到一個MTU的量時柳洋，也必須發(fā)送現(xiàn)有的數(shù)據(jù)，否則會一直阻塞叹坦。

tcp_nodelay熊镣、tcp_nopush兩個參數(shù)是“互斥”的，如果追求響應速度的應用推薦開啟tcp_nodelay參數(shù)募书，如IM绪囱、金融等類型的項目。如果追求吞吐量的應用則建議開啟tcp_nopush參數(shù)莹捡，如調(diào)度系統(tǒng)鬼吵、報表系統(tǒng)等。

注意：
①tcp_nodelay一般要建立在開啟了長連接模式的情況下使用篮赢。
②tcp_nopush參數(shù)是必須要開啟sendfile參數(shù)才可使用的齿椅。

優(yōu)化四、調(diào)整Worker工作進程

Nginx啟動后默認只會開啟一個Worker工作進程處理客戶端請求启泣，而我們可以根據(jù)機器的CPU核數(shù)開啟對應數(shù)量的工作進程涣脚，以此來提升整體的并發(fā)量支持，如下：

# 自動根據(jù)CPU核心數(shù)調(diào)整Worker進程數(shù)量
worker_processes auto;

工作進程的數(shù)量最高開到8個就OK了寥茫，8個之后就不會有再大的性能提升遣蚀。

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

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

操作系統(tǒng)內(nèi)核（kernel）都是利用文件描述符來訪問文件芭梯，無論是打開、新建膝迎、讀取粥帚、寫入文件時，都需要使用文件描述符來指定待操作的文件限次，因此該值越大芒涡，代表一個進程能夠操作的文件越多（但不能超出內(nèi)核限制，最多建議3.8W左右為上限）卖漫。

優(yōu)化五费尽、開啟CPU親和機制

對于并發(fā)編程較為熟悉的伙伴都知道，因為進程/線程數(shù)往往都會遠超出系統(tǒng)CPU的核心數(shù)羊始，因為操作系統(tǒng)執(zhí)行的原理本質(zhì)上是采用時間片切換機制旱幼，也就是一個CPU核心會在多個進程之間不斷頻繁切換，造成很大的性能損耗突委。

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

worker_cpu_affinity auto;

優(yōu)化六缘缚、開啟epoll模型及調(diào)整并發(fā)連接數(shù)

在最開始就提到過：Nginx勾笆、Redis都是基于多路復用模型去實現(xiàn)的程序，但最初版的多路復用模型select/poll最大只能監(jiān)聽1024個連接桥滨，而epoll則屬于select/poll接口的增強版窝爪，因此采用該模型能夠大程度上提升單個Worker的性能，如下：

events {
    # 使用epoll網(wǎng)絡模型
    use epoll;
    # 調(diào)整每個Worker能夠處理的連接數(shù)上限
    worker_connections  10240;
}

這里對于select/poll/epoll模型就不展開細說了齐媒，后面的IO模型文章中會詳細剖析蒲每。

十五、放在最后的結(jié)尾

至此喻括，Nginx的大部分內(nèi)容都已闡述完畢邀杏，關于最后一小節(jié)的性能優(yōu)化內(nèi)容，其實在前面就談到的動靜分離唬血、分配緩沖區(qū)淮阐、資源緩存、防盜鏈刁品、資源壓縮等內(nèi)容泣特，也都可歸納為性能優(yōu)化的方案。