小男孩‘自慰网亚洲一区二区,亚洲一级在线播放毛片,亚洲中文字幕av每天更新,黄aⅴ永久免费无码,91成人午夜在线精品,色网站免费在线观看,亚洲欧洲wwwww在线观看

分享

Nginx一網(wǎng)打盡:動(dòng)靜分離、壓縮、緩存、黑白名單、跨域、高可用、性能優(yōu)化!

 昵稱10087950 2023-09-08 發(fā)布于江蘇

引言

  • 一、性能怪獸-Nginx概念深入淺出
  • 二、Nginx環(huán)境搭建
  • 三、Nginx反向代理-負(fù)載均衡
  • 四、Nginx動(dòng)靜分離
  • 五、Nginx資源壓縮
  • 六、Nginx緩沖區(qū)
  • 七、Nginx緩存機(jī)制
  • 八、Nginx實(shí)現(xiàn)IP黑白名單
  • 九、Nginx跨域配置
  • 十、Nginx防盜鏈設(shè)計(jì)
  • 十一、Nginx大文件傳輸配置
  • 十二、Nginx配置SLL證書
  • 十三、Nginx的高可用
  • 十四、Nginx性能優(yōu)化
  • 十五、放在最后的結(jié)尾

引言

早期的業(yè)務(wù)都是基于單體節(jié)點(diǎn)部署,由于前期訪問流量不大,因此單體結(jié)構(gòu)也可滿足需求,但隨著業(yè)務(wù)增長(zhǎng),流量也越來(lái)越大,那么最終單臺(tái)服務(wù)器受到的訪問壓力也會(huì)逐步增高。時(shí)間一長(zhǎng),單臺(tái)服務(wù)器性能無(wú)法跟上業(yè)務(wù)增長(zhǎng),就會(huì)造成線上頻繁宕機(jī)的現(xiàn)象發(fā)生,最終導(dǎo)致系統(tǒng)癱瘓無(wú)法繼續(xù)處理用戶的請(qǐng)求。
?
從上面的描述中,主要存在兩個(gè)問題:①單體結(jié)構(gòu)的部署方式無(wú)法承載日益增長(zhǎng)的業(yè)務(wù)流量。②當(dāng)后端節(jié)點(diǎn)宕機(jī)后,整個(gè)系統(tǒng)會(huì)陷入癱瘓,導(dǎo)致整個(gè)項(xiàng)目不可用。
?
因此在這種背景下,引入負(fù)載均衡技術(shù)可帶來(lái)的收益:
  • 「系統(tǒng)的高可用:」 當(dāng)某個(gè)節(jié)點(diǎn)宕機(jī)后可以迅速將流量轉(zhuǎn)移至其他節(jié)點(diǎn)。

  • 「系統(tǒng)的高性能:」 多臺(tái)服務(wù)器共同對(duì)外提供服務(wù),為整個(gè)系統(tǒng)提供了更高規(guī)模的吞吐。

  • 「系統(tǒng)的拓展性:」 當(dāng)業(yè)務(wù)再次出現(xiàn)增長(zhǎng)或萎靡時(shí),可再加入/減少節(jié)點(diǎn),靈活伸縮。

OK~,既然引入負(fù)載均衡技術(shù)可給我們帶來(lái)如此巨大的好處,那么又有那些方案可供選擇呢?主要有兩種負(fù)載方案,「「硬件層面與軟件層面」」 ,比較常用的硬件負(fù)載器有A10、F5等,但這些機(jī)器動(dòng)輒大幾萬(wàn)乃至幾十萬(wàn)的成本,因此一般大型企業(yè)會(huì)采用該方案,如銀行、國(guó)企、央企等。而成本有限,但依舊想做負(fù)載均衡的項(xiàng)目,那么可在軟件層面實(shí)現(xiàn),如典型的Nginx
等,軟件層的負(fù)載也是本文的重點(diǎn),畢竟Boss們的準(zhǔn)則之一就是:「「能靠技術(shù)實(shí)現(xiàn)的就盡量不花錢?!埂?/strong>
?

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

Nginx是目前負(fù)載均衡技術(shù)中的主流方案,幾乎絕大部分項(xiàng)目都會(huì)使用它,Nginx是一個(gè)輕量級(jí)的高性能HTTP反向代理服務(wù)器,同時(shí)它也是一個(gè)通用類型的代理服務(wù)器,支持絕大部分協(xié)議,如TCP、UDP、SMTP、HTTPS等。
圖片
Nginx與Redis相同,都是基于多路復(fù)用模型構(gòu)建出的產(chǎn)物,因此它與Redis同樣具備 「「資源占用少、并發(fā)支持高」」 的特點(diǎn),在理論上單節(jié)點(diǎn)的Nginx同時(shí)支持5W并發(fā)連接,而實(shí)際生產(chǎn)環(huán)境中,硬件基礎(chǔ)到位再結(jié)合簡(jiǎn)單調(diào)優(yōu)后確實(shí)能達(dá)到該數(shù)值。
先來(lái)看看Nginx引入前后,客戶端請(qǐng)求處理流程的對(duì)比:
圖片
原本客戶端是直接請(qǐng)求目標(biāo)服務(wù)器,由目標(biāo)服務(wù)器直接完成請(qǐng)求處理工作,但加入Nginx
后,所有的請(qǐng)求會(huì)先經(jīng)過Nginx,再由其進(jìn)行分發(fā)到具體的服務(wù)器處理,處理完成后再返回Nginx,最后由Nginx將最終的響應(yīng)結(jié)果返回給客戶端。了解了Nginx的基本概念后,再來(lái)快速搭建一下環(huán)境,以及了解一些Nginx的高級(jí)特性,如動(dòng)靜分離、資源壓縮、緩存配置、IP
黑名單、高可用保障等。

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

?首先創(chuàng)建Nginx的目錄并進(jìn)入:

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

?下載Nginx的安裝包,可以通過FTP工具上傳離線環(huán)境包,也可通過wget命令在線獲取安裝包:

[root@localhost]# wget https:///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所需的依賴庫(kù)和包:

[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查看目錄文件,會(huì)看一大堆依賴:

圖片
緊接著通過rpm命令依次將依賴包一個(gè)個(gè)構(gòu)建,或者通過如下指令一鍵安裝所有依賴包:
[root@localhost]# rpm -ivh --nodeps *.rpm  
?進(jìn)入解壓后的nginx目錄,然后執(zhí)行Nginx的配置腳本,為后續(xù)的安裝提前配置好環(huán)境,默認(rè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  
    修改端口號(hào):listen    80;  
 修改IP地址:server_name  你當(dāng)前機(jī)器的本地IP(線上配置域名);  
?制定配置文件并啟動(dòng)Nginx:
[root@localhost]# sbin/nginx -c conf/nginx.conf  
[root@localhost]# ps aux | grep nginx  
Nginx其他操作命令:

sbin/nginx -t -c conf/nginx.conf # 檢測(cè)配置文件是否正常  
sbin/nginx -s reload -c conf/nginx.conf # 修改配置后平滑重啟  
sbin/nginx -s quit # 優(yōu)雅關(guān)閉Nginx,會(huì)在執(zhí)行完當(dāng)前的任務(wù)后再退出  
sbin/nginx -s stop # 強(qiáng)制終止Nginx,不管當(dāng)前是否有任務(wù)在執(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:最終看到如上的

Nginx歡迎界面,代表Nginx安裝完成。

三、Nginx反向代理-負(fù)載均衡

首先通過SpringBoot+Freemarker快速搭建一個(gè)WEB項(xiàng)目:springboot-web-nginx,然后在該項(xiàng)目中,創(chuàng)建一個(gè)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類中,存在一個(gè)成員變量:port,它的值即是從application.properties

配置文件中獲取server.port值。當(dāng)出現(xiàn)訪問/資源的請(qǐng)求時(shí),跳轉(zhuǎn)前端index頁(yè)面,并將該值攜帶返回。前端的index.ftl文件代碼如下:

<html>  
    <head>  
        <title>Nginx演示頁(yè)面</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>歡迎來(lái)到熊貓高級(jí)會(huì)所,我是竹子${port}號(hào)!</h1>  
            </div>  
        </div>  
    </body>  
</html>

從上可以看出其邏輯并不復(fù)雜,僅是從響應(yīng)中獲取了port輸出。
OK~,前提工作準(zhǔn)備就緒后,再簡(jiǎn)單修改一下nginx.conf的配置即可:

upstream nginx_boot{  
   # 30s內(nèi)檢查心跳發(fā)送兩次包,未回復(fù)就代表該機(jī)器宕機(jī),請(qǐng)求分發(fā)權(quán)重比為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請(qǐng)配置成你WEB服務(wù)所在的機(jī)器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;  
        # 請(qǐng)求交給名為nginx_boot的upstream上  
        proxy_pass http://nginx_boot;  
    }  
}

?

至此,所有的前提工作準(zhǔn)備就緒,緊接著再啟動(dòng)Nginx,然后再啟動(dòng)兩個(gè)web服務(wù),第一個(gè)WEB服務(wù)啟動(dòng)時(shí),在application.properties配置文件中,將端口號(hào)改為8080,第二個(gè)WEB服務(wù)啟動(dòng)時(shí),將其端口號(hào)改為8090。
?
最終來(lái)看看效果:
圖片
負(fù)載均衡效果-動(dòng)圖演示
因?yàn)榕渲昧苏?qǐng)求分發(fā)的權(quán)重,8080、8090的權(quán)重比為2:1,因此請(qǐng)求會(huì)根據(jù)權(quán)重比均攤到每臺(tái)機(jī)器,也就是8080一次、8090兩次、8080一次......

