建站
咨詢
售后
建站咨詢
新聞中心
前面我們講了 Nginx 的 11 個(gè)階段以及各個(gè)模塊的用法，現(xiàn)在終于到了最重要也是最常用的一部分了，那就是反向代理和負(fù)載均衡，今天這篇文章介紹了負(fù)載均衡的原理以及對(duì)應(yīng)的四種負(fù)載均衡算法，當(dāng)然還有對(duì)應(yīng)的指令及實(shí)戰(zhàn)，歡迎品嘗。
創(chuàng)新互聯(lián)建站網(wǎng)站建設(shè)服務(wù)商，為中小企業(yè)提供網(wǎng)站設(shè)計(jì)制作、成都網(wǎng)站制作服務(wù)，網(wǎng)站設(shè)計(jì)，網(wǎng)站運(yùn)營(yíng)等一站式綜合服務(wù)型公司，專業(yè)打造企業(yè)形象網(wǎng)站，讓您在眾多競(jìng)爭(zhēng)對(duì)手中脫穎而出創(chuàng)新互聯(lián)建站。
負(fù)載均衡
所謂負(fù)載均衡，就是 Nginx 把請(qǐng)求均勻的分?jǐn)偨o上游的應(yīng)用服務(wù)器，這樣即使某一個(gè)服務(wù)器宕機(jī)也不會(huì)影響請(qǐng)求的處理，或者當(dāng)應(yīng)用服務(wù)器扛不住了，可以隨時(shí)進(jìn)行擴(kuò)容。
Nginx 在 AKF 可擴(kuò)展立方體上的應(yīng)用
- 在 x 軸上，可以通過橫向擴(kuò)展應(yīng)用服務(wù)器集群，Nginx 基于 Round-Robin 或者 Least-Connected 算法分發(fā)請(qǐng)求。但是橫向擴(kuò)展并不能解決所有問題，當(dāng)數(shù)據(jù)量大的情況下，無論擴(kuò)展多少臺(tái)服務(wù)，單臺(tái)服務(wù)器數(shù)據(jù)量依然很大。
- 在 y 軸上，可以基于 URL 進(jìn)行不同功能的分發(fā)。需要對(duì) Nginx 基于 URL 進(jìn)行 location 的配置，成本較高。
- 在 z 軸上可以基于用戶信息進(jìn)行擴(kuò)展。例如將用戶 IP 地址或者其他信息映射到某個(gè)特定的服務(wù)或者集群上去。
這就是 Nginx 的負(fù)載均衡功能，它的主要目的就是為了增強(qiáng)服務(wù)的處理能力和容災(zāi)能力。
反向代理
反向代理和負(fù)載均衡在某種程度上是密不可分的。
Nginx 支持多種協(xié)議的反向代理。四層的反向代理比較簡(jiǎn)單，無論是 UDP 還是 TCP 的流量過來，轉(zhuǎn)發(fā)到上游的依然是 UDP 或 TCP 的流量。
而到了應(yīng)用層時(shí)，就不太相同了，因?yàn)?HTTP 的 Header 中包含了大量的業(yè)務(wù)信息，需要根據(jù) HTTP 的頭部轉(zhuǎn)換成不同的協(xié)議。
反向代理與緩存
緩存這個(gè)問題分為兩類，一類是時(shí)間緩存，一類是空間緩存。
- 時(shí)間緩存是指，當(dāng)用戶請(qǐng)求一個(gè)頁(yè)面的時(shí)候，Nginx 發(fā)現(xiàn)沒有緩存，就會(huì)到后端服務(wù)器去取，在返回給用戶響應(yīng)的同時(shí)還會(huì)緩存一份，這樣當(dāng)下一個(gè)用戶去請(qǐng)求的時(shí)候就會(huì)直接用緩存作為響應(yīng)而不會(huì)再去請(qǐng)求上游的服務(wù)器。
- 空間緩存這種用的比較少，主要是指當(dāng)用戶發(fā)來請(qǐng)求的時(shí)候，Nginx 可以提前去上游服務(wù)器獲取一些響應(yīng)的內(nèi)容，這個(gè)后面可以看到是怎么用的。
upstream 與 server 指令
指令name 表示負(fù)載均衡集群的名字，而 {} 內(nèi)指定了一系列的服務(wù)器server 后跟服務(wù)器地址，地址后還可以加一些參數(shù) parameters
- Syntax: upstream name { ... }
- Default: —
- Context: http
- Syntax: server address [parameters];
- Default: —
- Context: upstream
- 功能：指定一組上游服務(wù)器地址，地址可以是域名、IP 地址或者 Unix Socket 地址。可以在域名或者 IP 地址后加端口，如果不加端口，那么默認(rèn)使用 80 端口。
- 通用參數(shù)：server 后可以添加的參數(shù)backup：指定當(dāng)前 server 為備份服務(wù)，僅當(dāng)非備份 server 不可用時(shí)，請(qǐng)求才會(huì)轉(zhuǎn)發(fā)到該 server表示某臺(tái)服務(wù)已經(jīng)下線，不再服務(wù)
負(fù)載均衡算法
加權(quán) Round-Robin 負(fù)載均衡算法
Round-Robin(rr) 負(fù)載均衡算法發(fā)給上游服務(wù)器的請(qǐng)求是輪詢發(fā)送的，相當(dāng)于所有上游服務(wù)器根據(jù)順序依次處理發(fā)來的請(qǐng)求。
有些情況下上游服務(wù)器性能不同，比如 4C8G 和 8C16G 的服務(wù)器都有，那么這時(shí)候就可以對(duì)服務(wù)器設(shè)置一些權(quán)重，讓性能好的承擔(dān)更多的請(qǐng)求。
功能在加權(quán)輪詢的方式訪問 server 指令指定的上游服務(wù)集成在 Nginx 的 upstream 框架中，無法移除
指令weight：服務(wù)訪問的權(quán)重，默認(rèn)是 1max_conns：server 的最大并發(fā)連接數(shù)，僅作用于單 worker 進(jìn)程。默認(rèn)是 0，表示沒有限制max_fails：在 fail_timeout 時(shí)間段內(nèi)，最大的失敗次數(shù)。當(dāng)達(dá)到最大失敗時(shí)，會(huì)在 fail_timeout 秒內(nèi)這臺(tái) server 不允許再次被選擇fail_timeout：?jiǎn)挝皇敲?，默認(rèn) 10 秒，可以指定一段時(shí)間內(nèi)最大失敗次數(shù) max_fails 以及到達(dá) max_fails 之后該 server 不能訪問的時(shí)間
對(duì)上游服務(wù)使用 keepalive 長(zhǎng)連接
Nginx 與上游服務(wù)一般是在內(nèi)網(wǎng)中的，所以開啟 keepalive 后效果后更明顯。
- 功能：通過復(fù)用連接，降低 Nginx 與上游服務(wù)器建立、關(guān)閉連接的消耗，提升吞吐量的同時(shí)降低時(shí)延
- 模塊： ngx_http_upstream_keepalive_module 默認(rèn)編譯進(jìn) Nginx，通過 --without-http_upstream_keepalive_module 移除
對(duì)上游服務(wù)器的 HTTP 頭部設(shè)定
- Syntax: keepalive connections;
- Default: —
- Context: upstream
- # 1.15.3 非穩(wěn)定版本新增命令
- Syntax: keepalive_requests number;
- Default: keepalive_requests 100;
- Context: upstream
- Syntax: keepalive_timeout timeout;
- Default: keepalive_timeout 60s;
- Context: upstream
- keepalive connections;
指定上游服務(wù)域名解析的 resolver 指令
當(dāng)使用域名訪問上游服務(wù)時(shí)，可以指定一個(gè) DNS 解析的地址，還可以設(shè)置超時(shí)等，這個(gè)時(shí)候就要用到 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
實(shí)戰(zhàn)
下面我起了兩個(gè) Nginx 的進(jìn)程，一個(gè)作為上游服務(wù)器，監(jiān)聽 8011 和 8012 端口，另一個(gè)作為反向代理向上游服務(wù)器發(fā)請(qǐng)求。
上游服務(wù)器的配置如下，當(dāng)請(qǐng)求是到達(dá) 8011 端口就返回 8011 server response. ，當(dāng)請(qǐng)求到達(dá) 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 服務(wù)器配置是這個(gè)樣子的：
這里面 8011 端口和 8012 端口的區(qū)別在于 8011 端口設(shè)置了權(quán)重和對(duì)應(yīng)的參數(shù)。
- 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 "";
- }
- }
兩個(gè) Nginx 都配置好之后，來測(cè)試一下：
- 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 端口的權(quán)重設(shè)置的是 2，所以根據(jù) rr 算法，每次都是先兩個(gè)連接負(fù)載到 8011 端口上然后是 8012 端口。
這一節(jié)講了 rr 負(fù)載均衡算法，rr 算法是所有負(fù)載均衡算法的基礎(chǔ)，在其他負(fù)載均衡算法失效的情況下，Nginx 也會(huì)使用 rr 算法進(jìn)行負(fù)載均衡。
負(fù)載均衡哈希算法，ip_hash 與 hash 模塊
rr 輪詢算法沒有辦法保證請(qǐng)求由某一臺(tái)指定的服務(wù)器去處理，只能輪詢處理請(qǐng)求，在 AKF 立方體中只能在 x 軸方向上進(jìn)行水平擴(kuò)展。如果基于 z 軸擴(kuò)展，就可以采用哈希算法保證某一類請(qǐng)求只由特定的服務(wù)器處理。
- 功能：以客戶端的 IP 地址作為 hash 算法的關(guān)鍵字，映射到特定的上游服務(wù)器中對(duì) IPv4 地址使用前 3 個(gè)字節(jié)作為關(guān)鍵字，對(duì) IPv6 則使用完整地址可以使用 rr 算法的參數(shù)可以基于 realip 模塊修改用于執(zhí)行算法的 IP 地址
- 模塊： ngx_http_upstream_ip_hash_module ，通過 --without-http_upstream_ip_hash_module 禁用模塊
指令的話比較簡(jiǎn)單，就是 ip_hash 出現(xiàn)在 upstream 上下文中。
- Syntax: ip_hash;
- Default: —
- Context: upstream
這里面不得不提到的一個(gè)模塊就是 realip 模塊，哈希算法是根據(jù) remote_addr 這個(gè)變量的值來進(jìn)行哈希的，這個(gè)變量已經(jīng)出現(xiàn)了好多次了，可見是多么常用的一個(gè)變量。不熟悉的還是到前面Nginx 的 11 個(gè)階段 重新復(fù)習(xí)一下。
還有另外一個(gè)模塊 upstream_hash 模塊，這個(gè)模塊可以基于任意的關(guān)鍵字實(shí)現(xiàn) hash 算法的復(fù)雜均衡。
基于任意關(guān)鍵字實(shí)現(xiàn) hash 算法的負(fù)載均衡：upstream_hash 模塊
- 功能：通過指定關(guān)鍵字作為 hash key，基于 hash 算法映射到特定的上游服務(wù)器中關(guān)鍵字可以含有變量、字符串可以使用 rr 算法的參數(shù)
- 模塊： ngx_http_upstream_hash_module ，通過 --without-http_upstream_ip_hash_module 禁用模塊
指令的話就是 hash 指令，后面可以跟關(guān)鍵字作為 key。
- Syntax: hash key [consistent];
- Default: —
- Context: upstream
實(shí)戰(zhàn)
配置文件如下所示：
- 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 "";
- }
- }
實(shí)際驗(yàn)證一下，會(huì)發(fā)現(xiàn)不同的 ip 地址實(shí)際上是會(huì)被不同的上游服務(wù)器處理的，如果是同一個(gè) ip 地址，那么只會(huì)被一個(gè)上游服務(wù)器處理。
- 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 算法有一個(gè)嚴(yán)重的問題，那就是當(dāng)上游服務(wù)器掛掉的話，Nginx 依然會(huì)向這臺(tái)服務(wù)器發(fā)請(qǐng)求，這是因?yàn)?，如果?fù)載的不同的服務(wù)器上去，可能會(huì)得到異常的響應(yīng)，同時(shí)還可能導(dǎo)致大量的路由變更。下面的一致性哈希可以解決這個(gè)問題。
一致性哈希算法：hash 模塊
剛才說了基于 IP 的哈希算法存在一個(gè)問題，那就是當(dāng)有一個(gè)上游服務(wù)器宕機(jī)或者擴(kuò)容的時(shí)候，會(huì)引發(fā)大量的路由變更，進(jìn)而引發(fā)連鎖反應(yīng)，導(dǎo)致大量緩存失效等問題。那么為什么會(huì)造成這種情況呢?
假設(shè)我們基于 key 來做 hash，現(xiàn)在有 5 臺(tái)上游服務(wù)器，如果基于最簡(jiǎn)單的 hash 算法對(duì) key 取模，會(huì)將 key 和 server 一一對(duì)應(yīng)起來。
當(dāng)有一臺(tái)服務(wù)器宕機(jī)的時(shí)候，就需要重新對(duì) key 進(jìn)行 hash，最后會(huì)發(fā)現(xiàn)所有的對(duì)應(yīng)關(guān)系全都失效了，從而會(huì)引發(fā)緩存大范圍失效。
而一致性 hash 算法則可以解決這個(gè)問題。
一致性哈希算法的原理是，將一個(gè)環(huán)分成了 2^32 個(gè)區(qū)間范圍，四個(gè)節(jié)點(diǎn)將這個(gè)環(huán)劃分成為了四個(gè)區(qū)間，每個(gè)區(qū)間的請(qǐng)求都由對(duì)應(yīng)的節(jié)點(diǎn)去處理。來看看當(dāng)擴(kuò)容的時(shí)候會(huì)發(fā)生什么。
假設(shè)這時(shí)候發(fā)現(xiàn) node4 負(fù)載過高，因此決定再添加一個(gè)節(jié)點(diǎn)進(jìn)去分擔(dān)壓力，那么影響的也只是這個(gè)節(jié)點(diǎn)之后的請(qǐng)求，可能會(huì)緩存失效，而其他的三個(gè)節(jié)點(diǎn)是不會(huì)有任何影響的。
這就是一致性 hash 算法的原理，一致性 hash 算法使用也很簡(jiǎn)單，只需要將上一節(jié)指令中的參數(shù)打開即可：
- Syntax: hash key [consistent];
- Default: —
- Context: upstream
這里只需要指明 consistent 參數(shù)即可。
最少連接數(shù)算法
再來看一個(gè)最少連接數(shù)算法。這個(gè)算法顧名思義，它會(huì)優(yōu)先選擇連接最少的上游服務(wù)器，是由 upstream_least_conn 模塊提供的。
- 功能：從所有上游服務(wù)器中，找出當(dāng)前并發(fā)連接數(shù)最少的一個(gè)，將請(qǐng)求轉(zhuǎn)發(fā)到它如果出現(xiàn)多個(gè)最少連接服務(wù)器的連接數(shù)都是一樣的，使用 rr 算法
- 模塊： ngx_http_upstream_least_conn_module ，通過 --without-http_upstream_ip_hash_module 禁用模塊
指令的用法也很簡(jiǎn)單，直接在 upstream 模塊中開啟 least_conn 指令即可。
- Syntax: least_conn;
- Default: —
- Context: upstream
負(fù)載均衡策略對(duì)所有 worker 進(jìn)程生效：upstream_zone 模塊
上面說的所有的負(fù)載均衡算法對(duì)于 worker 進(jìn)程來說都是獨(dú)立的，每個(gè) worker 進(jìn)程之間并不互通，這樣在很多時(shí)候并不是我們期望的。
我們期望的應(yīng)該是負(fù)載均衡算法對(duì)所有的 worker 進(jìn)程生效。
- 功能：分配出共享內(nèi)存，將其他 upstream 模塊定義的負(fù)載均衡策略數(shù)據(jù)、運(yùn)行時(shí)每個(gè)上游服務(wù)器的狀態(tài)數(shù)據(jù)存放在共享內(nèi)存上，以對(duì)所 Nginx worker 進(jìn)程生效
- 模塊： ngx_http_upstream_zone_module ，通過 --without-http_upstream_ip_hash_module 禁用模塊
一個(gè)指令，指定 zone 的名字以及對(duì)應(yīng)的大?。?/p>
- Syntax: zone name [size];
- Default: —
- Context: upstream
除此之外，各個(gè)負(fù)載均衡模塊之間是要遵循一定的順序的：
- 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,
- … …
- };
注意，這個(gè)模塊的順序是從上到下執(zhí)行的，而不是我們前面過濾模塊的從下到上。
可以看到，zone 模塊在最后，也就是說，上面各個(gè)算法定義的參數(shù)和配置，最終 zone 模塊會(huì)把這些配置放到共享內(nèi)存里面生效。
這一節(jié)介紹了負(fù)載均衡的原理以及四種負(fù)載均衡算法，也可以說是三種，就是輪詢、哈希、最少連接數(shù)算法。每一種算法都有各自的應(yīng)用場(chǎng)景，rr 算法是最基礎(chǔ)的負(fù)載均衡算法，在某些情況下其他算法失效的時(shí)候，會(huì)退化為 rr 算法。
upstream 提供的變量
先來介紹一組不含緩存的變量。
- upstream_addr上游服務(wù)器的 IP 地址，格式為可讀的字符串，例如 127.0.0.1:8012
- upstream_connect_time與上游服務(wù)建立連接消耗的時(shí)間，單位為秒，精確到毫秒
- upstream_header_time：這個(gè)接收時(shí)間是會(huì)影響到 Nginx 的性能的，因?yàn)橹挥薪邮樟?Header 才能決定下一步如何處理接收上游服務(wù)發(fā)回響應(yīng)中 HTTP 頭部所消耗的時(shí)間，單位為秒，精確到毫秒
- upstream_response_time接收完整的上游服務(wù)響應(yīng)所消耗的時(shí)間，單位為秒，精確到毫秒
- upstream_http_頭部從上游服務(wù)返回的響應(yīng)頭部的值
- upstream_bytes_received從上游服務(wù)接收到的響應(yīng)長(zhǎng)度，單位為字節(jié)
- upstream_response_length從上游服務(wù)返回的響應(yīng)包體長(zhǎng)度，單位為字節(jié)
- upstream_status上游服務(wù)返回的 HTTP 響應(yīng)狀態(tài)碼。如果未連接上，該變量值為 502
- upstream_cookie_名稱從上游服務(wù)發(fā)回的響應(yīng)頭 Set-Cookie 中取出的 cookie 值
- upstream_trailer_名稱從上游服務(wù)的響應(yīng)尾部取到的值
來看一下剛才的實(shí)戰(zhàn)中我們的例子。
在剛才的負(fù)載均衡實(shí)戰(zhàn)中有一條日志的配置：
- 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';
這條配置用到了我們上面提到的很多變量，對(duì)應(yīng)輸出的實(shí)際日志長(zhǎng)這個(gè)樣子：
- 127.0.0.1:8012 0.001 0.001 0.001 22 170 200 nginx/1.17.8 -
大家可以對(duì)照日志格式看下分別代表什么意思，這里我就不細(xì)說了。
好了，今天這篇文章跟大家介紹了什么是負(fù)載均衡，Nginx 主要是通過 upstream 模塊來提供對(duì)應(yīng)的功能的，又介紹了負(fù)載均衡的四種算法，最后介紹了 upstream 中提供的變量。下一節(jié)課我們來說一說 Nginx 的反向代理。
名稱欄目：一篇文章讓你搞懂Nginx的負(fù)載均衡
網(wǎng)站URL：http://m.5511xx.com/article/djdjhcd.html
