2.Nginx優化技巧

Nginx核心配置

一、併發處理機制

併發處理一般有以下三種方式：多進程、多線程，與異步機制。

Nginx 對於併發的處理同時採⽤了三種機制。當然，其異步機制使⽤的是異步⾮阻塞⽅式。

Nginx 的進程分爲兩類： master進程與 worker進程。

每個 master 進程可以⽣成多個worke進程，所以其是多進程的。

每個 worker進程可以同時處理多個⽤戶請求，每個⽤戶請求會由⼀個線程來處理，所以其是多線程的.

二、全局模式

主要針對的是nginx.conf文件夾的調優配置

work_process

工作進程數，指定nginx的工作進程數，其數值一般設置爲CPU核數的整數倍

不過需要注意，該值不僅僅取決於 CPU內核數量，還與硬盤數量及負載均衡模式相關。在不確定時可
以指定其值爲 auto

worker_cpu_affinity

將work進程與具體的內核進行綁定。不過，若指定work_process的值爲auto,則無法設置work_cpu_affinity

內核數量	工作進程數	進程與內核綁取值	說明
2	2	01 10	每個進程各使用一個內核
2	4	01 10 01 10	每個進程交替使用各個內核
4	4	0001 0010 0100 1000	每個進程各使用一個內核
4	2	0101 1010	每個進程使用兩個內核。CPU要進行大量運算的應用可以讓每個進程使用多個cpu內核
8	8	00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000	0001表示啓用第一個CPU內核，0010表示啓用第二個CPU內核【類推即可】

備註: 0-內核關閉 1-內核開啓 ----- 有⼏個內核，就需要使⽤⼏個⼆進制位

工作進程數最多開啓8個，8個以上性能提升不會再提升了，而且穩定性變得更低，所以8個進程夠用了。

worker_rlimit_nofile

設置一個worker進程所能打開的最大文件數量【655356】，默認值與當前Linux系統可打開的最大文件數相同

三、Event模塊

worker_connections

每⼀個 worker 進程可以併發處理的最⼤連接數, 該值不能超過worker_rlimit_nofile的值

accept_mutex on

on： 默認值，當⼀個新連接到達時，那些沒有處於⼯作狀態的 worker將以串⾏⽅式來處理；(效率慢)
off： 表示當⼀個新連接到達時， 所有的 worker 都會被喚醒，不過只有⼀個 worker 能獲取新連接，
其它的worker會重新進⼊阻塞狀態，這就是“驚羣”現象。(效率⾼ 但是會有浪費)

accept_mutex_delay

設置隊⾸worker會嘗試獲取互斥鎖的時間間隔。 默認值爲 500 毫秒

multi_accept

off： 系統會逐個拿出新連接按照負載均衡策略， 將其分配給當前處理連接個數最少的worker。
on： 系統會實時的統計出各個worker當前正在處理的連接個數， 然後會按照“缺編”
最多的 worker的“缺編” 數量，⼀次性將這麼多的新連接分配給該 worker。(效率⾼)

use

設置 worker與客戶端連接的處理⽅式。Nginx會⾃動選擇適合當前系統的最⾼效的⽅式。當然，也可
以使⽤ use 指令明確指定所要使⽤的連接處理⽅式。

use的取值有以下⼏種：select | poll | epoll

四、Http模塊

⾮調優屬性簡介

include mime.types;

將當前⽬錄(conf ⽬錄)中的 mime.types⽂件包含進來

default_type application/octet-stream;

對於⽆擴展名的⽂件，默認其爲 application/octet-stream類型，

即Nginx會將其作爲⼀個⼋進制流⽂件來處理

charset utf-8;

設置請求與響應的字符編碼

sendfile on

設置爲 on則開啓 Linux 系統的零拷⻉機制，否則不啓⽤零拷⻉。 當然，開啓後是否起作⽤，要看所使⽤的系統版本。 CentOS6及其以上版本⽀持 sendfile零拷⻉

tcp_nopush on

on： 以單獨的數據包形式發送 Nginx的響應頭信息，⽽真正的響應體數據會再以數據包的形式發送，
這個數據包中就不再包含響應頭信息了。(適⽤於數據量⼤的連接)
off： 默認值， 響應頭信息包含在每⼀個響應體數據包中

tcp_nodelay on

on： 不設置數據發送緩存，即不推遲發送，適合於傳輸⼩數據，⽆需緩存。
off： 開啓發送緩存。 若傳輸的數據是圖⽚等⼤數據量⽂件，則建議設置爲 off

keepalive_timeout 60

