深刻 Nginx 之配置篇

經常使用配置項

在工做中，咱們與 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 反向代理指令將請求轉發給該模塊進行分配處理。