Nginx請(qǐng)求分發(fā)原理

客戶端發(fā)出的請(qǐng)求192.168.12.129最終會(huì)轉(zhuǎn)變?yōu)椋篽ttp://192.168.12.129:80/,然后再向目標(biāo)IP發(fā)起請(qǐng)求,流程如下:
圖片
請(qǐng)求分發(fā)原理
  • 由于Nginx監(jiān)聽了192.168.12.129的80端口,所以最終該請(qǐng)求會(huì)找到Nginx進(jìn)程;Nginx首先會(huì)根據(jù)配置的location規(guī)則進(jìn)行匹配,根據(jù)客戶端的請(qǐng)求路徑/,會(huì)定位到location /{}規(guī)則;然后根據(jù)該location中配置的proxy_pass會(huì)再找到名為nginx_boot的upstream;

  • 最后根據(jù)upstream中的配置信息,將請(qǐng)求轉(zhuǎn)發(fā)到運(yùn)行WEB服務(wù)的機(jī)器處理,由于配置了多個(gè)WEB服務(wù),且配置了權(quán)重值,因此Nginx會(huì)依次根據(jù)權(quán)重比分發(fā)請(qǐng)求。

四、Nginx動(dòng)靜分離

動(dòng)靜分離應(yīng)該是聽的次數(shù)較多的性能優(yōu)化方案,那先思考一個(gè)問題:「「為什么需要做動(dòng)靜分離呢?它帶來(lái)的好處是什么?」」 其實(shí)這個(gè)問題也并不難回答,當(dāng)你搞懂了網(wǎng)站的本質(zhì)后,自然就理解了動(dòng)靜分離的重要性。先來(lái)以淘寶為例分析看看:
圖片
淘寶首頁(yè)當(dāng)瀏覽器輸入www.taobao.com訪問淘寶首頁(yè)時(shí),打開開發(fā)者調(diào)試工具可以很明顯的看到,首頁(yè)加載會(huì)出現(xiàn)100+的請(qǐng)求數(shù),而正常項(xiàng)目開發(fā)時(shí),靜態(tài)資源一般會(huì)放入到resources/static/
目錄下:
圖片
IDEA 工程結(jié)構(gòu)
在項(xiàng)目上線部署時(shí),這些靜態(tài)資源會(huì)一起打成包,那此時(shí)思考一個(gè)問題:「「假設(shè)淘寶也是這樣干的,那么首頁(yè)加載時(shí)的請(qǐng)求最終會(huì)去到哪兒被處理?」」 答案毋庸置疑,首頁(yè)100+的所有請(qǐng)求都會(huì)來(lái)到部署WEB服務(wù)的機(jī)器處理,那則代表著一個(gè)客戶端請(qǐng)求淘寶首頁(yè),就會(huì)對(duì)后端服務(wù)器造成100+的并發(fā)請(qǐng)求。毫無(wú)疑問,這對(duì)于后端服務(wù)器的壓力是尤為巨大的。
?
但此時(shí)不妨分析看看,首頁(yè)100+的請(qǐng)求中,是不是至少有60+是屬于*.js、*.css、*.html、*.jpg.....這類靜態(tài)資源的請(qǐng)求呢?答案是Yes。
?
既然有這么多請(qǐng)求屬于靜態(tài)的,這些資源大概率情況下,長(zhǎng)時(shí)間也不會(huì)出現(xiàn)變動(dòng),那為何還要讓這些請(qǐng)求到后端再處理呢?能不能在此之前就提前處理掉?當(dāng)然OK,因此經(jīng)過分析之后能夠明確一點(diǎn):「「做了動(dòng)靜分離之后,至少能夠讓后端服務(wù)減少一半以上的并發(fā)量?!埂?/strong> 到此時(shí)大家應(yīng)該明白了動(dòng)靜分離能夠帶來(lái)的性能收益究竟有多大。

OK~,搞清楚動(dòng)靜分離的必要性之后,如何實(shí)現(xiàn)動(dòng)靜分離呢?其實(shí)非常簡(jiǎn)單,實(shí)戰(zhàn)看看。
①先在部署Nginx的機(jī)器,Nginx目錄下創(chuàng)建一個(gè)目錄static_resources:mkdir static_resources  
②將項(xiàng)目中所有的靜態(tài)資源全部拷貝到該目錄下,而后將項(xiàng)目中的靜態(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;  
}

然后照常啟動(dòng)nginx和移除了靜態(tài)資源的WEB服務(wù),你會(huì)發(fā)現(xiàn)原本的樣式、js效果、圖片等依舊有效,如下:

圖片
其中static目錄下的nginx_style.css
文件已被移除,但效果依舊存在(綠色字體+藍(lán)色大邊框):
圖片
移除后效果動(dòng)圖最后解讀一下那條location規(guī)則:location ~ .*\.html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css)~代表匹配時(shí)區(qū)分大小寫.*
  • 代表任意字符都可以出現(xiàn)零次或多次,即資源名不限制\.代表匹配后綴分隔符.(html|...|css)
  • 代表匹配括號(hào)里所有靜態(tài)資源類型綜上所述,簡(jiǎn)單一句話概述:該配置表示匹配以.html~.css
為后綴的所有資源請(qǐng)求。
「最后提一嘴,也可以將靜態(tài)資源上傳到文件服務(wù)器中,然后location中配置一個(gè)新的upstream指向?!?/strong>

五、Nginx資源壓縮

建立在動(dòng)靜分離的基礎(chǔ)之上,如果一個(gè)靜態(tài)資源的Size越小,那么自然傳輸速度會(huì)更快,同時(shí)也會(huì)更節(jié)省帶寬,因此我們?cè)诓渴痦?xiàng)目時(shí),也可以通過Nginx對(duì)于靜態(tài)資源實(shí)現(xiàn)壓縮傳輸,一方面可以節(jié)省帶寬資源,第二方面也可以加快響應(yīng)速度并提升系統(tǒng)整體吞吐。在Nginx也提供了三個(gè)支持資源壓縮的模塊ngx_http_gzip_module、ngx_http_gzip_static_module、ngx_http_gunzip_module,其中ngx_http_gzip_module屬于內(nèi)置模塊,代表著可以直接使用該模塊下的一些壓縮指令,后續(xù)的資源壓縮操作都基于該模塊,先來(lái)看看壓縮配置的一些參數(shù)/指令:
圖片
了解了Nginx中的基本壓縮配置后,接下來(lái)可以在Nginx中簡(jiǎn)單配置一下:

