深入 Nginx 之配置篇

Jeffrey_up發表於2019-03-01

常用配置項

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

首先,nginx.conf 的內容通常是這樣的:

...              
...            #核心摸塊

events {        #事件模組

   ...
}

http {     # http 模組

    server {      # server塊

        location [PATTERN] {  # location塊

            ...
        }
        location [PATTERN] {

            ...
        }
    }
    server {
      ...
    }

}

mail {     # mail 模組

     server {    # server塊
          ...
    }

}

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

核心模組

user admin; #配置使用者或者組。

worker_processes 4; #允許生成的程式數,預設為1 

pid /nginx/pid/nginx.pid; #指定 nginx 程式執行檔案存放地址 

error_log log/error.log debug; #錯誤日誌路徑,級別。

事件模組

events { 
    accept_mutex on; #設定網路連線序列化,防止驚群現象發生,預設為on 

    multi_accept on; #設定一個程式是否同時接受多個網路連線,預設為off 

    use epoll; #事件驅動模型select|poll|kqueue|epoll|resig

    worker_connections 1024; #最大連線數,預設為512
}

http 模組

http {
    include       mime.types;   #副檔名與檔案型別對映表

    default_type  application/octet-stream; #預設檔案型別,預設為text/plain

    access_log off; #取消服務日誌    

    sendfile on;   #允許 sendfile 方式傳輸檔案,預設為off,可以在http塊,server塊,location塊。

    sendfile_max_chunk 100k;  #每個程式每次呼叫傳輸數量不能大於設定的值,預設為0,即不設上限。

    keepalive_timeout 65;  #連線超時時間,預設為75s,可以在http,server,location塊。

    server 
    {
            keepalive_requests 120; #單連線請求上限次數。

            listen 80; #監聽埠

            server_name  127.0.0.1;   #監聽地址      

            index index.html index.htm index.php;

            root your_path;  #根目錄

            location ~ \.php$
            {
                  fastcgi_pass unix:/var/run/php/php7.1-fpm.sock;

                  #fastcgi_pass 127.0.0.1:9000;

                  fastcgi_index index.php;

                  include fastcgi_params;
            }

    }
}

配置項解析

  • worker_processes

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

  • worker_cpu_affinity

    worker_cpu_affinity 用來為每個程式分配CPU的工作核心,引數有多個二進位制值表示,每一組代表一個程式,每組中的每一位代表該程式使用CPU的情況,1代表使用,0代表不使用。所以我們使用 worker_cpu_affinity 0001 0010 0100 1000;來讓程式分別繫結不同的核上。預設情況下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 查詢規則


location  = / {
  # 精確匹配 / ,主機名後面不能帶任何字串
  [ config A ]
}

location  / {
  # 因為所有的地址都以 / 開頭,所以這條規則將匹配到所有請求
  # 但是正則和最長字串會優先匹配
  [ config B ]
}

location /documents/ {
  # 匹配任何以 /documents/ 開頭的地址,匹配符合以後,還要繼續往下搜尋
  # 只有後面的正規表示式沒有匹配到時,這一條才會採用這一條
  [ config C ]
}

location ~ /documents/Abc {
  # 匹配任何以 /documents/Abc 開頭的地址,匹配符合以後,還要繼續往下搜尋
  # 只有後面的正規表示式沒有匹配到時,這一條才會採用這一條
  [ config CC ]
}

location ^~ /images/ {
  # 匹配任何以 /images/ 開頭的地址,匹配符合以後,停止往下搜尋正則,採用這一條。
  [ config D ]
}

location ~* \.(gif|jpg|jpeg)$ {
  # 匹配所有以 gif,jpg或jpeg 結尾的請求
  # 然而,所有請求 /images/ 下的圖片會被 config D 處理,因為 ^~ 到達不了這一條正則
  [ config E ]
}

location /images/ {
  # 字元匹配到 /images/,繼續往下,會發現 ^~ 存在
  [ config F ]
}

location /images/abc {
  # 最長字元匹配到 /images/abc,繼續往下,會發現 ^~ 存在
  # F與G的放置順序是沒有關係的
  [ config G ]
}

location ~ /images/abc/ {
  # 只有去掉 config D 才有效:先最長匹配 config G 開頭的地址,繼續往下搜尋,匹配到這一條正則,採用
    [ config H ]
}

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

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

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

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

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

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

負載均衡配置

Nginx 的負載均衡需要用到 upstream 模組,可通過以下配置來實現:

upstream test-upstream {
    ip_hash; # 使用 ip_hash 演算法分配

    server 192.168.1.1; # 要分配的 ip
    server 192.168.1.2;
}

server {

    location / {       
        proxy_pass http://test-upstream;
    }

}

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

但行好事,莫問前程。

相關文章