深入 Nginx 之配置篇

作者：jeffrey_up

連結：https://segmentfault.com/a/1190000018359026

常用配置項

在工作中，我們與 Nginx 打交道更多的是透過其配置檔案來進行。那麼掌握這些配置項各自的作用就很有必要了。

首先， nginx.conf 的內容通常是這樣的：

1. ...
2. ... #核心摸塊
4. events { #事件模組
6. ...
7. }
9. http { # http 模組
11. server { # server塊
13. location [PATTERN] { # location塊
15. ...
16. }
17. location [PATTERN] {
19. ...
20. }
21. }
22. server {
23. ...
24. }
26. }
28. mail { # mail 模組
30. server { # server塊
31. ...
32. }
34. }

我們依次看一下每個模組一般有哪些配置項。

核心模組

1. user admin; #配置使用者或者組
3. worker_processes 4; #允許生成的行程數，預設為1
5. pid /nginx/pid/nginx.pid; #指定 nginx 行程執行檔案存放地址
7. error_log log/error.log debug; #錯誤日誌路徑，級別

事件模組

1. events {
2. accept_mutex on; #設定網路連線序列化，防止驚群現象發生，預設為on
4. multi_accept on; #設定一個行程是否同時接受多個網路連線，預設為off
6. use epoll; #事件驅動模型select|poll|kqueue|epoll|resig
8. worker_connections 1024; #最大連線數，預設為512
9. }

http 模組

1. http {
2. include mime.types; #檔案副檔名與檔案型別對映表
4. default_type application/octet-stream; #預設檔案型別，預設為text/plain
6. access_log off; #取消服務日誌
8. sendfile on; #允許 sendfile 方式傳輸檔案，預設為off，可以在http塊，server塊，location塊
10. sendfile_max_chunk 100k; #每個行程每次呼叫傳輸數量不能大於設定的值，預設為0，即不設上限
12. keepalive_timeout 65; #連線超時時間，預設為75s，可以在http，server，location塊
14. server
15. {
16. keepalive_requests 120; #單連線請求上限次數
18. listen 80; #監聽埠
20. server_name 127.0.0.1; #監聽地址
22. index index.html index.htm index.php;
24. root your_path; #根目錄
26. location ~ .php$
27. {
28. fastcgi_pass unix:/var/run/php/php7.1-fpm.sock;
30. #fastcgi_pass 127.0.0.1:9000;
32. fastcgi_index index.php;
34. include fastcgi_params;
35. }
37. }
38. }

配置項解析

worker_processes

worker_processes 用來設定 Nginx 服務的行程數。該值推薦使用 CPU 核心數。

worker_cpu_affinity*

worker_cpu_affinity 用來為每個行程分配CPU的工作核心，引數有多個二進位制值表示，每一組代表一個行程，每組中的每一位代表該行程使用CPU的情況，1代表使用，0代表不使用。所以我們使用 worker_cpu_affinity0001001001001000; 來讓行程分別系結不同的核上。預設情況下worker行程不繫結在任何一個CPU上。

worker_rlimit_nofile

設定毎個行程的最大檔案開啟數。如果不設的話上限就是系統的 ulimit–n 的數字，一般為65535。

worker_connections

設定一個行程理論允許的最大連線數，理論上越大越好，但不可以超過 worker_rlimit_nofile 的值。

use epoll

設定事件驅動模型使用 epoll。epoll 是 Nginx 支援的高效能事件驅動庫之一。是公認的非 常優秀的事件驅動模型。

accept_mutex off

關閉網路連線序列化，當其設定為開啟的時候，將會對多個 Nginx 行程接受連線進行序列化，防止多個行程對連線的爭搶。當伺服器連線數不多時，開啟這個引數會讓負載有一定程度的降低。但是當伺服器的吞吐量很大時，為了效率，請關閉這個引數；並且關閉這個引數的時候也可以讓請求在多個 worker 間的分配更均衡。所以我們設定 accept_mutex off;。

multi_accept on

設定一個行程可同時接受多個網路連線。

Sendfile on

Sendfile 是 Linux2.0 以後的推出的一個系統呼叫，它能簡化網路傳輸過程中的步驟，提高伺服器效能。

不用 sendfile 的傳統網路傳輸過程：

硬碟 >> kernel buffer >> user buffer >> kernel socket buffer >> 協議棧

用 sendfile() 來進行網路傳輸的過程：