http{
    # 開啟壓縮機(jī)制
    gzip on;
    # 指定會(huì)被壓縮的文件類型(也可自己配置其他類型)
    gzip_types text/plain application/javascript text/css application/xml text/javascript image/jpeg image/gif image/png;
    # 設(shè)置壓縮級(jí)別,越高資源消耗越大,但壓縮效果越好
    gzip_comp_level 5;
    # 在頭部中添加Vary: Accept-Encoding(建議開啟)
    gzip_vary on;
    # 處理壓縮請(qǐng)求的緩沖區(qū)數(shù)量和大小
    gzip_buffers 16 8k;
    # 對(duì)于不支持壓縮功能的客戶端請(qǐng)求不開啟壓縮機(jī)制
    gzip_disable 'MSIE [1-6]\.'; # 低版本的IE瀏覽器不支持壓縮
    # 設(shè)置壓縮響應(yīng)所支持的HTTP最低版本
    gzip_http_version 1.1;
    # 設(shè)置觸發(fā)壓縮的最小閾值
    gzip_min_length 2k;
    # 關(guān)閉對(duì)后端服務(wù)器的響應(yīng)結(jié)果進(jìn)行壓縮
    gzip_proxied off;
}

在上述的壓縮配置中,最后一個(gè)gzip_proxied選項(xiàng),可以根據(jù)系統(tǒng)的實(shí)際情況決定,總共存在多種選項(xiàng):off:關(guān)閉Nginx對(duì)后臺(tái)服務(wù)器的響應(yīng)結(jié)果進(jìn)行壓縮。
  • expired:如果響應(yīng)頭中包含Expires信息,則開啟壓縮。

  • no-cache:如果響應(yīng)頭中包含Cache-Control:no-cache信息,則開啟壓縮。

  • no-store:如果響應(yīng)頭中包含Cache-Control:no-store信息,則開啟壓縮。

  • private:如果響應(yīng)頭中包含Cache-Control:private信息,則開啟壓縮。

  • no_last_modified:如果響應(yīng)頭中不包含Last-Modified信息,則開啟壓縮。

  • no_etag:如果響應(yīng)頭中不包含ETag信息,則開啟壓縮。

  • auth:如果響應(yīng)頭中包含Authorization信息,則開啟壓縮。

  • any:無(wú)條件對(duì)后端的響應(yīng)結(jié)果開啟壓縮機(jī)制。

OK~,簡(jiǎn)單修改好了Nginx的壓縮配置后,可以在原本的index頁(yè)面中引入一個(gè)jquery-3.6.0.js文件:<script type='text/javascript' src='jquery-3.6.0.js'></script>  分別來(lái)對(duì)比下壓縮前后的區(qū)別:
圖片
從圖中可以很明顯看出,未開啟壓縮機(jī)制前訪問時(shí),js文件的原始大小為230K,當(dāng)配置好壓縮后再重啟Nginx,會(huì)發(fā)現(xiàn)文件大小從230KB→69KB,效果立竿見影!
?
注意點(diǎn):①對(duì)于圖片、視頻類型的數(shù)據(jù),會(huì)默認(rèn)開啟壓縮機(jī)制,因此一般無(wú)需再次開啟壓縮。②對(duì)于.js文件而言,需要指定壓縮類型為application/javascript,而并非text/javascript、application/x-javascript。
?

六、Nginx緩沖區(qū)

先來(lái)思考一個(gè)問題,接入Nginx的項(xiàng)目一般請(qǐng)求流程為:“客戶端→Nginx→服務(wù)端”,在這個(gè)過程中存在兩個(gè)連接:“客戶端→Nginx、Nginx→服務(wù)端”,那么兩個(gè)不同的連接速度不一致,就會(huì)影響用戶的體驗(yàn)(比如瀏覽器的加載速度跟不上服務(wù)端的響應(yīng)速度)。

其實(shí)也就類似電腦的內(nèi)存跟不上CPU速度,所以對(duì)于用戶造成的體驗(yàn)感極差,因此在CPU設(shè)計(jì)時(shí)都會(huì)加入三級(jí)高速緩沖區(qū),用于緩解CPU和內(nèi)存速率不一致的矛盾。在Nginx也同樣存在緩沖區(qū)的機(jī)制,主要目的就在于:「「用來(lái)解決兩個(gè)連接之間速度不匹配造成的問題」」 ,有了緩沖后,Nginx代理可暫存后端的響應(yīng),然后按需供給數(shù)據(jù)給客戶端。先來(lái)看看一些關(guān)于緩沖區(qū)的配置項(xiàng):

proxy_buffering:是否啟用緩沖機(jī)制,默認(rèn)為on關(guān)閉狀態(tài)。

  • client_body_buffer_size:設(shè)置緩沖客戶端請(qǐng)求數(shù)據(jù)的內(nèi)存大小。
  • proxy_buffers:為每個(gè)請(qǐng)求/連接設(shè)置緩沖區(qū)的數(shù)量和大小,默認(rèn)4 4k/8k。
  • proxy_buffer_size:設(shè)置用于存儲(chǔ)響應(yīng)頭的緩沖區(qū)大小。
  • proxy_busy_buffers_size:在后端數(shù)據(jù)沒有完全接收完成時(shí),Nginx可以將busy狀態(tài)的緩沖返回給客戶端,該參數(shù)用來(lái)設(shè)置busy狀態(tài)的buffer具體有多大,默認(rèn)為proxy_buffer_size*2。
  • proxy_temp_path:當(dāng)內(nèi)存緩沖區(qū)存滿時(shí),可以將數(shù)據(jù)臨時(shí)存放到磁盤,該參數(shù)是設(shè)置存儲(chǔ)緩沖數(shù)據(jù)的目錄。
  • path是臨時(shí)目錄的路徑。
    語(yǔ)法:proxy_temp_path path;
     path是臨時(shí)目錄的路徑
  • proxy_temp_file_write_size:設(shè)置每次寫數(shù)據(jù)到臨時(shí)文件的大小限制。
  • proxy_max_temp_file_size:設(shè)置臨時(shí)的緩沖目錄中允許存儲(chǔ)的最大容量。
  • 非緩沖參數(shù)項(xiàng):
  • proxy_connect_timeout:設(shè)置與后端服務(wù)器建立連接時(shí)的超時(shí)時(shí)間。
    • proxy_read_timeout:設(shè)置從后端服務(wù)器讀取響應(yīng)數(shù)據(jù)的超時(shí)時(shí)間。
    • proxy_send_timeout:設(shè)置向后端服務(wù)器傳輸請(qǐng)求數(shù)據(jù)的超時(shí)時(shí)間。
具體的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ù),是基于每個(gè)請(qǐng)求分配的空間,而并不是所有請(qǐng)求的共享空間。當(dāng)然,具體的參數(shù)值還需要根據(jù)業(yè)務(wù)去決定,要綜合考慮機(jī)器的內(nèi)存以及每個(gè)請(qǐng)求的平均數(shù)據(jù)大小。

?
最后提一嘴:使用緩沖也可以減少即時(shí)傳輸帶來(lái)的帶寬消耗。
?

七、Nginx緩存機(jī)制

