nginx配置詳解和原理

1.nginx的配置文件

nginx 配置文件的整體結構

　　

 

 

user nobody nobody; # 指定Nginx Worker進程運行用戶以及用戶組，默認由nobody賬號運行,nobody 是系統用戶,是一個不能登陸的帳號，一個特殊用途的用戶 ID
#啟動進程,通常設置成和cpu的數量相等
worker_processes  1; #指定了Nginx要開啟的進程數。每個Nginx進程平均耗費10M~12M內存。建議指定和CPU的數量一致即可。
 
#全局錯誤日志及PID文件 用來定義全局錯誤日志文件。日志輸出級別有debug、info、notice、warn、error、crit可供選擇，其中，debug輸出日志最為最詳細，而crit輸出日志最少
#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;
 
#pid        logs/nginx.pid; # pid是個主模塊指令，用來指定進程pid的存儲文件位置
worker_rlimit_nofile 65535; #用於綁定worker進程和CPU， Linux內核2.4以上可用

 
#工作模式及連接數上限
events {
    #epoll是多路復用IO(I/O Multiplexing)中的一種方式,
    #僅用於linux2.6以上內核,可以大大提高nginx的性能
    use   epoll; 
 
    #單個后台worker process進程的最大並發鏈接數    
    worker_connections  1024;
 
    # 並發總數是 worker_processes 和 worker_connections 的乘積
    # 即 max_clients = worker_processes * worker_connections
    # 在設置了反向代理的情況下，max_clients = worker_processes * worker_connections / 4  為什么
    # 為什么上面反向代理要除以4，應該說是一個經驗值
    # 根據以上條件，正常情況下的Nginx Server可以應付的最大連接數為：4 * 8000 = 32000
    # worker_connections 值的設置跟物理內存大小有關
    # 因為並發受IO約束，max_clients的值須小於系統可以打開的最大文件數
    # 而系統可以打開的最大文件數和內存大小成正比，一般1GB內存的機器上可以打開的文件數大約是10萬左右
    # 我們來看看360M內存的VPS可以打開的文件句柄數是多少：
    # $ cat /proc/sys/fs/file-max
    # 輸出 34336
    # 32000 < 34336，即並發連接總數小於系統可以打開的文件句柄總數，這樣就在操作系統可以承受的范圍之內
    # 所以，worker_connections 的值需根據 worker_processes 進程數目和系統可以打開的最大文件總數進行適當地進行設置
    # 使得並發總數小於操作系統可以打開的最大文件數目
    # 其實質也就是根據主機的物理CPU和內存進行配置
    # 當然，理論上的並發總數可能會和實際有所偏差，因為主機還有其他的工作進程需要消耗系統資源。
    # ulimit -SHn 65535
 
}
 
 
http {
    #設定mime類型,類型由mime.type文件定義
    include    mime.types;
    default_type  application/octet-stream;#  default_type屬於HTTP核心模塊指令，這里設定默認類型為二進制流，也就是當文件類型未定義時使用這種方式，例如在沒有配置PHP環境時，Nginx是不予解析的，此時，用瀏覽器訪問PHP文件就會出現下載窗口。
    #設定日志格式
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';
 
    access_log  logs/access.log  main;
 
    #sendfile 指令指定 nginx 是否調用 sendfile 函數（zero copy 方式）來輸出文件，
    #對於普通應用，必須設為 on,
    #如果用來進行下載等應用磁盤IO重負載應用，可設置為 off，
    #以平衡磁盤與網絡I/O處理速度，降低系統的uptime.
    sendfile     on;
    #tcp_nopush     on;
 
    #連接超時時間
    #keepalive_timeout  0;
    keepalive_timeout  65;
    tcp_nodelay     on;
 
    #開啟gzip壓縮
    gzip  on;
    gzip_disable "MSIE [1-6].";
 
    #設定請求緩沖
    client_header_buffer_size    128k;
    large_client_header_buffers  4 128k;
 
 　　

　　　　upstream cszhi.com{
　　　　　　ip_hash;
　　　　　　server 192.168.8.11:80;
　　　　　　server 192.168.8.12:80 down;
　　　　　　server 192.168.8.13:8009 max_fails=3 fail_timeout=20s;
　　　　　　server 192.168.8.146:8080;
　　　　}; 負載均衡的設置

#設定虛擬主機配置
    server {
        #偵聽80端口
        listen    80;
        #定義使用 www.nginx.cn訪問
        server_name  www.nginx.cn;
 
        #定義服務器的默認網站根目錄位置
        root html;
 
        #設定本虛擬主機的訪問日志
        access_log  logs/nginx.access.log  main;
 
        #默認請求
        location / {
            
            #定義首頁索引文件的名稱
            index index.php index.html index.htm;   
 
        }
　　　　
 
        # 定義錯誤提示頁面
        error_page   500 502 503 504 /50x.html;
        location = /50x.html {
        }
 
        #靜態文件，nginx自己處理
        location ~ ^/(images|javascript|js|css|flash|media|static)/ {
            
            #過期30天，靜態文件不怎么更新，過期可以設大一點，
            #如果頻繁更新，則可以設置得小一點。
            expires 30d;
        }
 
        #PHP 腳本請求全部轉發到 FastCGI處理. 使用FastCGI默認配置.
        location ~ .php$ {
            fastcgi_pass 127.0.0.1:9000;
            fastcgi_index index.php;
            fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
            include fastcgi_params;
        }
 　　　　

　　　　 location /proxy {
        　　proxy_pass http://192.168.33.10; 　　 } # 設置方向代理

#禁止訪問 .htxxx 文件 location ~ /.ht { deny all; } } }

 1.1 關於nobody用戶

關於linux下的nobody用戶
nobody 是系統用戶,是一個不能登陸的帳號，一個特殊用途的用戶 ID ,一些服務進程如apache，aquid等都采用一些特殊的帳號來運行，比如nobody,news,games等等。一般來說 uid < 500 的都是系統 ID 。
Linux 系統為了安全，很多操作和服務的運行都不是運行在 root 用戶下面的，而是一個專用的 ID ，這個 ID 一般就是 nobody ，這樣就可以把每個服務運行的情況隔離出來。
保證不會因為服務器程序的問題而讓服務器程序成了黑客的直接操作源（黑客拿下了服務器程序，也僅僅是 nobody 用戶而不是 root 用戶）。同時也不會影響其他用戶的數據。
服務器程序提權有專用的辦法來防止惡意使用的。
除了 nobody ，常見的還有 ftp 、ssh 什么的。有的不是用來跑服務，而是用來占坑，主要是用用戶組的權限管理進行權限設置，這個時候會有一個占坑用的同名 ID 加入到用戶組。這種情況好像主要是為了兼容。
問題描述：
上午據反映，系統響應很慢，界面要刷新很久才出得來。查后台也沒有報什么錯，我們系統是用nginx做負載均衡。慣性地不走負載均衡而直接訪 問單節點應用，發現響應很快，很正常。初步定位問題出在nginx上，
然后查nginx日志，發現有很多錯誤，錯誤中有“13: Permission denied”這個信息，明顯是權限問題，很奇怪，之前運行都很正常啊。后來一問才知道，維護人員做了操作。

系統上nginx安裝時使用的是root用戶，也是用root用戶啟動的，所以要修改配置的時候需要使用root用戶，管理上不方便，所以維護人員 心血來潮修改了nginx的權限（后來知道他是使用這個命令修改的權限chown -R user:group $nginxdir）。
就是將nginx的用戶和組都換掉了，但是這樣為什么會造成“響應慢”呢？

 1.2 負載均衡設置

Nginx的負載均衡模塊目前支持4種調度算法，下面進行分別介紹，其中后兩項屬於第三方的調度方法。

• 輪詢（默認）：每個請求按時間順序逐一分配到不同的后端服務器，如果后端某台服務器宕機，故障系統被自動剔除，使用戶訪問不受影響；
• Weight：指定輪詢權值，Weight值越大，分配到的訪問機率越高，主要用於后端每個服務器性能不均的情況下；
• ip_hash：每個請求按訪問IP的hash結果分配，這樣來自同一個IP的訪客固定訪問一個后端服務器，有效解決了動態網頁存在的session共享問題；
• fair：比上面兩個更加智能的負載均衡算法。此種算法可以依據頁面大小和加載時間長短智能地進行負載均衡，也就是根據后端服務器的響應時間來分配請求，響應時間短的優先分配。Nginx本身是不支持fair的，如果需要使用這種調度算法，必須下載Nginx的upstream_fair模塊；
• url_hash：按訪問url的hash結果來分配請求，使每個url定向到同一個后端服務器，可以進一步提高后端緩存服務器的效率。Nginx本身是不支持url_hash的，如果需要使用這種調度算法，必須安裝Nginx 的hash軟件包。

在HTTP Upstream模塊中，可以通過server指令指定后端服務器的IP地址和端口，同時還可以設定每個后端服務器在負載均衡調度中的狀態。常用的狀態有：

• down：表示當前的server暫時不參與負載均衡；
• backup：預留的備份機器。當其他所有的非backup機器出現故障或者忙的時候，才會請求backup機器，因此這台機器的壓力最輕；
• max_fails：允許請求失敗的次數，默認為1。當超過最大次數時，返回proxy_next_upstream 模塊定義的錯誤；
• fail_timeout：在經歷了max_fails次失敗后，暫停服務的時間。max_fails可以和fail_timeout一起使用。

注意，當負載調度算法為ip_hash時，后端服務器在負載均衡調度中的狀態不能是weight和backup。

2.

參考資料：https://blog.csdn.net/wangbin_0729/article/details/82109693

http://baijiahao.baidu.com/s?id=1604485941272024493&wfr=spider&for=pc

https://www.jianshu.com/p/6215e5d24553