Nginx負載均衡與生產環境應用

Nginx反向代理實現

反向代理基本配置

正向代理
正向代理是指客戶端與目標服務器之間增加一個代理服務器，客戶端直接訪問代理服務器，再由代理服務器訪問目標服務器並返回客戶端。這個過程中客戶端需要知道代理服務器的地址，並配置連接。

反向代理
反向代理是指客戶端訪問目標服務器，在目標服務器內部有一個統一接入網關將請求轉發至後端真正處理的服務器並返回結果。這個過程當中客戶端不需要知道代理服務器地址，代理對客戶端是透明的。

區別

	正向代理	反向代理
代理服務器位置	客戶端與服務都能連接的位置	目標服務器內部
主要作用	屏蔽客戶端IP、集中式緩存、解決客戶端不能直連服務器的問題	屏蔽服務端內部實現、負載均衡、緩存
應用場景	爬蟲、翻牆、maven的nexus服務	Nginx、Apache負載均衡引用

正向代理與反向代理從技術角度來說是沒有區別的，只是應用場景不同，正向代理是代理服務器訪問別的外部服務器，而反向代理是訪問服務器內部服務
正向代理配置

server {
        listen       80;
        server_name  www.hello.com;
        location /baidu.html {
            proxy_pass http://www.baidu.com/;
            }
        }

反向代理配置

location /proxy {
            proxy_pass http://127.0.0.1:8080;
            }
        }

代理相關參數

#代理服務
proxy_pass

#是否允許重定向
proxy_redirect off;

# 串header參數值後端服務
proxy_set_header Host $host;

# 設置request header即客戶端地址
proxy_set_header X-Forwarded-For $remote_addr;

### 代理連接目標服務時間
#連接代理服務超時時間
proxy_connect_timeout 90;

#請求發送最大時間
proxy_send_timeout 90;

#讀取最大時間
proxy_read_timeout 90;

#代理緩衝區大小
proxy_buffer_size 4k;

proxy_buffers 4 32k;

proxy_busy_buffers_size 64k;

proxy_temp_file_write_size 64k; 

負載均衡配置與參數解析

 upstream backend {
        server 127.0.0.1:8080 weight=1;
        server 127.0.0.1:8081 weight=2;
        }
    server {
        listen       80;
        server_name  www.hello.com;
        # 反向代理
        location / {
            proxy_pass http://backend;
            }
        }

upstream相關參數

• server 反向服務地址加端口
• weight 權重
• max_fails 失敗多少次認爲主機已經掛掉，剔除；
• fail_timeout 剔除後重新探測時間；
• backup 備用服務
• max_conns 允許最大連接數
• slow_start 當節點恢復 不立即加入 而是等待slow_start時間後加入服務隊列。

upstream負載均衡算法介紹

• ll+weight ：輪詢加權重(默認)；
• ip_hash：基於Hash計算，用於保持session一致性；
• url_hash：靜態資源緩存、節約存儲、加快速度；
• least_conn：最少連接；
• least_time：最小的響應時間，計算節點平均響應時間，然後去響應最快的哪一個，分配更高的權重。

Nginx高速緩存

問題

當達到500QPS的時候很難繼續壓測上去，一個商品詳情頁html 主體達平均150kb，在500QPS的時候已經接近千兆局域網貸款極限，所以必須減少內網通信。

Nginx緩存配置

在http元素下添加緩存區聲明。

#緩存路徑
proxy_cache_path

#緩存層級及目錄位數
levels

#緩存區內存大小
keys_zone

#有效期
inactive

#硬盤大小
max_size

# 指定緩存區，對應keys_zone 中設置的值
proxy_cache

#通過參數拼裝緩存key
proxy_cache_key 

#胃不痛的狀態碼設置緩存有效期
# proxy_cache_valid

# 在http模塊下加入配置
    proxy_cache_path /www/cache
    levels=1:2   # 1代表第一層緩存中目錄名有一個字符，2代表第二層目錄名有兩個字符
    keys_zone=cache_hello:500m
    inactive=20d
    max_size=1g;
# 在server  location下加入對應參數
location / {
            proxy_cache cache_hello;
            proxy_cache_key $host$uri$is_args$args;
            proxy_cache_valid 200 304 12h;
            proxy_pass http://backend;
      }

雖然採用輪詢算法，但是由於加了緩存，所以多次訪問到的都是同一個tomcat。

指定緩存區緩存的內容

緩存清除

該功能可以採用第三方模塊 ngx_cache_purge來實現，爲nginx添加新模塊

# 下載包
wget http://labs.frickle.com/files/ngx_cache_purge-2.3.tar.gz
# 查看已安裝模塊
./sbin/nginx -V
# 進入nginx安裝包目錄 重新安裝  --add-module 爲模塊解壓的全路徑
./configure --prefix=/root/Desktop/installpack/nginx-1.18.0 --with-http_stub_status_module --with-http_ssl_module --add-module=/root/Desktop/installpack/ngx_cache_purge-2.3
# 重新編譯
make

#備份並刪除/usr/local/nginx/sbin/nginx 文件
#將nginx安裝目錄objs/nginx 拷貝到/usr/local/nginx/sbin/下面
#啓動nginx

location ~ /clear(/.*) {
            proxy_cache_purge cache_hello $host$1$is_args$args;
            }

Nginx性能參數調優

worker_processes number

每個worker進程都是單線程的進程，它們會調用各個模塊以實現各種功能。如果這些模塊確認不會出現阻塞時的調用，那麼有多少cpu內核就應該配置多少個進程；反之，如果有可能出現阻塞時調用，那麼需要配置稍多一些的worker進程。

每個worker進程的最大連接數

worker_connections number;
worker_connections 1024; # 默認

綁定Nginx worker進程到指定的CPU內核

worker_cpu_affinity cpumask

假設每一個worker進程都是非常繁忙的，如果多個worker進程都在搶同一個cpu，那麼就會出現同步問題，反之，如果每一個worker進程都獨享一個cpu，就會在內核的調度策略上實現完全的併發。

worker_processes 4;
worker_cpu_affinity 1000 0100 0010 0001; #移位

Nginx worker進程優先級設置

worker_priority nice;
worker_priority 0; #默認

優先級由靜態優先級和內核根據進程執行情況所做的動態調整共同決定，nice是進程的靜態優先級，取值範圍是-20~+19,-20是最高優先級，+19是最低優先級。如果用戶希望Nginx佔有更多的系統資源，那麼可以把nice值配置的更小一些，但不建議比內核進程的nice值還小。

Nginx worker進程可以打開最大句柄描述符個數

worker_rlimit_nofile limit;

如果沒有設置則跟隨系統進程的限制，設置後操作系統和Nginx可以處理比ulimit -a更多的文件。

是否打開accept鎖

accept_mutex [on|off] #默認爲on

accept_mutex是Nginx的負載均衡鎖，當某一個worker進程建立的連接數量達到worker_connections配置的最大連接數的7/8時，會大大地減小該worker進程試圖建立新TCP連接的機會，如果關閉這個鎖，那麼建立TCP連接的耗時會更短，但是worker進程之間的輔助會非常不均衡，因此不建議關閉。

使用accept鎖後到真正建立連接之間的延遲時間

accept_mutex_delay Nms;

在使用accept鎖後，同一時間只有一個worker進程能夠取到accept鎖，這個accept鎖不是堵塞鎖，如果取不到會立即返回，然後至少等待accept_mutex_delay時間後才能再次駛入取鎖。