對(duì)于性能優(yōu)化而言,緩存是一種能夠大幅度提升性能的方案,因此幾乎可以在各處都能看見緩存,如客戶端緩存、代理緩存、服務(wù)器緩存等等,Nginx的緩存則屬于代理緩存的一種。對(duì)于整個(gè)系統(tǒng)而言,加入緩存帶來(lái)的優(yōu)勢(shì)額外明顯:減少了再次向后端或文件服務(wù)器請(qǐng)求資源的帶寬消耗。降低了下游服務(wù)器的訪問壓力,提升系統(tǒng)整體吞吐??s短了響應(yīng)時(shí)間,提升了加載速度,打開頁(yè)面的速度更快。那么在Nginx中,又該如何配置代理緩存呢?先來(lái)看看緩存相關(guān)的配置項(xiàng):「proxy_cache_path」:代理緩存的路徑。
語(yǔ)法:
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];
是的,你沒有看錯(cuò),就是這么長(zhǎng)....,解釋一下每個(gè)參數(shù)項(xiàng)的含義:path:緩存的路徑地址。
  • levels:緩存存儲(chǔ)的層次結(jié)構(gòu),最多允許三層目錄。
  • use_temp_path:是否使用臨時(shí)目錄。
  • keys_zone:指定一個(gè)共享內(nèi)存空間來(lái)存儲(chǔ)熱點(diǎn)Key(1M可存儲(chǔ)8000個(gè)Key)。
  • inactive:設(shè)置緩存多長(zhǎng)時(shí)間未被訪問后刪除(默認(rèn)是十分鐘)。
  • max_size:允許緩存的最大存儲(chǔ)空間,超出后會(huì)基于LRU算法移除緩存,Nginx會(huì)創(chuàng)建一個(gè)Cache manager的進(jìn)程移除數(shù)據(jù),也可以通過purge方式。
  • manager_files:manager進(jìn)程每次移除緩存文件數(shù)量的上限。
  • manager_sleep:manager進(jìn)程每次移除緩存文件的時(shí)間上限。
  • manager_threshold:manager進(jìn)程每次移除緩存后的間隔時(shí)間。
  • loader_files:重啟Nginx載入緩存時(shí),每次加載的個(gè)數(shù),默認(rèn)100。
  • loader_sleep:每次載入時(shí),允許的最大時(shí)間上限,默認(rèn)200ms。
  • loader_threshold:一次載入后,停頓的時(shí)間間隔,默認(rèn)50ms。
  • purger:是否開啟purge方式移除數(shù)據(jù)。
  • purger_files:每次移除緩存文件時(shí)的數(shù)量。
  • purger_sleep:每次移除時(shí),允許消耗的最大時(shí)間。
  • purger_threshold:每次移除完成后,停頓的間隔時(shí)間。
「proxy_cache」:開啟或關(guān)閉代理緩存,開啟時(shí)需要指定一個(gè)共享內(nèi)存區(qū)域。
語(yǔ)法:
proxy_cache zone | off;
zone為內(nèi)存區(qū)域的名稱,即上面中keys_zone設(shè)置的名稱。
「proxy_cache_key」:定義如何生成緩存的鍵。
語(yǔ)法:
proxy_cache_key string;
string為生成Key的規(guī)則,如$scheme$proxy_host$request_uri。
「proxy_cache_valid」:緩存生效的狀態(tài)碼與過期時(shí)間。
語(yǔ)法:proxy_cache_valid [code ...] time;
code為狀態(tài)碼,time為有效時(shí)間,可以根據(jù)狀態(tài)碼設(shè)置不同的緩存時(shí)間。
例如:proxy_cache_valid 200 302 30m;
「proxy_cache_min_uses」:設(shè)置資源被請(qǐng)求多少次后被緩存。
語(yǔ)法:
proxy_cache_min_uses number;
number為次數(shù),默認(rèn)為1。
「proxy_cache_use_stale」:當(dāng)后端出現(xiàn)異常時(shí),是否允許Nginx返回緩存作為響應(yīng)。
語(yǔ)法:
proxy_cache_use_stale error;
error為錯(cuò)誤類型,可配置timeout|invalid_header|updating|http_500...。
「proxy_cache_lock」:對(duì)于相同的請(qǐng)求,是否開啟鎖機(jī)制,只允許一個(gè)請(qǐng)求發(fā)往后端。
語(yǔ)法:
proxy_cache_lock on | off;
「proxy_cache_lock_timeout」:配置鎖超時(shí)機(jī)制,超出規(guī)定時(shí)間后會(huì)釋放請(qǐng)求。
proxy_cache_lock_timeout time;
「proxy_cache_methods」:設(shè)置對(duì)于那些HTTP方法開啟緩存。
語(yǔ)法:
proxy_cache_methods method;
method為請(qǐng)求方法類型,如GET、HEAD等。
「proxy_no_cache」:定義不存儲(chǔ)緩存的條件,符合時(shí)不會(huì)保存。
語(yǔ)法:
proxy_no_cache string...;
string為條件,例如$cookie_nocache $arg_nocache $arg_comment;
「proxy_cache_bypass」:定義不讀取緩存的條件,符合時(shí)不會(huì)從緩存中讀取。
語(yǔ)法:

proxy_cache_bypass string...;

和上面proxy_no_cache的配置方法類似。

「add_header」:往響應(yīng)頭中添加字段信息。
語(yǔ)法:
add_header fieldName fieldValue;
「$upstream_cache_status」:記錄了緩存是否命中的信息,存在多種情況:
  • MISS:請(qǐng)求未命中緩存。
  • HIT:請(qǐng)求命中緩存。
  • EXPIRED:請(qǐng)求命中緩存但緩存已過期。
  • STALE:請(qǐng)求命中了陳舊緩存。
  • REVALIDDATED:Nginx驗(yàn)證陳舊緩存依然有效。
  • UPDATING:命中的緩存內(nèi)容陳舊,但正在更新緩存。
  • BYPASS:響應(yīng)結(jié)果是從原始服務(wù)器獲取的。
?
PS:這個(gè)和之前的不同,之前的都是參數(shù)項(xiàng),這個(gè)是一個(gè)Nginx內(nèi)置變量。
?
OK~,對(duì)于Nginx中的緩存配置項(xiàng)大概了解后,接著來(lái)配置一下Nginx代理緩存:

http{  
    # 設(shè)置緩存的目錄,并且內(nèi)存中緩存區(qū)名為hot_cache,大小為128m,  
    # 三天未被訪問過的緩存自動(dòng)清楚,磁盤中緩存的最大容量為2GB。  
    proxy_cache_path /soft/nginx/cache levels=1:2 
	keys_zone=hot_cache:128m
    inactive=3d
    max_size=2g;

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

接著來(lái)看一下效果,如下:

圖片
第一次訪問時(shí),因?yàn)檫€沒有請(qǐng)求過資源,所以緩存中沒有數(shù)據(jù),因此沒有命中緩存。第二、三次,依舊沒有命中緩存,直至第四次時(shí)才顯示命中,這是為什么呢?因?yàn)樵谇懊娴木彺媾渲弥?,我們配置了加入緩存的最低條件為:「「資源至少要被請(qǐng)求三次以上才會(huì)加入緩存?!埂?/strong> 這樣可以避免很多無(wú)效緩存占用空間。

緩存清理

當(dāng)緩存過多時(shí),如果不及時(shí)清理會(huì)導(dǎo)致磁盤空間被“吃光”,因此我們需要一套完善的緩存清理機(jī)制去刪除緩存,在之前的proxy_cache_path參數(shù)中有purger相關(guān)的選項(xiàng),開啟后可以幫我們自動(dòng)清理緩存,但遺憾的是:**purger系列參數(shù)只有商業(yè)版的NginxPlus才能使用,因此需要付費(fèi)才可使用。**不過天無(wú)絕人之路,我們可以通過強(qiáng)大的第三方模塊ngx_cache_purge
來(lái)替代,先來(lái)安裝一下該插件:①首先去到Nginx的安裝目錄下,創(chuàng)建一個(gè)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  
④重新構(gòu)建一次Nginx,通過--add-module的指令添加剛剛的第三方模塊:
[root@localhost]# ./configure --prefix=/soft/nginx/ --add-module=/soft/nginx/cache_purge/ngx_cache_purge-2.3/  
⑤重新根據(jù)剛剛構(gòu)建的Nginx,再次編譯一下,「但切記不要make install :
[root@localhost]# make  
⑥刪除之前Nginx的啟動(dòng)文件,不放心的也可以移動(dòng)到其他位置:
[root@localhost]# rm -rf /soft/nginx/sbin/nginx  
⑦從生成的objs目錄中,重新復(fù)制一個(gè)Nginx的啟動(dòng)文件到原來(lái)的位置:
[root@localhost]# cp objs/nginx /soft/nginx/sbin/nginx  
至此,第三方緩存清除模塊ngx_cache_purge就安裝完成了,接下來(lái)稍微修改一下nginx.conf
配置,再添加一條location
規(guī)則:

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

然后再重啟Nginx,接下來(lái)即可通過http://xxx/purge/xx的方式清除緩存。

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

