Nginx負載均衡配置與算法

1 Nginx配置負載均衡

1.1 配置反向代理/負載均衡

配置反向代理:配置一個server虛擬主機(server 塊) 用來監聽端口,用來接收http請求,location 配置爲 proxy_pass(代理經過) 用來表示請求轉發到上游服務器 upstream。html

配置多臺server,便具備了負載均衡。node

upstream cluster (upstream 塊)上有服務器信息,內部包含{ sever 服務器ip對應端口} ,若是是多臺會自動實現負載均衡。nginx

# 配置上游服務器(測試時在一臺虛擬機上配置了兩臺Tomcat)
upstream cluster {
    server 192.168.233.130:8080;
    server 192.168.233.130:8088;
}

# 配置server
server {
    listen      80;
    server_name     www.awecoder.com;
    
    location / {
        # 轉發請求
        proxy_pass  http://cluster;
    }
}

1.2 Jmeter壓力測試

Jmeter官網jmeter.apache.org下載並按照壓測工具。
使用步驟:算法

  1. 添加線程組--配置線程數、間隔、每一個線程發送多少請求
  2. 添加取樣器--HTTP請求--添加ip/端口等
  3. 添加監聽器--聚合報告/結果數/表格查看結果。

注意關注異常率,查看請求成功與失敗的日誌。能夠設置異常率閾值(例如20%),超過閾值表示到達併發峯值,須要進行擴容等操做。數據庫

針對於上面配置負載均衡的壓力測試,首先直接訪問某個Tomcat服務器,再測試訪問Nginx集羣,查看壓測效果。apache

注:本地測試,可能會出現集羣錯誤率高於單機的狀況。本地壓測有大量IO,nginx做爲中轉代理,全部請求流量會通過nginx分發,對網絡和磁盤都有要求。緩存

1.3 upstream 模塊參數

  1. weight 節點資源不均時,設置權重
  2. max_conns 限制每臺上遊服務器最大的鏈接數,防止過載,起到限流做用。請求超出閾值,會異常502:Bad Gateway。
upstream cluster {
    server 192.168.233.130:8080 max_conns=2;
    server 192.168.233.130:8088 max_conns=2;
}
  1. slow_start 緩啓動,服務器從0逐漸升至設定值。是付費功能,不能用於hash和random負載均衡方法;只有一臺服務器時,參數失效。
server 192.168.233.130:8088 weight=3 slow_start=30s;
  1. down 標記某個節點(server)永久不可用。
  2. backup 標記節點爲備用機,在主節點所有宕機時纔會啓用。不能用於hash和random負載均衡方法。
  3. max_fails 和 fail_timeout 結合使用。max_fails 表示失敗幾回,則標記該server已宕機。fail_timeout 表示重試時間。默認1次,10s。

max_fails=3 fail_timeout=30s 表明在30s內請求某個節點失敗3次,認爲該節點宕機,而後等待30s,期間內新的請求值發送給正常的應用。直到30s後,Nginx再次嘗試轉發新請求到宕機節點,而且僅嘗試一次,若是仍是失敗,則繼續等待30s,直到節點恢復。服務器

1.4 http upstream 模塊參數

  1. keepalive connections 緩存上游節點的鏈接,咱們能夠視爲長鏈接。緩存長鏈接,能夠提升吞吐量。
upstream cluster {
    server 192.168.233.130:8080;
    server 192.168.233.130:8088;

    keepalive 32;
}

