投稿
  1. 簡單一點首頁
  2. 投稿

基礎原理和算法解析「nginx的負載均衡算法有哪些」

投稿專員 • • 投稿

前面我們講了 Nginx 的 11 個階段以及各個模塊的用法，現在終於到了最重要也是最常用的一部分了，那就是反向代理和負載均衡，今天這篇文章介紹了負載均衡的原理以及對應的四種負載均衡算法，當然還有對應的指令及實戰，歡迎品嘗。

負載均衡

所謂負載均衡，就是 Nginx 把請求均勻的分攤給上游的應用服務器，這樣即使某一個服務器宕機也不會影響請求的處理，或者當應用服務器扛不住了，可以隨時進行擴容。

一篇文章讓你搞懂 Nginx 的負載均衡

Nginx 在 AKF 可擴展立方體上的應用

一篇文章讓你搞懂 Nginx 的負載均衡
  • 在 x 軸上，可以通過橫向擴展應用服務器集群，Nginx 基於 Round-Robin 或者 Least-Connected 算法分發請求。但是橫向擴展並不能解決所有問題，當數據量大的情況下，無論擴展多少台服務，單台服務器數據量依然很大。
  • 在 y 軸上，可以基於 URL 進行不同功能的分發。需要對 Nginx 基於 URL 進行 location 的配置，成本較高。
  • 在 z 軸上可以基於用戶信息進行擴展。例如將用戶 IP 地址或者其他信息映射到某個特定的服務或者集群上去。

這就是 Nginx 的負載均衡功能，它的主要目的就是為了增強服務的處理能力和容災能力。

反向代理

反向代理和負載均衡在某種程度上是密不可分的。

Nginx 支持多種協議的反向代理。四層的反向代理比較簡單，無論是 UDP 還是 TCP 的流量過來，轉發到上游的依然是 UDP 或 TCP 的流量。

而到了應用層時，就不太相同了，因為 HTTP 的 Header 中包含了大量的業務信息，需要根據 HTTP 的頭部轉換成不同的協議。

一篇文章讓你搞懂 Nginx 的負載均衡

反向代理與緩存

緩存這個問題分為兩類，一類是時間緩存，一類是空間緩存。

  • 時間緩存是指，當用戶請求一個頁面的時候，Nginx 發現沒有緩存，就會到後端服務器去取，在返回給用戶響應的同時還會緩存一份，這樣當下一個用戶去請求的時候就會直接用緩存作為響應而不會再去請求上游的服務器。
  • 空間緩存這種用的比較少，主要是指當用戶發來請求的時候，Nginx 可以提前去上游服務器獲取一些響應的內容，這個後面可以看到是怎麼用的。
一篇文章讓你搞懂 Nginx 的負載均衡

upstream 與 server 指令

  • 指令name 表示負載均衡集群的名字，而 {} 內指定了一系列的服務器server 後跟服務器地址，地址後還可以加一些參數 parameters
Syntax: upstream name { ... }
Default: —
Context: http

Syntax: server address [parameters];
Default: —
Context: upstream
  • 功能：指定一組上游服務器地址，地址可以是域名、IP 地址或者 Unix Socket 地址。可以在域名或者 IP 地址後加端口，如果不加端口，那麼默認使用 80 端口。
  • 通用參數：server 後可以添加的參數backup：指定當前 server 為備份服務，僅當非備份 server 不可用時，請求才會轉發到該 server表示某台服務已經下線，不再服務

負載均衡算法

加權 Round-Robin 負載均衡算法

Round-Robin（rr） 負載均衡算法發給上游服務器的請求是輪詢發送的，相當於所有上游服務器根據順序依次處理髮來的請求。

有些情況下上游服務器性能不同，比如 4C8G 和 8C16G 的服務器都有，那麼這時候就可以對服務器設置一些權重，讓性能好的承擔更多的請求。

  • 功能在加權輪詢的方式訪問 server 指令指定的上游服務集成在 Nginx 的 upstream 框架中，無法移除
  • 指令weight：服務訪問的權重，默認是
    1max_conns：server 的最大並發連接數，僅作用於單 worker 進程。默認是 0，表示沒有限制max_fails：在
    fail_timeout 時間段內，最大的失敗次數。當達到最大失敗時，會在 fail_timeout 秒內這台 server
    不允許再次被選擇fail_timeout：單位是秒，默認 10 秒，可以指定一段時間內最大失敗次數 max_fails 以及到達
    max_fails 之後該 server 不能訪問的時間