有時(shí)候往往有些需求,可能某些接口只能開放給對(duì)應(yīng)的合作商,或者購(gòu)買/接入API的合作伙伴,那么此時(shí)就需要實(shí)現(xiàn)類似于IP白名單的功能。而有時(shí)候有些惡意攻擊者或爬蟲程序,被識(shí)別后需要禁止其再次訪問網(wǎng)站,因此也需要實(shí)現(xiàn)IP黑名單。那么這些功能無(wú)需交由后端實(shí)現(xiàn),可直接在Nginx中處理。Nginx做黑白名單機(jī)制,主要是通過allow、deny配置項(xiàng)來(lái)實(shí)現(xiàn):
allow xxx.xxx.xxx.xxx; # 允許指定的IP訪問,可以用于實(shí)現(xiàn)白名單。  
deny xxx.xxx.xxx.xxx; # 禁止指定的IP訪問,可以用于實(shí)現(xiàn)黑名單。  
要同時(shí)屏蔽/開放多個(gè)IP訪問時(shí),如果所有IP全部寫在nginx.conf
文件中定然是不顯示的,這種方式比較冗余,那么可以新建兩個(gè)文件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
添加到對(duì)應(yīng)的文件后,可以再將這兩個(gè)文件在nginx.conf中導(dǎo)入:

http{  
    # 屏蔽該文件中的所有IP  
    include /soft/nginx/IP/BlocksIP.conf;   
 server{  
    location xxx {  
        # 某一系列接口只開放給白名單中的IP  
        include /soft/nginx/IP/blockip.conf;   
    }  
 }  
}

對(duì)于文件具體在哪兒導(dǎo)入,這個(gè)也并非隨意的,如果要整站屏蔽/開放就在http中導(dǎo)入,如果只需要一個(gè)域名下屏蔽/開放就在sever中導(dǎo)入,如果只需要針對(duì)于某一系列接口屏蔽/開放IP

,那么就在location中導(dǎo)入。
?
當(dāng)然,上述只是最簡(jiǎn)單的IP黑/白名單實(shí)現(xiàn)方式,同時(shí)也可以通過ngx_http_geo_module、ngx_http_geo_module第三方庫(kù)去實(shí)現(xiàn)(這種方式可以按地區(qū)、國(guó)家進(jìn)行屏蔽,并且提供了IP庫(kù))。
?

九、Nginx跨域配置

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

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

產(chǎn)生跨域問題的主要原因就在于 「同源策略」 ,為了保證用戶信息安全,防止惡意網(wǎng)站竊取數(shù)據(jù),同源策略是必須的,否則cookie可以共享。由于http無(wú)狀態(tài)協(xié)議通常會(huì)借助cookie來(lái)實(shí)現(xiàn)有狀態(tài)的信息記錄,例如用戶的身份/密碼等,因此一旦cookie被共享,那么會(huì)導(dǎo)致用戶的身份信息被盜取。同源策略主要是指三點(diǎn)相同,「「協(xié)議+域名+端口」」 相同的兩個(gè)請(qǐng)求,則可以被看做是同源的,但如果其中任意一點(diǎn)存在不同,則代表是兩個(gè)不同源的請(qǐng)求,同源策略會(huì)限制了不同源之間的資源交互。

Nginx解決跨域問題

弄明白了跨域問題的產(chǎn)生原因,接下來(lái)看看Nginx中又該如何解決跨域呢?其實(shí)比較簡(jiǎn)單,在nginx.conf中稍微添加一點(diǎn)配置即可:

location / {  
    # 允許跨域的請(qǐng)求,可以自定義變量$http_origin,*表示所有  
    add_header 'Access-Control-Allow-Origin' *;  
    # 允許攜帶cookie請(qǐng)求  
    add_header 'Access-Control-Allow-Credentials' 'true';  
    # 允許跨域請(qǐng)求的方法:GET,POST,OPTIONS,PUT  
    add_header 'Access-Control-Allow-Methods' 'GET,POST,OPTIONS,PUT';  
    # 允許請(qǐng)求時(shí)攜帶的頭部信息,*表示所有  
    add_header 'Access-Control-Allow-Headers' *;  
    # 允許發(fā)送按段獲取資源的請(qǐng)求  
    add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range';  
    # 一定要有?。?!否則Post請(qǐng)求無(wú)法進(jìn)行跨域!  
    # 在發(fā)送Post跨域請(qǐng)求前,會(huì)以O(shè)ptions方式發(fā)送預(yù)檢請(qǐng)求,服務(wù)器接受時(shí)才會(huì)正式請(qǐng)求  
    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;  
        # 對(duì)于Options方式的請(qǐng)求返回204,表示接受跨域請(qǐng)求  
        return 204;  
    }  
}
在nginx.conf文件加上如上配置后,跨域請(qǐng)求即可生效了。
?
但如果后端是采用分布式架構(gòu)開發(fā)的,有時(shí)候RPC調(diào)用也需要解決跨域問題,不然也同樣會(huì)出現(xiàn)無(wú)法跨域請(qǐng)求的異常,因此可以在你的后端項(xiàng)目中,通過繼承HandlerInterceptorAdapter
類、實(shí)現(xiàn)WebMvcConfigurer接口、添加@CrossOrgin注解的方式實(shí)現(xiàn)接口之間的跨域配置。
?

十、Nginx防盜鏈設(shè)計(jì)

首先了解一下何謂盜鏈:「「盜鏈即是指外部網(wǎng)站引入當(dāng)前網(wǎng)站的資源對(duì)外展示」」 ,來(lái)舉個(gè)簡(jiǎn)單的例子理解:

?

好比壁紙網(wǎng)站X站、Y站,X站是一點(diǎn)點(diǎn)去購(gòu)買版權(quán)、簽約作者的方式,從而積累了海量的壁紙素材,但Y站由于資金等各方面的原因,就直接通過<img src='X站/xxx.jpg' />這種方式照搬了X站的所有壁紙資源,繼而提供給用戶下載。
?
那么如果我們自己是這個(gè)X站的Boss,心中必然不爽,那么此時(shí)又該如何屏蔽這類問題呢?那么接下來(lái)要敘說的「「防盜鏈」」 登場(chǎng)了!
Nginx的防盜鏈機(jī)制實(shí)現(xiàn),跟一個(gè)頭部字段:Referer有關(guān),該字段主要描述了當(dāng)前請(qǐng)求是從哪兒發(fā)出的,那么在Nginx中就可獲取該值,然后判斷是否為本站的資源引用請(qǐng)求,如果不是則不允許訪問。Nginx中存在一個(gè)配置項(xiàng)為valid_referers,正好可以滿足前面的需求,語(yǔ)法如下:
valid_referers none | blocked | server_names | string ...;
  • none:表示接受沒有Referer字段的HTTP請(qǐng)求訪問。

  • blocked:表示允許http://https//以外的請(qǐng)求訪問。

  • server_names:資源的白名單,這里可以指定允許訪問的域名。

  • string:可自定義字符串,支配通配符、正則表達(dá)式寫法。

簡(jiǎn)單了解語(yǔ)法后,接下來(lái)的實(shí)現(xiàn)如下:

# 在動(dòng)靜分離的location中開啟防盜鏈機(jī)制  
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./NO.jpg;  
        # 也可直接返回403  
        return   403;  
    }  
      
    root   /soft/nginx/static_resources;  
    expires 7d;  
}

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

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

十一、Nginx大文件傳輸配置

在某些業(yè)務(wù)場(chǎng)景中需要傳輸一些大文件,但大文件傳輸時(shí)往往都會(huì)會(huì)出現(xiàn)一些Bug,比如文件超出限制、文件傳輸過程中請(qǐng)求超時(shí)等,那么此時(shí)就可以在Nginx稍微做一些配置,先來(lái)了解一些關(guān)于大文件傳輸時(shí)可能會(huì)用的配置項(xiàng):
圖片
在傳輸大文件時(shí),client_max_body_size、client_header_timeout、proxy_read_timeout
、proxy_send_timeout這四個(gè)參數(shù)值都可以根據(jù)自己項(xiàng)目的實(shí)際情況來(lái)配置。
?
上述配置僅是作為代理層需要配置的,因?yàn)樽罱K客戶端傳輸文件還是直接與后端進(jìn)行交互,這里只是把作為網(wǎng)關(guān)層的Nginx配置調(diào)高一點(diǎn),調(diào)到能夠“容納大文件”傳輸?shù)某潭取.?dāng)然,Nginx中也可以作為文件服務(wù)器使用,但需要用到一個(gè)專門的第三方模塊nginx-upload-module,如果項(xiàng)目中文件上傳的作用處不多,那么建議可以通過Nginx搭建,畢竟可以節(jié)省一臺(tái)文件服務(wù)器資源。但如若文件上傳/下載較為頻繁,那么還是建議額外搭建文件服務(wù)器,并將上傳/下載功能交由后端處理。
?

