緩存清理

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

不過天無絕人之路，我們可以通過強大的第三方模塊ngx_cache_purge來替代，先來安裝一下該插件：①首先去到Nginx的安裝目錄下，創建一個cache_purge目錄：

[root@localhost]#mkdircache_purge&&cdcache_purge

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

[root@localhost]#wgethttps://github.com/FRiCKLE/ngx_cache_purge/archive/2.3.tar.gz
[root@localhost]#tar-xvzf2.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]#cpobjs/nginx/soft/nginx/sbin/nginx

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

location~/purge(/.*){
#配置可以執行清除操作的IP（線上可以配置成內網機器）
#allow127.0.0.1;#代表本機
allowall;#代表允許任意IP清除緩存
proxy_cache_purge$host$1$is_args$args;
}

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

八、Nginx實現IP黑白名單

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

Nginx做黑白名單機制，主要是通過allow、deny配置項來實現：

allowxxx.xxx.xxx.xxx;#允許指定的IP訪問，可以用于實現白名單。
denyxxx.xxx.xxx.xxx;#禁止指定的IP訪問，可以用于實現黑名單。

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

#--------黑名單：BlocksIP.conf---------
deny192.177.12.222;#屏蔽192.177.12.222訪問
deny192.177.44.201;#屏蔽192.177.44.201訪問
deny127.0.0.0/8;#屏蔽127.0.0.1到127.255.255.254網段中的所有IP訪問

#--------白名單：WhiteIP.conf---------
allow192.177.12.222;#允許192.177.12.222訪問
allow192.177.44.201;#允許192.177.44.201訪問
allow127.45.0.0/16;#允許127.45.0.1到127.45.255.254網段中的所有IP訪問
denyall;#除開上述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站由于資金等各方面的原因，就直接通過這種方式照搬了X站的所有壁紙資源，繼而提供給用戶下載。

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

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

valid_referersnone|blocked|server_names|string...;

none：表示接受沒有Referer字段的HTTP請求訪問。

blocked：表示允許http://或https//以外的請求訪問。

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：

.crt：數字證書文件，.crt是.pem的拓展文件，因此有些人下載后可能沒有。

.key：服務器的私鑰文件，及非對稱加密的私鑰，用于解密公鑰傳輸的數據。

.pem：Base64-encoded編碼格式的源證書文本文件，可自行根需求修改拓展名。

③在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-SHA256ECDHHIGH!aNULL!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]#wgethttps://www.keepalived.org/software/keepalived-2.2.4.tar.gz
[root@localhost]#tar-zxvfkeepalived-2.2.4.tar.gz

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

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

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

[root@localhost]#cd/soft/keepalived/etc/keepalived/
[root@localhost]#vikeepalived.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，解決異?；謴秃笤俅螕屨荚斐傻哪X裂問題  
 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-Cnginx--no-header|wc-l`
#判斷后臺是否還有Nginx進程在運行
if[$nginx_number-eq0];then
#如果后臺查詢不到`Nginx`進程存在，則執行重啟指令
/soft/nginx/sbin/nginx-c/soft/nginx/conf/nginx.conf
#重啟后等待1s后，再次查詢后臺進程數
sleep1
#如果重啟后依舊無法查詢到nginx進程
if[`ps-Cnginx--no-header|wc-l`-eq0];then
#將keepalived主機下線，將虛擬IP漂移給從機，從機上線接管Nginx服務
systemctlstopkeepalived.service
fi
fi

⑦編寫的腳本文件需要更改編碼格式，并賦予執行權限，否則可能執行失?。?/p>

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

:setfileformat=unix#在vi命令里面執行，修改編碼格式
:setff#查看修改后的編碼格式

[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]#chkconfigkeepalivedon
[root@localhost]#systemctldaemon-reload
[root@localhost]#systemctlenablekeepalived.service
[root@localhost]#systemctlstartkeepalived.service

其他命令：

systemctldisablekeepalived.service#禁止開機自動啟動
systemctlrestartkeepalived.service#重啟keepalived
systemctlstopkeepalived.service#停止keepalived
tail-f/var/log/messages#查看keepalived運行時日志

⑩最后測試一下VIP是否生效，通過查看本機是否成功掛載虛擬IP：

[root@localhost]#ipaddr

“

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

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

Nginx高可用性測試

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

一、為部署Nginx的機器掛載了VIP。

二、通過keepalived搭建了主從雙機熱備。

三、通過keepalived實現了Nginx宕機重啟。

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

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

最后來實驗一下效果：

“

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

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

“

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

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

“

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

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

十四、Nginx性能優化

到這里文章的篇幅較長了，最后再來聊一下關于Nginx的性能優化，主要就簡單說說收益最高的幾個優化項，在這塊就不再展開敘述了，畢竟影響性能都有多方面原因導致的，比如網絡、服務器硬件、操作系統、后端服務、程序自身、數據庫服務等。

優化一：打開長連接配置

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

upstreamxxx{
#長連接數
keepalive32;
#每個長連接提供的最大請求數
keepalived_requests100;
#每個長連接沒有新的請求時，保持的最長時間
keepalive_timeout60s;
}

優化二、開啟零拷貝技術

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

sendfileon;#開啟零拷貝機制

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

「傳統方式：」 硬件-->內核-->用戶空間-->程序空間-->程序內核空間-->網絡套接字

「零拷貝方式：」 硬件-->內核-->程序內核空間-->網絡套接字

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

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

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

tcp_nodelayon;
tcp_nopushon;

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

“

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

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

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

“

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

優化五、開啟CPU親和機制

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

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

worker_cpu_affinityauto;

優化六、開啟epoll模型及調整并發連接數

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

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

“

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

十五、放在最后的結尾

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

“