設置客戶端與Nginx間所建⽴的⻓連接的⽣命超時時間，時間到達，則連接將⾃動關閉。單位秒keepalive_requests 10000

設置⼀個⻓連接最多可以發送的請求數。該值需要在真實環境下測試。

client_body_timeout 10`

設置客戶端獲取 Nginx響應的超時時限，即⼀個請求從客戶端發出到接收到 Nginx 的響應的最⻓時
間間隔。 若超時，則認爲本次請求失敗

五、請求定位

1.資源訪問

修改配置⽂件

root：前端項目的首頁文件夾

index: 前端項目的首頁面

路徑匹配優先級

普通匹配 < ⻓路徑匹配 < 正則匹配 < 短路匹配 < 精確匹配

普通匹配

長路徑匹配

正則匹配

在正則匹配與普通匹配（⻓路徑匹配也屬於普通匹配） 均可匹配上時，正則匹配的優先級⾼

A、區分⼤⼩寫

~表示這⾥是正則表達式，默認匹配是區分⼤⼩寫的正則表達式

B、不區分⼤⼩

~後跟上*號，表示這是不區分⼤⼩寫的正則表達式

短路匹配

以^~開頭的匹配路徑稱爲短路匹配，表示只要匹配上，就不再匹配其它的了

精確匹配

以等號（=）開頭的匹配稱爲精確匹配，其是優先級最⾼的匹配

六、緩存配置

Nginx具有很強⼤的緩存功能，可以對請求的 response進⾏緩存，起到類似CDN的作⽤，甚⾄有⽐
CDN更強⼤的功能。同時， Nginx緩存還可以⽤來“數據託底”，即當後臺 web 服務器掛掉的時候，
Nginx可以直接將緩存中的託底數據返回給⽤戶。此功能就是 Nginx 實現“服務降級”的體現。

全局緩存

定義在http模塊的緩存

http{
    proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;
	#...
}

局部緩存

定義在server模塊的緩存

http{
        proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;
    server {
         set $upstream http://ip:port
        location / {
            proxy_cache my_cache;
            proxy_pass $upstream;
        }
    }
}

/path/to/cache  #本地路徑，用來設置Nginx緩存資源的存放地址
levels          #默認所有緩存文件都放在同一個/path/to/cache下，但是會影響緩存的性能，因此通常會在/path/to/cache下面建立子目錄用來分別存放不同的文件。假設levels=1:2，Nginx爲將要緩存的資源生成的key爲f4cd0fbc769e94925ec5540b6a4136d0，那麼key的最後一位0，以及倒數第2-3位6d作爲兩級的子目錄，也就是該資源最終會被緩存到/path/to/cache/0/6d目錄中
key_zone        #在共享內存中設置一塊存儲區域來存放緩存的key和metadata（類似使用次數），這樣nginx可以快速判斷一個request是否命中或者未命中緩存，1m可以存儲8000個key，10m可以存儲80000個key
max_size        #最大cache空間，如果不指定，會使用掉所有disk space，當達到配額後，會刪除最少使用的cache文件
inactive        #未被訪問文件在緩存中保留時間，本配置中如果60分鐘未被訪問則不論狀態是否爲expired，緩存控制程序會刪掉文件。inactive默認是10分鐘。需要注意的是，inactive和expired配置項的含義是不同的，expired只是緩存過期，但不會被刪除，inactive是刪除指定時間內未被訪問的緩存文件
use_temp_path   #如果爲off，則nginx會將緩存文件直接寫入指定的cache文件中，而不是使用temp_path存儲，official建議爲off，避免文件在不同文件系統中不必要的拷貝
proxy_cache     #啓用proxy cache，並指定key_zone。另外，如果proxy_cache off表示關閉掉緩存。
expires 3m      #爲靜態資源開啓緩存

七、Nginx變量

自定義變量

set $zbomc http://zbomc-blue.com:8080
location /user {
    proxy_path $zbomc;
    #...
}

內置變量

$body_bytes_sent #已發送的消息體字節數
$content_length HTTP #請求信息⾥的"Content-Length"
$content_type #請求信息⾥的"Content-Type"
$document_root #針對當前請求的根路徑設置值
$document_uri #與$uri 相同
$host #請求信息中的"Host"，如果請求中沒有 Host ⾏，則等於設置的服務器名;
$http_cookie #cookie 信息
$http_referer #來源地址
$http_user_agent #客戶端代理信息
$http_via #最後⼀個訪問服務器的 Ip 地址
$http_x_forwarded_for #相當於⽹絡訪問路徑。
$limit_rate #對連接速率的限制
$remote_addr #客戶端地址
$remote_port #客戶端端⼝號
$remote_user #客戶端⽤戶名，認證⽤
$request #⽤戶請求信息
$request_body #⽤戶請求主體
$request_body_file #發往後端的本地⽂件名稱
$request_filename #當前請求的⽂件路徑名
$request_method 請求的⽅法，⽐如"GET"、 "POST"等
$request_uri #請求的 URI，帶參數
$server_addr #服務器地址，如果沒有⽤ listen 指明服務器地址，使⽤這個變量將發起⼀次系統調⽤以取得地址(造成資源浪費)
$server_name #請求到達的服務器名
$server_port #請求到達的服務器端⼝號
$server_protocol #請求的協議版本， "HTTP/1.0"或"HTTP/1.1"
$uri #請求的 URI，可能和最初的值有不同，⽐如經過重定向之類的

八、日誌管理

http模塊管理

只要有請求通過 http協議訪問該 Nginx，就會有⽇志信息寫⼊到這⾥的⽇志⽂件

http {
    og_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';
    access_log  /var/log/nginx/access.log  main;
    error_log   /var/logs/nginx/error.log;
}

server模塊管理

只要有請求訪問當前 Server，就會有⽇志信息寫⼊到這⾥的⽇志⽂件

http{
    #...
    server{
        access_log /var/log/nginx/server/access.log main;
        error_log   /var/logs/nginx/server/error.log;
        location {
            #...
        }
    }
}

location模塊管理

http{
    #...
    server{
        location /{
            root html;
            index index.html
            access_log /var/log/nginx/server/access.log main;
        	error_log   /var/logs/nginx/server/error.log;
			#...
        }
    }
}

九、日誌壓縮

瀏覽器壓縮協議

一種過時的壓縮算法，是哈夫曼編碼的一種加強

gzip

主流壓縮算法，對deflate的一種改進

sdch

谷歌開發的壓縮算法，前面兩者的壓縮思路是修改傳輸數據的編碼格式以達到減少體量的目的，最終傳輸的數據量並沒有減少。而sdch的算法原理是，讓冗餘的數據只出現一次，其最終傳輸的數據變少了

Zopfli

谷歌開發的壓縮算法，不推薦

常用設置

http{
    #...
    gzip on;# 開啓gzip壓縮
    gzip_min_length 5k;#最小啓用壓縮的文件大小
    gzip_comp_level 4;#壓縮級別，取值爲 1-9，默認爲1，推薦爲4
    gzip_buffers 4 16k;#“4”表示的是緩存顆粒數量，⽽“16k”表示的是緩存顆粒⼤⼩
    gzip_vary on;#開啓動態壓縮
    gzip_types text/html text/css test/xml application/x-javascriptg; #通過 MIME 類型來指定要壓縮的⽂件類型。 默認值 text/html
    
    server{
        #...
    }
}

十、負載均衡

工作層次

七層負載均衡

應⽤層， 基於 HTTP 協議， 通過虛擬 URL 將請求分配到真實服務器。 ⼀般應⽤於B/S 架構系統。

Nginx就是七層負載均衡。

四層負載均衡

傳輸層， 基於 TCP 協議， 通過“虛擬 IP + 端⼝號” 將請求分配到真實服務器。

⼀般應⽤於 C/S 架構系統。

例如，LVS、 F5、 Nginx Plus 都屬於四層負載均衡

三層負載均衡

⽹絡層， 基於 IP協議， 通過虛擬 IP 將請求分配到真實服務器

二層負載均衡

鏈路層， 基於虛擬 MAC 地址將請求分配到真實服務器

負載策略

策略	說明
輪詢	缺省默認負載策略
weight	權重方式，在輪詢策略的基礎上指定輪詢的機率
ip_hash	IP分配，使用較少
least_conn	把請求轉發給連接數較少的後端服務器
fair【第三方】	響應時間短的優先匹配
url_hash【第三方】	url分配，使用較少

負載參數設置

backup

表示當前服務器爲備⽤服務器, 只有在其他的服務器都宕機以後,纔會加⼊到集羣中,被⽤戶訪問到

down

表示當前服務器永久停機，標記該服務器不可用

fail_timeout

表示當前主機被 Nginx認定爲停機的最⻓失聯時間默認, 爲10 秒。常與max_fails聯合使⽤

max_fails

在fail_timeout允許的時間內最多失敗次數，如果超出, 剔出上游服務，標記宕機

max_conns

限制每臺server的連接數，⽤於保護避免過載，可起到限流作⽤

配置實現

輪詢/權重

其他