十二、Nginx配置SLL證書

隨著越來(lái)越多的網(wǎng)站接入HTTPS,因此Nginx中僅配置HTTP還不夠,往往還需要監(jiān)聽443
端口的請(qǐng)求,HTTPS為了確保通信安全,所以服務(wù)端需配置對(duì)應(yīng)的數(shù)字證書,當(dāng)項(xiàng)目使用Nginx作為網(wǎng)關(guān)時(shí),那么證書在Nginx中也需要配置,接下來(lái)簡(jiǎn)單聊一下關(guān)于SSL證書配置過程:
①先去CA機(jī)構(gòu)或從云控制臺(tái)中申請(qǐng)對(duì)應(yīng)的SSL證書,審核通過后下載Nginx
版本的證書。
②下載數(shù)字證書后,完整的文件總共有三個(gè):.crt、.key、.pem:.crt:數(shù)字證書文件,.crt
  • 是.pem的拓展文件,因此有些人下載后可能沒有。.key:服務(wù)器的私鑰文件,及非對(duì)稱加密的私鑰,用于解密公鑰傳輸?shù)臄?shù)據(jù)。.pem:Base64-encoded編碼格式的源證書文本文件,可自行根需求修改拓展名。
③在Nginx目錄下新建certificate目錄,并將下載好的證書/私鑰等文件上傳至該目錄。
④最后修改一下nginx.conf文件即可,如下:

# ----------HTTPS配置-----------  
server {  
    # 監(jiān)聽HTTPS默認(rèn)的443端口  
    listen 443;  
    # 配置自己項(xiàng)目的域名  
    server_name www.x;  
    # 打開SSL加密傳輸  
    ssl on;  
    # 輸入域名后,首頁(yè)文件所在的目錄  
    root html;  
    # 配置首頁(yè)的文件名  
    index index.html index.htm index.jsp index.ftl;  
    # 配置自己下載的數(shù)字證書  
    ssl_certificate  certificate/xxx.pem;  
    # 配置自己下載的服務(wù)器私鑰  
    ssl_certificate_key certificate/xxx.key;  
    # 停止通信時(shí),加密會(huì)話的有效期,在該時(shí)間段內(nèi)不需要重新交換密鑰  
    ssl_session_timeout 5m;  
    # TLS握手時(shí),服務(wù)器采用的密碼套件  
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;  
    # 服務(wù)器支持的TLS版本  
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;  
    # 開啟由服務(wù)器決定采用的密碼套件  
    ssl_prefer_server_ciphers on;  
  
    location / {  
        ....  
    }  
}  
  
# ---------HTTP請(qǐng)求轉(zhuǎn)HTTPS-------------  
server {  
    # 監(jiān)聽HTTP默認(rèn)的80端口  
    listen 80;  
    # 如果80端口出現(xiàn)訪問該域名的請(qǐng)求  
    server_name www.x;  
    # 將請(qǐng)求改寫為HTTPS(這里寫你配置了HTTPS的域名)  
    rewrite ^(.*)$ https://www.x;  
}

OK~,根據(jù)如上配置了Nginx后,你的網(wǎng)站即可通過https://的方式訪問,并且當(dāng)客戶端使用

http://的方式訪問時(shí),會(huì)自動(dòng)將其改寫為HTTPS請(qǐng)求。十三、Nginx的高可用
線上如果采用單個(gè)節(jié)點(diǎn)的方式部署Nginx,難免會(huì)出現(xiàn)天災(zāi)人禍,比如系統(tǒng)異常、程序宕機(jī)、服務(wù)器斷電、機(jī)房爆炸、地球毀滅....哈哈哈,夸張了。但實(shí)際生產(chǎn)環(huán)境中確實(shí)存在隱患問題,由于Nginx作為整個(gè)系統(tǒng)的網(wǎng)關(guān)層接入外部流量,所以一旦Nginx宕機(jī),最終就會(huì)導(dǎo)致整個(gè)系統(tǒng)不可用,這無(wú)疑對(duì)于用戶的體驗(yàn)感是極差的,因此也得保障Nginx高可用的特性。
?
接下來(lái)則會(huì)通過keepalived的VIP機(jī)制,實(shí)現(xiàn)Nginx的高可用。VIP并不是只會(huì)員的意思,而是指Virtual IP,即虛擬IP。
?
keepalived在之前單體架構(gòu)開發(fā)時(shí),是一個(gè)用的較為頻繁的高可用技術(shù),比如MySQL、Redis、MQ、Proxy、Tomcat等各處都會(huì)通過keepalived提供的VIP機(jī)制,實(shí)現(xiàn)單節(jié)點(diǎn)應(yīng)用的高可用。

Keepalived+重啟腳本+雙機(jī)熱備搭建

①首先創(chuàng)建一個(gè)對(duì)應(yīng)的目錄并下載keepalived到Linux中并解壓:

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

②進(jìn)入解壓后的keepalived目錄并構(gòu)建安裝環(huán)境,然后編譯并安裝:

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

③進(jìn)入安裝目錄的/soft/keepalived/etc/keepalived/并編輯配置文件:

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

④編輯主機(jī)的keepalived.conf核心配置文件,如下:

global_defs {  
    # 自帶的郵件提醒服務(wù),建議用獨(dú)立的監(jiān)控或第三方SMTP,也可選擇配置郵件發(fā)送。  
    notification_email {  
        root@localhost  
    }  
    notification_email_from root@localhost  
    smtp_server localhost  
    smtp_connect_timeout 30  
    # 高可用集群主機(jī)身份標(biāo)識(shí)(集群中主機(jī)身份標(biāo)識(shí)名稱不能重復(fù),建議配置成本機(jī)IP)  
 router_id 192.168.12.129   
}  
  
# 定時(shí)運(yùn)行的腳本文件配置  
vrrp_script check_nginx_pid_restart {  
    # 之前編寫的nginx重啟腳本的所在位置  
 script '/soft/scripts/keepalived/check_nginx_pid_restart.sh'   
    # 每間隔3秒執(zhí)行一次  
 interval 3  
    # 如果腳本中的條件成立,重啟一次則權(quán)重-20  
 weight -20  
}  
  
# 定義虛擬路由,VI_1為虛擬路由的標(biāo)示符(可自定義名稱)  
vrrp_instance VI_1 {  
    # 當(dāng)前節(jié)點(diǎn)的身份標(biāo)識(shí):用來(lái)決定主從(MASTER為主機(jī),BACKUP為從機(jī))  
 state MASTER  
    # 綁定虛擬IP的網(wǎng)絡(luò)接口,根據(jù)自己的機(jī)器的網(wǎng)卡配置  
 interface ens33   
    # 虛擬路由的ID號(hào),主從兩個(gè)節(jié)點(diǎn)設(shè)置必須一樣  
 virtual_router_id 121  
    # 填寫本機(jī)IP  
 mcast_src_ip 192.168.12.129  
    # 節(jié)點(diǎn)權(quán)重優(yōu)先級(jí),主節(jié)點(diǎn)要比從節(jié)點(diǎn)優(yōu)先級(jí)高  
 priority 100  
    # 優(yōu)先級(jí)高的設(shè)置nopreempt,解決異?;謴?fù)后再次搶占造成的腦裂問題  
 nopreempt  
    # 組播信息發(fā)送間隔,兩個(gè)節(jié)點(diǎn)設(shè)置必須一樣,默認(rèn)1s(類似于心跳檢測(cè))  
 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),也可擴(kuò)展,可配置多個(gè)。  
  192.168.12.111  
    }  
}