硬碟 >> kernel buffer (快速複製到 kernelsocket buffer) >>協議棧

tcp_nopush on;

設定資料包會累積一下再一起傳輸，可以提高一些傳輸效率。 tcp_nopush 必須和 sendfile 搭配使用。

tcp_nodelay on;

小的資料包不等待直接傳輸。預設為on。看上去是和 tcp_nopush 相反的功能，但是兩邊都為 on 時 nginx 也可以平衡這兩個功能的使用。

keepalive_timeout

HTTP 連線的持續時間。設的太長會使無用的執行緒變的太多。這個根據伺服器訪問數量、處理速度以及網路狀況方面考慮。

send_timeout

設定 Nginx 伺服器響應客戶端的超時時間，這個超時時間只針對兩個客戶端和伺服器建立連線後，某次活動之間的時間，如果這個時間後，客戶端沒有任何活動，Nginx 伺服器將關閉連線。

gzip on

啟用 gzip，對響應資料進行線上實時壓縮，減少資料傳輸量。

gzip_disable “msie6”

Nginx伺服器在響應這些種類的客戶端請求時，不使用 Gzip 功能快取應用資料， gzip_disable “msie6”對IE6瀏覽器的資料不進行 GZIP 壓縮。

常用的配置項大致這些，對於不同的業務場景，有的需要額外的其他配置項，這裡不做展開。

其他

http 配置裡有 location 這一項，它是用來根據請求中的 uri 來為其匹配相應的處理規則。

location 查詢規則

1. location = / {
2. # 精確匹配 / ，主機名後面不能帶任何字串
3. [ config A ]
4. }
6. location / {
7. # 因為所有的地址都以 / 開頭，所以這條規則將匹配到所有請求
8. # 但是正則和最長字串會優先匹配
9. [ config B ]
10. }
12. location /documents/ {
13. # 匹配任何以 /documents/ 開頭的地址，匹配符合以後，還要繼續往下搜尋
14. # 只有後面的正則運算式沒有匹配到時，這一條才會採用這一條
15. [ config C ]
16. }
18. location ~ /documents/Abc {
19. # 匹配任何以 /documents/Abc 開頭的地址，匹配符合以後，還要繼續往下搜尋
20. # 只有後面的正則運算式沒有匹配到時，這一條才會採用這一條
21. [ config CC ]
22. }
24. location ^~ /images/ {
25. # 匹配任何以 /images/ 開頭的地址，匹配符合以後，停止往下搜尋正則，採用這一條
26. [ config D ]
27. }
29. location ~* .(gif|jpg|jpeg)$ {
30. # 匹配所有以 gif,jpg或jpeg 結尾的請求
31. # 然而，所有請求 /images/ 下的圖片會被 config D 處理，因為 ^~ 到達不了這一條正則
32. [ config E ]
33. }
35. location /images/ {
36. # 字元匹配到 /images/，繼續往下，會發現 ^~ 存在
37. [ config F ]
38. }
40. location /images/abc {
41. # 最長字元匹配到 /images/abc，繼續往下，會發現 ^~ 存在
42. # F與G的放置順序是沒有關係的
43. [ config G ]
44. }
46. location ~ /images/abc/ {
47. # 只有去掉 config D 才有效：先最長匹配 config G 開頭的地址，繼續往下搜尋，匹配到這一條正則，採用
48. [ config H ]
49. }

正則查詢優先順序從高到低依次如下：

“ = ” 開頭表示精確匹配，如 A 中只匹配根目錄結尾的請求，後面不能帶任何字串。

“ ^~ ” 開頭表示uri以某個常規字串開頭，不是正則匹配。

“ ~ ” 開頭表示區分大小寫的正則匹配。

“ ~* ”開頭表示不區分大小寫的正則匹配。

“ / ” 通用匹配, 如果沒有其它匹配,任何請求都會匹配到。

負載均衡配置

Nginx 的負載均衡需要用到 upstream 模組，可透過以下配置來實現：

1. upstream test-upstream {
2. ip_hash; # 使用 ip_hash 演演算法分配
4. server 192.168.1.1; # 要分配的 ip
5. server 192.168.1.2;
6. }
8. server {
10. location / {
11. proxy_pass http://test-upstream;
12. }
14. }

上面的例子定義了一個 test-upstream 的負載均衡配置，透過 proxy_pass 反向代理指令將請求轉發給該模組進行分配處理。