對上游服務使用 keepalive 長連接

Nginx 與上游服務一般是在內網中的，所以開啟 keepalive 後效果後更明顯。

  • 功能：通過復用連接，降低 Nginx 與上游服務器建立、關閉連接的消耗，提升吞吐量的同時降低時延
  • 模塊： ngx_http_upstream_keepalive_module 默認編譯進 Nginx，通過 –without-http_upstream_keepalive_module 移除

對上游服務器的 HTTP 頭部設定

proxy_http_version 1.1;
proxy_set_header Connection "";

upstream_keepalive 的指令

Syntax: keepalive connections;
Default: —
Context: upstream
# 1.15.3 非穩定版本新增命令
Syntax: keepalive_requests number;
Default: keepalive_requests 100; 
Context: upstream
Syntax: keepalive_timeout timeout;
Default: keepalive_timeout 60s; 
Context: upstream

keepalive connections;

指定上游服務域名解析的 resolver 指令

當使用域名訪問上游服務時，可以指定一個 DNS 解析的地址，還可以設置超時等，這個時候就要用到 resolver 指令。

Syntax: resolver address ... [valid=time] [ipv6=on|off];
Default: —
Context: http, server, location

Syntax: resolver_timeout time;
Default: resolver_timeout 30s; 
Context: http, server, location

實戰

下面我起了兩個 Nginx 的進程，一個作為上游服務器，監聽 8011 和 8012 端口，另一個作為反向代理向上游服務器發請求。

上游服務器的配置如下，當請求是到達 8011 端口就返回 8011 server response. ，當請求到達 8012 端口返回 8012 server response. 。

server {
    listen 8011;
    default_type text/plain;
    return 200 '8011 server response.n';
}

server {
    listen 8012;
    default_type text/plain;
    # client_body_in_single_buffer on;
    return 200 '8012 server response.n';
}

作為反向代理的 Nginx 服務器配置是這個樣子的：

這裏面 8011 端口和 8012 端口的區別在於 8011 端口設置了權重和對應的參數。

upstream rrups {
    server 127.0.0.1:8011 weight=2 max_conns=2 max_fails=2 fail_timeout=5;
    server 127.0.0.1:8012;
    keepalive 32;
}