⑤克隆一臺(tái)之前的虛擬機(jī)作為從(備)機(jī),編輯從機(jī)的keepalived.conf文件,如下:

global_defs {  
    # 自帶的郵件提醒服務(wù),建議用獨(dú)立的監(jiān)控或第三方SMTP,也可選擇配置郵件發(fā)送。  
    notification_email {  
        root@localhost  
    }  
    notification_email_from root@localhost  
    smtp_server localhost  
    smtp_connect_timeout 30  
    # 高可用集群主機(jī)身份標(biāo)識(shí)(集群中主機(jī)身份標(biāo)識(shí)名稱不能重復(fù),建議配置成本機(jī)IP)  
 router_id 192.168.12.130   
}  
  
# 定時(shí)運(yùn)行的腳本文件配置  
vrrp_script check_nginx_pid_restart {  
    # 之前編寫的nginx重啟腳本的所在位置  
 script '/soft/scripts/keepalived/check_nginx_pid_restart.sh'   
    # 每間隔3秒執(zhí)行一次  
 interval 3  
    # 如果腳本中的條件成立,重啟一次則權(quán)重-20  
 weight -20  
}  
  
# 定義虛擬路由,VI_1為虛擬路由的標(biāo)示符(可自定義名稱)  
vrrp_instance VI_1 {  
    # 當(dāng)前節(jié)點(diǎn)的身份標(biāo)識(shí):用來(lái)決定主從(MASTER為主機(jī),BACKUP為從機(jī))  
 state BACKUP  
    # 綁定虛擬IP的網(wǎng)絡(luò)接口,根據(jù)自己的機(jī)器的網(wǎng)卡配置  
 interface ens33   
    # 虛擬路由的ID號(hào),主從兩個(gè)節(jié)點(diǎn)設(shè)置必須一樣  
 virtual_router_id 121  
    # 填寫本機(jī)IP  
 mcast_src_ip 192.168.12.130  
    # 節(jié)點(diǎn)權(quán)重優(yōu)先級(jí),主節(jié)點(diǎn)要比從節(jié)點(diǎn)優(yōu)先級(jí)高  
 priority 90  
    # 優(yōu)先級(jí)高的設(shè)置nopreempt,解決異常恢復(fù)后再次搶占造成的腦裂問題  
 nopreempt  
    # 組播信息發(fā)送間隔,兩個(gè)節(jié)點(diǎn)設(shè)置必須一樣,默認(rèn)1s(類似于心跳檢測(cè))  
 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),也可擴(kuò)展,可配置多個(gè)。  
  192.168.12.111  
    }  
}

⑥新建scripts目錄并編寫Nginx的重啟腳本,check_nginx_pid_restart.sh:

#!/bin/sh  
# 通過ps指令查詢后臺(tái)的nginx進(jìn)程數(shù),并將其保存在變量nginx_number中  
nginx_number=`ps -C nginx --no-header | wc -l`  
# 判斷后臺(tái)是否還有Nginx進(jìn)程在運(yùn)行  
if [ $nginx_number -eq 0 ];then  
    # 如果后臺(tái)查詢不到`Nginx`進(jìn)程存在,則執(zhí)行重啟指令  
    /soft/nginx/sbin/nginx -c /soft/nginx/conf/nginx.conf  
    # 重啟后等待1s后,再次查詢后臺(tái)進(jìn)程數(shù)  
    sleep 1  
    # 如果重啟后依舊無(wú)法查詢到nginx進(jìn)程  
    if [ `ps -C nginx --no-header | wc -l` -eq 0 ];then  
        # 將keepalived主機(jī)下線,將虛擬IP漂移給從機(jī),從機(jī)上線接管Nginx服務(wù)  
        systemctl stop keepalived.service  
    fi  
fi

⑦編寫的腳本文件需要更改編碼格式,并賦予執(zhí)行權(quán)限,否則可能執(zhí)行失?。?/p>

[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時(shí),是自定義的安裝位置,因此需要拷貝一些文件到系統(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)服務(wù)并設(shè)置開啟自啟動(dòng),然后測(cè)試啟動(dò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 # 禁止開機(jī)自動(dòng)啟動(dòng)  
systemctl restart keepalived.service # 重啟keepalived  
systemctl stop keepalived.service # 停止keepalived  
tail -f /var/log/messages # 查看keepalived運(yùn)行時(shí)日志

⑩最后測(cè)試一下VIP是否生效,通過查看本機(jī)是否成功掛載虛擬IP:

[root@localhost]# ip addr  
圖片
虛擬IP-VIP
?
從上圖中可以明顯看見虛擬IP已經(jīng)成功掛載,但另外一臺(tái)機(jī)器192.168.12.130
并不會(huì)掛載這個(gè)虛擬IP,只有當(dāng)主機(jī)下線后,作為從機(jī)的192.168.12.130
才會(huì)上線,接替VIP。最后測(cè)試一下外網(wǎng)是否可以正常與VIP通信,即在Windows
中直接ping VIP:
?
圖片
Ping-VIP外部通過VIP通信時(shí),也可以正常Ping通,代表虛擬IP配置成功。

Nginx高可用性測(cè)試

經(jīng)過上述步驟后,keepalived的VIP機(jī)制已經(jīng)搭建成功,在上個(gè)階段中主要做了幾件事:
  • 一、為部署Nginx的機(jī)器掛載了VIP。
  • 二、通過keepalived搭建了主從雙機(jī)熱備。
  • 三、通過keepalived實(shí)現(xiàn)了Nginx宕機(jī)重啟。由于前面沒有域名的原因,因此最初server_name
配置的是當(dāng)前機(jī)器的IP,所以需稍微更改一下nginx.conf的配置:

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

最后來(lái)實(shí)驗(yàn)一下效果:

圖片
Nginx宕機(jī)
?
在上述過程中,首先分別啟動(dòng)了keepalived、nginx服務(wù),然后通過手動(dòng)停止nginx的方式模擬了Nginx宕機(jī)情況,過了片刻后再次查詢后臺(tái)進(jìn)程,我們會(huì)發(fā)現(xiàn)nginx依舊存活。
?
從這個(gè)過程中不難發(fā)現(xiàn),keepalived已經(jīng)為我們實(shí)現(xiàn)了Nginx
宕機(jī)后自動(dòng)重啟的功能,那么接著再模擬一下服務(wù)器出現(xiàn)故障時(shí)的情況:
圖片
服務(wù)器故障
?
在上述過程中,我們通過手動(dòng)關(guān)閉keepalived服務(wù)模擬了機(jī)器斷電、硬件損壞等情況(因?yàn)闄C(jī)器斷電等情況=主機(jī)中的keepalived進(jìn)程消失),然后再次查詢了一下本機(jī)的IP信息,很明顯會(huì)看到VIP消失了!
?
現(xiàn)在再切換到另外一臺(tái)機(jī)器:192.168.12.130來(lái)看看情況:
圖片
130的IP情況
?
此刻我們會(huì)發(fā)現(xiàn),在主機(jī)192.168.12.129宕機(jī)后,VIP自動(dòng)從主機(jī)飄移到了從機(jī)192.168.12.130上,而此時(shí)客戶端的請(qǐng)求就最終會(huì)來(lái)到130這臺(tái)機(jī)器的Nginx上。
?
「「最終,利用Keepalived對(duì)Nginx做了主從熱備之后,無(wú)論是遇到線上宕機(jī)還是機(jī)房斷電等各類故障時(shí),都能夠確保應(yīng)用系統(tǒng)能夠?yàn)橛脩籼峁?/strong>7x24小時(shí)服務(wù)?!埂?/strong>

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

到這里文章的篇幅較長(zhǎng)了,最后再來(lái)聊一下關(guān)于Nginx的性能優(yōu)化,主要就簡(jiǎn)單說說收益最高的幾個(gè)優(yōu)化項(xiàng),在這塊就不再展開敘述了,畢竟影響性能都有多方面原因?qū)е碌模热缇W(wǎng)絡(luò)、服務(wù)器硬件、操作系統(tǒng)、后端服務(wù)、程序自身、數(shù)據(jù)庫(kù)服務(wù)等。

優(yōu)化一:打開長(zhǎng)連接配置

