nginx集群:nginx配置負載均衡集群(nginx1.18.0)

一，nginx的負載均衡集群的特點:

1,nginx集群和lvs的不同？

lvs集群:工作在第4層(傳輸層) nginx集群:工作在第7層(應用層) lvs集群:性能更強 nginx集群:功能更強:可以針對域名/目錄等進行配置 lvs:不支持重發請求 nginx集群:檢測到錯誤后可以重發請求

 

2，調度算法有哪些？

rr (輪詢)
wrr (就是rr的基礎上加上權重weight)
ip_hash (根據ip分發)
url_pash (根據url分發)
least_conn (分發給連接數少的機器)
fair (按響應時間分發，是第三方的算法，如使用需要安裝時添加相應的模塊)

 

說明：劉宏締的架構森林是一個專注架構的博客，地址：https://www.cnblogs.com/architectforest

         對應的源碼可以訪問這里獲取： https://github.com/liuhongdi/

說明：作者:劉宏締 郵箱: [e-mail]

 

二，我們作為例子的nginx負載均衡集群的結構:

 

loader:  172.18.1.1  loadbalancer,負責作為負載均衡的入口

web1:   172.18.1.2  后端的web機器之一

web2:   172.18.1.3   后端的web機器之二  

 

三，loader上負載均衡集群的配置

1，編輯配置文件：用upstream定義一個集群

#upstream :定義一個上游服務器集群   

#webcluster  :集群的名稱，用來區分

#server 172.18.1.2:80    指定集群的機器ip的端口

   upstream webcluster{
       server 172.18.1.2:80;
       server 172.18.1.3:80;
    }

 

2,在server配置訪問中使用上面定義的webcluster集群

   server {
        listen       80;
        server_name  localhost;
        location / {
             proxy_set_header X-Real-IP $remote_addr;
             proxy_buffering off;
             proxy_connect_timeout 5;
             proxy_read_timeout 5;
             proxy_send_timeout 5;
             proxy_pass http://webcluster;
        }
    }

 

3,配置中各個指令的說明：

proxy_pass

將代理轉發給上方 upstream 中配置的集群中的兩台服務器去處理

 

X-Real-IP

用來得到真實ip,否則在后端看到的都是loader的ip

proxy_set_header X-Real-IP $remote_addr;

 

proxy_buffering

默認值是on,這里我們把它關閉,off

它負責開啟從后端被代理服務器的響應body緩沖，

我們需要從后端服務器按收實時的數據，所以關閉

 

proxy_connect_timeout 

該指令設置與upstream server的連接超時時間，默認值60s，最高不能超過75秒

注意這個不是等待后端返回頁面的時間(那個時長是由proxy_read_timeout變量來定義)。

如果upstream服務器正在運行中，但是沒有響應

則這個指令不會起作用，因為與upstream服務器的連接已經建立

 

proxy_read_timeout

該指令設置與代理服務器的讀超時時間。它決定了nginx會等待多長時間來獲得請求的響應

如果兩次讀操作之間經過指定的時間還收不到upstream響應的數據，視為超時

默認值:60s

 

proxy_send_timeout

這個指定設置了發送請求給upstream服務器的超時時間

如果兩次寫操作之間經過指定的時間不能發送到upstream,視為超時

默認值:60s

 

四，nginx集群的輪循算法:

1,默認算法:輪詢

輪詢是upstream的默認分配方式，

每個請求按照時間順序輪流分配到不同的后端服務器

 

2,使用ip_hash算法：

   # ip_hash: 根據ip地址做hash,使同一個ip發出的請求能分發到相同的后端機器

    upstream webcluster{
       ip_hash;
       server 172.18.1.2:80;
       server 172.18.1.3:80;
    }

如果同一個ip發出的請求能分發到相同的后端機器,

則一定程度上可以提高訪問效率，因為可以避免多次建立http連接

 

注意：如果用戶使用帶有服務端緩存功能的瀏覽器（比如微信的內置瀏覽器），

則用戶的ip地址會發生變化,

所以如果做session共享時不能寄希望於ip_hash

 

3，使用url_hash算法

說明: url hash把相同的請求地址轉發到后端相同的機器

     upstream webcluster{
       hash $request_uri;
       server 172.18.1.2:80;
       server 172.18.1.3:80;
    }

如果后端的web服務機器上有本地緩存，且緩存內容不同，可以使用這種方式

因為可以提高緩存命中率，縮短訪問時間

比如：供下載用的文件緩存到web服務器

如果緩存內容相同,例如 redis緩存頁面內容，則使用url_hash帶來的益外不大

 

五，負載均衡的參數例子：

1，weight:

     機器在集群中占的權重，默認值是1

    weight越大，負載的權重就越大，

    如果后端服務器的性能或帶寬有差異時，可以用這個值來調整壓力的分配

    例子：

 

    upstream webcluster{
       server 172.18.1.2:80 weight=1;
       server 172.18.1.3:80 weight=2;
    }

說明:使用ip_hash和url_hash算法時weight不生效

 

2,max_fails /fail_timeout

   例子：

     upstream webcluster{
       server 172.18.1.2:80 max_fails=3 fail_timeout=60s;
       server 172.18.1.3:80 max_fails=3 fail_timeout=60s;
    }

在fail_timeout參數定義的時間段內，如果失敗的次數達到max_fails的值，Nginx就認為服務器不可用,標記此機器為fail,

當前的fail_timeout時長內不再嘗試連接，

到下一個再去嘗試請求，如果連接成功，則恢復之前的分發，

如果仍然不可用，則繼續等到下一個周期再嘗試

默認值:

fail_timeout為10s

max_fails為1次

 

建議值:

機器出故障一般沒那么容易恢復，

建議設置為: 3/60

 

說明：

后端服務器連接失敗時，會記錄到error_log日志中:

例：

2020/05/12 05:44:32 [error] 483#0: *7 connect() failed (111: Connection refused) while connecting to upstream, 
client: 172.18.0.1, server: localhost, request: "GET / HTTP/1.1", upstream: "http://172.18.1.3:80/", host: "192.168.3.59"

 

3，down 

表示此服務器已被手動停用

例子：

     upstream webcluster{
       server 172.18.1.2:80 max_fails=3 fail_timeout=60s down;
       server 172.18.1.3:80 max_fails=3 fail_timeout=60s;
    }

 

4，backup 

表示此服務器是備用服務器，

只有其它后端服務器都宕機或者很忙才會訪問到

所以在集群中壓力最小

例：

     upstream webcluster{
       server 172.18.1.2:80 max_fails=3 fail_timeout=60s;
       server 172.18.1.3:80 max_fails=3 fail_timeout=60s backup;
    }

 

六，查看nginx版本

[root@centos8 playbook]# /usr/local/soft/nginx-1.18.0/sbin/nginx -v
nginx version: nginx/1.18.0