server {
    listen      80;
    server_name     www.awecoder.com;

    location / {
        proxy_pass  http://cluster;

        # HTTP 1.1 才支持長鏈接,並清空鏈接頭
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}

2 負載均衡算法

2.1 輪詢(RR)與加權輪詢(WRR,使用較多)

Nginx默認的負載均衡策略是輪詢,每一個節點接收幾乎一樣數量的請求。
服務器配置一般不一樣,硬件配置越好,處理的請求也會越多。能夠配置節點權重,改變nginx請求轉發比例。網絡

upstream cluster {
    server 192.168.233.130:8080 weight=1;
    server 192.168.233.130:8088 weight=3;
}

weight=1是默認權重,weight值越高,服務器接收請求概率越大。併發

2.2 ip_hash算法

經過ip_hash算法,能夠保證對於同一個ip,hash值相同,即同一個請求能夠訪問同一個節點。

hash(ip) % node_counts = index

相似場景,例如數據庫分表,假設將某張表拆分紅三張表,能夠將主鍵取出取hash和取模,放入分表中。

```nginx
upstream cluster {
    ip_hash;
    
    server 192.168.233.130:8080;
    server 192.168.233.130:8088;
}

使用ip_hash須要注意的是,

  1. 若是採用動態ip,則不能保證每次訪問到相同節點。
  2. 若是用戶發起高併發請求,或者惡意請求,會致使某個節點性能急劇降低。
  3. 若是某個server須要臨時刪除,須要使用down參數標記,以此保留客戶端ip地址的當前hash值。若是直接刪除,全部hash取模須要從新計算,用戶會話丟失,緩存失效。

2.3 其餘算法(least_conn/url_hash/fair)

  • url_hash算法 (第三方) 根據每次請求的url地址,hash後訪問到固定的服務器節點。固然,節點也能夠是一臺Nginx。
  • least_conn 傳入的請求是根據每臺服務器當前所打開的鏈接數來分配。
  • fair(第三方)根據後臺響應時間來分發請求,響應時間短的分發的請求多。
upstream cluster {
    hash $request_uri;
    #least_conn
    
    server 192.168.233.130:8080;
    server 192.168.233.130:8088;
}

2.4 一致性哈希算法 (須要引入第三方模塊ngx_http_upstream_consistent_hash,瞭解原理)

一致性hash算法提出的初衷是爲了解決分佈式緩存問題,在分佈式系統中普遍應用。

考慮到分佈式系統每一個節點都有可能失效,而且新的節點極可能動態的增長進來,如何保證當系統的節點數目發生變化時仍然可以對外提供良好的服務,這是值得考慮的。尤爲是在設計分佈式緩存系統時,若是某臺服務器失效,對於整個系統來講若是不採用合適的算法來保證一致性,那麼緩存於系統中的全部數據均可能會失效(由於節點總數減小,客戶端請求通過hash取模時,hash值發生改變,極可能找不到原先保存該對象的節點),所以一致性hash就顯得相當重要。

一致性hash算法原理

  1. 一致性哈希將整個哈希值空間組織成一個虛擬的圓環,如假設某哈希函數H的值空間爲0-2^32-1(即哈希值是一個32位無符號整形),整個哈希空間環以下:

整個空間按順時針方向組織。0和2^32-1在零點中方向重合。  

  1. 將各個服務器使用Hash進行一個哈希,具體能夠選擇服務器的ip或主機名做爲關鍵字進行哈希,這樣每臺機器就能肯定其在哈希環上的位置。

  2. 使用以下算法定位數據訪問到相應服務器:將數據key使用相同的函數Hash計算出哈希值,並肯定此數據在環上的位置,今後位置沿環順時針「行走」,第一臺遇到的服務器就是其應該定位到的服務器。  
    例如咱們有Object A、Object B、Object C、Object D四個數據對象,通過哈希計算後,在環空間上的位置以下:

  1. 容錯性分析。現假設Node C不幸宕機,能夠看到此時對象A、B、D不會受到影響,只有C對象被重定位到Node D。通常的,在一致性哈希算法中,若是一臺服務器不可用,則受影響的數據僅僅是此服務器到其環空間中前一臺服務器(即沿着逆時針方向行走遇到的第一臺服務器)之間數據,其它不會受到影響。

  2. 可擴展性分析。
    下面考慮另一種狀況,若是在系統中增長一臺服務器Node X,此時對象Object A、B、D不受影響,只有對象C須要重定位到新的Node X 。

  1. 對於服務節點過少,形成數據傾斜問題,一致性hash算法採用虛擬節點機制。

小結

一致性hash算法有着這樣幾個特色:

  1. hash結果在空間內儘可能均勻(hash算法的共性)。
  2. 具備良好的容錯性和擴展性,在節點宕機和擴展節點時,影響最少的數據。

參考資料

相關文章
相關標籤/搜索