通常Nginx作為代理服務(wù),負(fù)責(zé)分發(fā)客戶端的請(qǐng)求,那么建議開啟HTTP長(zhǎng)連接,用戶減少握手的次數(shù),降低服務(wù)器損耗,具體如下:

upstream xxx {  
    # 長(zhǎng)連接數(shù)  
    keepalive 32;  
    # 每個(gè)長(zhǎng)連接提供的最大請(qǐng)求數(shù)  
    keepalived_requests 100;  
    # 每個(gè)長(zhǎng)連接沒有新的請(qǐng)求時(shí),保持的最長(zhǎng)時(shí)間  
    keepalive_timeout 60s;  
}

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

零拷貝這個(gè)概念,在大多數(shù)性能較為不錯(cuò)的中間件中都有出現(xiàn),例如Kafka、Netty
等,而Nginx中也可以配置數(shù)據(jù)零拷貝技術(shù),如下:
sendfile on; # 開啟零拷貝機(jī)制  
零拷貝讀取機(jī)制與傳統(tǒng)資源讀取機(jī)制的區(qū)別:
  • 「?jìng)鹘y(tǒng)方式:」 硬件-->內(nèi)核-->用戶空間-->程序空間-->程序內(nèi)核空間-->網(wǎng)絡(luò)套接字

  • 「零拷貝方式:」 硬件-->內(nèi)核-->程序內(nèi)核空間-->網(wǎng)絡(luò)套接字

從上述這個(gè)過程對(duì)比,很輕易就能看出兩者之間的性能區(qū)別。

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

在Nginx中有兩個(gè)較為關(guān)鍵的性能參數(shù),即tcp_nodelay、tcp_nopush,開啟方式如下:
tcp_nodelay on;  tcp_nopush on;  TCP/IP協(xié)議中默認(rèn)是采用了Nagle算法的,即在網(wǎng)絡(luò)數(shù)據(jù)傳輸過程中,每個(gè)數(shù)據(jù)報(bào)文并不會(huì)立馬發(fā)送出去,而是會(huì)等待一段時(shí)間,將后面的幾個(gè)數(shù)據(jù)包一起組合成一個(gè)數(shù)據(jù)報(bào)文發(fā)送,但這個(gè)算法雖然提高了網(wǎng)絡(luò)吞吐量,但是實(shí)時(shí)性卻降低了。
?
因此你的項(xiàng)目屬于交互性很強(qiáng)的應(yīng)用,那么可以手動(dòng)開啟tcp_nodelay配置,讓應(yīng)用程序向內(nèi)核遞交的每個(gè)數(shù)據(jù)包都會(huì)立即發(fā)送出去。但這樣會(huì)產(chǎn)生大量的TCP報(bào)文頭,增加很大的網(wǎng)絡(luò)開銷。
?
相反,有些項(xiàng)目的業(yè)務(wù)對(duì)數(shù)據(jù)的實(shí)時(shí)性要求并不高,追求的則是更高的吞吐,那么則可以開啟tcp_nopush配置項(xiàng),這個(gè)配置就類似于“塞子”的意思,首先將連接塞住,使得數(shù)據(jù)先不發(fā)出去,等到拔去塞子后再發(fā)出去。設(shè)置該選項(xiàng)后,內(nèi)核會(huì)盡量把小數(shù)據(jù)包拼接成一個(gè)大的數(shù)據(jù)包(一個(gè)MTU)再發(fā)送出去.
?
當(dāng)然若一定時(shí)間后(一般為200ms),內(nèi)核仍然沒有積累到一個(gè)MTU的量時(shí),也必須發(fā)送現(xiàn)有的數(shù)據(jù),否則會(huì)一直阻塞。
?
tcp_nodelay、tcp_nopush兩個(gè)參數(shù)是“互斥”的,如果追求響應(yīng)速度的應(yīng)用推薦開啟tcp_nodelay參數(shù),如IM、金融等類型的項(xiàng)目。如果追求吞吐量的應(yīng)用則建議開啟tcp_nopush參數(shù),如調(diào)度系統(tǒng)、報(bào)表系統(tǒng)等。
?

注意:①tcp_nodelay一般要建立在開啟了長(zhǎng)連接模式的情況下使用。

②tcp_nopush參數(shù)是必須要開啟sendfile參數(shù)才可使用的。

?

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

Nginx啟動(dòng)后默認(rèn)只會(huì)開啟一個(gè)Worker工作進(jìn)程處理客戶端請(qǐng)求,而我們可以根據(jù)機(jī)器的CPU核數(shù)開啟對(duì)應(yīng)數(shù)量的工作進(jìn)程,以此來(lái)提升整體的并發(fā)量支持,如下:
# 自動(dòng)根據(jù)CPU核心數(shù)調(diào)整Worker進(jìn)程數(shù)量  
worker_processes auto;  
?
工作進(jìn)程的數(shù)量最高開到8個(gè)就OK了,8個(gè)之后就不會(huì)有再大的性能提升。
?
同時(shí)也可以稍微調(diào)整一下每個(gè)工作進(jìn)程能夠打開的文件句柄數(shù):
# 每個(gè)Worker能打開的文件描述符,最少調(diào)整至1W以上,負(fù)荷較高建議2-3W  
worker_rlimit_nofile 20000;  
?
操作系統(tǒng)內(nèi)核(kernel)都是利用文件描述符來(lái)訪問文件,無(wú)論是打開、新建、讀取、寫入文件時(shí),都需要使用文件描述符來(lái)指定待操作的文件,因此該值越大,代表一個(gè)進(jìn)程能夠操作的文件越多(但不能超出內(nèi)核限制,最多建議3.8W左右為上限)。
?

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

對(duì)于并發(fā)編程較為熟悉的伙伴都知道,因?yàn)檫M(jìn)程/線程數(shù)往往都會(huì)遠(yuǎn)超出系統(tǒng)CPU的核心數(shù),因?yàn)椴僮飨到y(tǒng)執(zhí)行的原理本質(zhì)上是采用時(shí)間片切換機(jī)制,也就是一個(gè)CPU核心會(huì)在多個(gè)進(jìn)程之間不斷頻繁切換,造成很大的性能損耗。而CPU親和機(jī)制則是指將每個(gè)Nginx的工作進(jìn)程,綁定在固定的CPU核心上,從而減小CPU切換帶來(lái)的時(shí)間開銷和資源損耗,開啟方式如下:
worker_cpu_affinity auto;  

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

在最開始就提到過:Nginx、Redis都是基于多路復(fù)用模型去實(shí)現(xiàn)的程序,但最初版的多路復(fù)用模型select/poll最大只能監(jiān)聽1024個(gè)連接,而epoll則屬于select/poll接口的增強(qiáng)版,因此采用該模型能夠大程度上提升單個(gè)Worker的性能,如下:

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

?

這里對(duì)于select/poll/epoll模型就不展開細(xì)說了,后面的IO模型文章中會(huì)詳細(xì)剖析。
?

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

至此,Nginx的大部分內(nèi)容都已闡述完畢,關(guān)于最后一小節(jié)的性能優(yōu)化內(nèi)容,其實(shí)在前面就談到的動(dòng)靜分離、分配緩沖區(qū)、資源緩存、防盜鏈、資源壓縮等內(nèi)容,也都可歸納為性能優(yōu)化的方案。
?
最后,希望諸君收藏的同時(shí)不要忘了點(diǎn)個(gè)贊支持一下^_^,在此萬(wàn)分感謝!
?
你還有什么想要補(bǔ)充的嗎?

    本站是提供個(gè)人知識(shí)管理的網(wǎng)絡(luò)存儲(chǔ)空間,所有內(nèi)容均由用戶發(fā)布,不代表本站觀點(diǎn)。請(qǐng)注意甄別內(nèi)容中的聯(lián)系方式、誘導(dǎo)購(gòu)買等信息,謹(jǐn)防詐騙。如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容,請(qǐng)點(diǎn)擊一鍵舉報(bào)。
    轉(zhuǎn)藏 分享 獻(xiàn)花(0

    0條評(píng)論

    發(fā)表

    請(qǐng)遵守用戶 評(píng)論公約

    類似文章 更多