server {
    server_name rrups.ziyang.com;
    error_log myerror.log info;

    location /{
        proxy_pass http://rrups;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}

兩個 Nginx 都配置好之後，來測試一下：

➜  nginx curl rrups.ziyang.com
8011 server response.
➜  nginx curl rrups.ziyang.com
8011 server response.
➜  nginx curl rrups.ziyang.com
8012 server response.

由於 8011 端口的權重設置的是 2，所以根據 rr 算法，每次都是先兩個連接負載到 8011 端口上然後是 8012 端口。

這一節講了 rr 負載均衡算法，rr 算法是所有負載均衡算法的基礎，在其他負載均衡算法失效的情況下，Nginx 也會使用 rr 算法進行負載均衡。

負載均衡哈希算法，ip_hash 與 hash 模塊

rr 輪詢算法沒有辦法保證請求由某一台指定的服務器去處理，只能輪詢處理請求，在 AKF 立方體中只能在 x 軸方向上進行水平擴展。如果基於 z 軸擴展，就可以採用哈希算法保證某一類請求只由特定的服務器處理。

  • 功能：以客戶端的 IP 地址作為 hash 算法的關鍵字，映射到特定的上游服務器中對 IPv4 地址使用前 3 個位元組作為關鍵字，對 IPv6 則使用完整地址可以使用 rr 算法的參數可以基於 realip 模塊修改用於執行算法的 IP 地址
  • 模塊： ngx_http_upstream_ip_hash_module ，通過 –without-http_upstream_ip_hash_module 禁用模塊

指令的話比較簡單，就是 ip_hash 出現在 upstream 上下文中。

Syntax: ip_hash;
Default: —
Context: upstream

這裏面不得不提到的一個模塊就是 realip 模塊，哈希算法是根據 remote_addr 這個變量的值來進行哈希的，這個變量已經出現了好多次了，可見是多麼常用的一個變量。不熟悉的還是到前面Nginx 的 11 個階段 重新複習一下。

還有另外一個模塊 upstream_hash 模塊，這個模塊可以基於任意的關鍵字實現 hash 算法的複雜均衡。

基於任意關鍵字實現 hash 算法的負載均衡：upstream_hash 模塊

  • 功能：通過指定關鍵字作為 hash key，基於 hash 算法映射到特定的上游服務器中關鍵字可以含有變量、字符串可以使用 rr 算法的參數
  • 模塊： ngx_http_upstream_hash_module ，通過 –without-http_upstream_ip_hash_module 禁用模塊

指令的話就是 hash 指令，後面可以跟關鍵字作為 key。

Syntax: hash key [consistent];
Default: —
Context: upstream

實戰

配置文件如下所示：

log_format  varups  '$upstream_addr $upstream_connect_time $upstream_header_time $upstream_response_time '
                        '$upstream_response_length $upstream_bytes_received '
                        '$upstream_status $upstream_http_server $upstream_cache_status';

upstream iphashups {
    ip_hash;
    #hash user_$arg_username;
    server 127.0.0.1:8011 weight=2 max_conns=2 max_fails=2 fail_timeout=5;
    server 127.0.0.1:8012 weight=1;
}

server {
    set_real_ip_from  127.0.0.1;
    real_ip_recursive on;
    real_ip_header X-Forwarded-For;
    server_name iphash.ziyang.com;
    listen 80;
    error_log myerror.log info;
    access_log logs/upstream_access.log varups;

    location /{
        proxy_pass http://iphashups;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}

實際驗證一下，會發現不同的 ip 地址實際上是會被不同的上游服務器處理的，如果是同一個 ip 地址，那麼只會被一個上游服務器處理。

➜  nginx curl -H 'X-Forwarded-For: 10.200.20.20' iphash.ziyang.com
8012 server response.
➜  nginx curl -H 'X-Forwarded-For: 1.200.20.20' iphash.ziyang.com
8011 server response.

基於 IP 或者基於自定義 key 的 hash 算法有一個嚴重的問題，那就是當上游服務器掛掉的話，Nginx 依然會向這台服務器發請求，這是因為，如果負載的不同的服務器上去，可能會得到異常的響應，同時還可能導致大量的路由變更。下面的一致性哈希可以解決這個問題。

一致性哈希算法：hash 模塊

剛才說了基於 IP 的哈希算法存在一個問題，那就是當有一個上游服務器宕機或者擴容的時候，會引發大量的路由變更，進而引發連鎖反應，導致大量緩存失效等問題。那麼為什麼會造成這種情況呢？

  • 假設我們基於 key 來做 hash，現在有 5 台上游服務器，如果基於最簡單的 hash 算法對 key 取模，會將 key 和 server 一一對應起來。
一篇文章讓你搞懂 Nginx 的負載均衡
  • 當有一台服務器宕機的時候，就需要重新對 key 進行 hash，最後會發現所有的對應關係全都失效了，從而會引發緩存大範圍失效。
一篇文章讓你搞懂 Nginx 的負載均衡

而一致性 hash 算法則可以解決這個問題。

一篇文章讓你搞懂 Nginx 的負載均衡

一致性哈希算法的原理是，將一個環分成了 2^32 個區間範圍，四個節點將這個環劃分成為了四個區間，每個區間的請求都由對應的節點去處理。來看看當擴容的時候會發生什麼。

一篇文章讓你搞懂 Nginx 的負載均衡

假設這時候發現 node4 負載過高，因此決定再添加一個節點進去分擔壓力，那麼影響的也只是這個節點之後的請求，可能會緩存失效，而其他的三個節點是不會有任何影響的。

這就是一致性 hash 算法的原理，一致性 hash 算法使用也很簡單，只需要將上一節指令中的參數打開即可：

Syntax: hash key [consistent];
Default: —
Context: upstream

這裡只需要指明 consistent 參數即可。

最少連接數算法

再來看一個最少連接數算法。這個算法顧名思義，它會優先選擇連接最少的上游服務器，是由 upstream_least_conn 模塊提供的。

  • 功能：從所有上游服務器中，找出當前並發連接數最少的一個，將請求轉發到它如果出現多個最少連接服務器的連接數都是一樣的，使用 rr 算法
  • 模塊： ngx_http_upstream_least_conn_module ，通過 –without-http_upstream_ip_hash_module 禁用模塊

指令的用法也很簡單，直接在 upstream 模塊中開啟 least_conn 指令即可。

Syntax: least_conn;
Default: —
Context: upstream

負載均衡策略對所有 worker 進程生效：upstream_zone 模塊

上面說的所有的負載均衡算法對於 worker 進程來說都是獨立的，每個 worker 進程之間並不互通，這樣在很多時候並不是我們期望的。

我們期望的應該是負載均衡算法對所有的 worker 進程生效。

  • 功能：分配出共享內存，將其他 upstream 模塊定義的負載均衡策略數據、運行時每個上游服務器的狀態數據存放在共享內存上，以對所 Nginx worker 進程生效
  • 模塊： ngx_http_upstream_zone_module ，通過 –without-http_upstream_ip_hash_module 禁用模塊

一個指令，指定 zone 的名字以及對應的大小：

Syntax: zone name [size];
Default: —
Context: upstream

除此之外，各個負載均衡模塊之間是要遵循一定的順序的：

ngx_module_t *ngx_modules[] = {
    … …
    &ngx_http_upstream_hash_module,
    &ngx_http_upstream_ip_hash_module,
    &ngx_http_upstream_least_conn_module,
    &ngx_http_upstream_random_module,
    &ngx_http_upstream_keepalive_module,
    &ngx_http_upstream_zone_module,
    … …
};

注意，這個模塊的順序是從上到下執行的，而不是我們前面過濾模塊的從下到上。

可以看到，zone 模塊在最後，也就是說，上面各個算法定義的參數和配置，最終 zone 模塊會把這些配置放到共享內存裏面生效。

這一節介紹了負載均衡的原理以及四種負載均衡算法，也可以說是三種，就是輪詢、哈希、最少連接數算法。每一種算法都有各自的應用場景，rr 算法是最基礎的負載均衡算法，在某些情況下其他算法失效的時候，會退化為 rr 算法。

upstream 提供的變量

先來介紹一組不含緩存的變量。

  • upstream_addr上游服務器的 IP 地址，格式為可讀的字符串，例如 127.0.0.1:8012
  • upstream_connect_time與上游服務建立連接消耗的時間，單位為秒，精確到毫秒
  • upstream_header_time：這個接收時間是會影響到 Nginx 的性能的，因為只有接收了 Header 才能決定下一步如何處理接收上游服務發迴響應中 HTTP 頭部所消耗的時間，單位為秒，精確到毫秒
  • upstream_response_time接收完整的上游服務響應所消耗的時間，單位為秒，精確到毫秒
  • upstream_http_頭部從上游服務返回的響應頭部的值
  • upstream_bytes_received從上游服務接收到的響應長度，單位為位元組
  • upstream_response_length從上游服務返回的響應包體長度，單位為位元組
  • upstream_status上游服務返回的 HTTP 響應狀態碼。如果未連接上，該變量值為 502
  • upstream_cookie_名稱從上游服務發回的響應頭 Set-Cookie 中取出的 cookie 值
  • upstream_trailer_名稱從上游服務的響應尾部取到的值

來看一下剛才的實戰中我們的例子。

在剛才的負載均衡實戰中有一條日誌的配置：

log_format  varups  '$upstream_addr $upstream_connect_time $upstream_header_time $upstream_response_time '
                        '$upstream_response_length $upstream_bytes_received '
                        '$upstream_status $upstream_http_server $upstream_cache_status';

這條配置用到了我們上面提到的很多變量，對應輸出的實際日誌長這個樣子：

127.0.0.1:8012 0.001 0.001 0.001 22 170 200 nginx/1.17.8 -

大家可以對照日誌格式看下分別代表什麼意思，這裡我就不細說了。

好了，今天這篇文章跟大家介紹了什麼是負載均衡，Nginx 主要是通過 upstream 模塊來提供對應的功能的，又介紹了負載均衡的四種算法，最後介紹了 upstream 中提供的變量。下一節課我們來說一說 Nginx 的反向代理。

原創文章，作者：投稿專員，如若轉載，請註明出處：https://www.506064.com/zh-hk/n/281207.html

贊 (0)
打賞 微信掃一掃 微信掃一掃 支付寶掃一掃 支付寶掃一掃
投稿專員的頭像投稿專員
0 0
上一篇 2024-12-21 13:16
下一篇 2024-12-21 13:16

相關推薦

發表回復

登錄後才能評論