nginx負載均衡基於iphash的session黏貼
阿新 • • 發佈：2019-02-09
nginx負載均衡中RR和ip_hash策略分析一、nginx的upstream目前支援負載均衡方式的分配
1、RR（預設）
每個請求按時間順序逐一分配到不同的後端伺服器，假如後端伺服器down掉，能自動剔除。
例如：
upstream tomcats {
server 10.1.1.107:88 max_fails=3 fail_timeout=3s weight=9;
server 10.1.1.132:80 max_fails=3 fail_timeout=3s weight=9;
}
2、ip_hash
每個請求按訪問ip的hash結果分配，這樣每個訪客固定訪問一個後端伺服器，可以解決session的題目。
例如：
upstream tomcats {
ip_hash;
server 10.1.1.107:88;
server 10.1.1.132:80;
}
3、fair（第三方）
按後端伺服器的響應時間來分配請求，響應時間短的優先分配。
4、url_hash（第三方）
按訪問url的hash結果來分配請求，使每個url定向到同一個後端伺服器，後端伺服器為快取時比較有效。
下面，我們針對RR和ip_hash的負載均衡策略進行分析。由於每一種負載均衡策略都是在upstream的框架中使用，upstream控制總的工作流程，負載均衡策略僅僅提供選擇或開釋server的函式，所以，我們在分析RR時結合upstream（ngx_http_upstream.c）。ip_hash大部分內容與RR一致，只是重新實現RR中的ngx_http_upstream_get_peer函式。
二、RR策略
RR機制分為三個部分：初始化upstream，獲取一個可用的後臺伺服器和開釋後臺伺服器。
以下分析以此配置為例:
upstream backend {
server A max_fails=3 fail_timeout=4s weight=9;
server B max_fails=3 fail_timeout=4s weight=9;
server C max_fails=3 fail_timeout=4s weight=9;
server D backup;
Server E backup;
}
2.1 初始化upstream
對於例子中的upstream backend來說，
首先初始化各個server, 除了設定IP和埠號外，還要設定如下置weight，current_weight，max_fails和fail_timeout。其中max_fails和fail_timeout 這兩個引數是組合使用的，表示server 假如失敗次數達到max_fails 次，並保持fail_timeout秒之內該伺服器不能被訪問。
對於serverA來說，設定如下
serverA.weight =9;
serverA.current_weight = 9; //初始值即是配置檔案中的weight.
serverA.max_fails = 3;
serverA.fail_timeout = 4;
接著，建立兩個server型別（在下文先容中，server型別等同於peer型別，都是用來指明儲存upstream中一個server的資訊）的陣列，peers和backup，分別儲存正常的輪循server和備用server. 並竊冬按照陣列中各個server的weight值的大小，由高到底排序。
本例中，在陣列peers中儲存serverA、serverB和serverC, 並記錄server的總個數peers->number=3; 在陣列backup中儲存serverD和serverE, 並記錄server的總個數backup->number=2;
最後，設定upstream中各個變數的值。
rrp 表示當前要輪循的server陣列，初始設定為Upstream->rrp = peers.
tries 表示嘗試的次數，當嘗試一個server失敗後，tries的值就會減一。初始設定為peers的總個數。
Next 表示當peers陣列中server都失敗，不能提供服務了，通過upstream->next，切換到back陣列中選擇server.
2.2 具體的RR策略
2.2.1 ） 選擇最初要輪循的server, 把它給rrp->current變數，跳轉到2.2.2 當一個客戶端請求到達nginx後，nginx就會在upstream的peers 陣列中挑選一個current_weight最大的server作為當前請求最初要輪循的server. 在peers陣列中選取current_weight最大的演算法如下：
由於peers陣列中的server是按照weight值的大小排序好的。
它是通過雙重迴圈，滿足下列條件後,
if (peer[n].current_weight * 1000 / peer[i].current_weight > peer[n].weight * 1000 / peer[i].weight) //peer[i].current_weight不為0
並且該server的current_weight大於0，就選擇sever n, 把編號n賦給rrp->current，成功返回。
假如當upstream的peers陣列中的所有server的current_weight都為零時，立即無條件地把所有server的current_weight設定為初始值。for (i = 0; i < peers->number; i++) {
peer[i].current_weight = peer[i].weight;
}
然後，當所有server的current_weight設定為初始值後，重新查詢peers 陣列中current_weight最大的server。把編號賦給rrp->current，返回。
2.2.2 判定當前rrp->current所指向的server是否有效，假如無效，就會讓rrp->current++，判定peers陣列中下一個server，是否有效。至到找到有效的server為止. 跳轉到2.2.3; 否則跳轉到2.2.2.1
判定server是否有效的方法是：
1）假如server的失敗次數（peers->peer[i].fails）沒有達到了max_fails所設定的最大失敗次數，則該server是有效的。
2）假如server已經達到了max_fails所設定的最大失敗次數，從這一時刻開始算起，在fail_timeout 所設定的時間段內，server是無效的。
3）當server的失敗次數（peers->peer[i].fails）為最大的失敗次數，當間隔現在的時間超過了fail_timeout 所設定的時間段， 則令peers->peer[i].fails =0，使得該server重新有效。
2.2.2.1假如peers中所有的server都是無效的; 就會嘗試往backup的陣列中找一個有效的server, 假如找到， 跳轉到2.2.3; 假如仍然找不到，表示此時upstream中無server可以使用。就會清空所有peers陣列中所有的失敗次數的記錄，使所有server都變成了有效。這樣做的目的是為了防止下次再有請求訪問時，仍找不到一個有效的server.
for (i = 0; i < peers->number; i++) {
peers->peer[i].fails = 0;
}
並返回錯誤碼給nginx, nginx得到此錯誤碼後，就不再向後臺server發請求，而是在nginx的錯誤日誌中輸出“no live upstreams while connecting to upstream”的記錄（這就是no live產生的真正原因），並直接返回給請求的客戶端一個502的錯誤。
2.2.3 當找到一個有效的server後，令該server的current_weight減一，然後，nginx就會嘗試與該server建立連線。假如成功建立連線，跳轉到2.2.4; 否則 跳轉到2.2..3.1
2.2..3.1 假如nginx在等待了proxy_connect_timeout所設定的時間段後（如3秒），連線仍然沒有建立成功，nginx就在錯誤日誌中輸出“upstream timed out (110: Connection timed out) while connecting to upstream”的記錄（這就是timed out（連線超時）產生的真正原因）.
2.2.3 .2 接著，讓當前server的失敗次數加一（peer->fails++; 假如該server最大失敗次達到最大失敗次數，將在一段時間內該server是無效的），假如當前nginx與後臺伺服器的嘗試次數沒有達到upstream中server的總個數，重新跳轉到2.2.2, 輪循下一個server, 繼續嘗試。假如達到最大嘗試次數，就表示uptream中所有的server都嘗試了一遍，沒有server可以提供服務，返回一個504的錯誤給客戶端。
2.2.4 當nginx與server建立連線成功後，假如server響應請求，把處理結果返回給nginx,
跳轉到2.2.5; 否則跳轉到2.2.4.1
2.2.4.1 假如nginx在等待了proxy_read_timeout所設定的時間段後（如30秒），server仍然沒有對nginx傳送來的請求作出響應，nginx就在錯誤日誌中輸出“upstream timed out (110: Connection timed out)while reading response header from upstream”的記錄（這就是timed out（讀超時）產生的真正原因）.
2.2.4.2 接著，讓當前server的失敗次數加一（peer->fails++; 假如該server最大失敗次達到最大失敗次數，將在一段時間內該server是無效的），假如當前nginx與後臺伺服器的嘗試次數沒有達到upstream中server的總個數，重新跳轉到2.2.2, 輪循下一個server, 繼續嘗試。假如達到最大嘗試次數，就表示uptream中所有的server都嘗試了一遍，沒有server可以提供服務，返回一個504的錯誤給客戶端。
2.2.5 Nginx收到後臺server傳送過來的結果後，就會返回給客戶端一個200的正確結果。這樣，nginx作為反向代理的功能也就完成了。
三、Ip_hash策略
3.1 Ip_hash和RR 的策略有兩點不同在於：
當一個客戶請求到nginx後，
1）nginx如何選擇一個最初的server,
2）以及當前選擇的server不能提供服務時，如何選擇下一個server.
3.2 RR策略回顧
從第二部分對RR的先容中，我們知道：
當一個客戶請求到達後，RR策略是從upstream的所有server中選擇一個當前權重（current_weight）最大的server作為最初的server.
upstream的所有server是按照由高到低排序後儲存在一個peers陣列中，當最初選擇的server不能提供服務時，RR策略就會選擇peers陣列中的下一個元素作為當前server，繼續嘗試， 假如已經達到陣列的最大元素，就會從第一個元素再輪循。
3.3 ip_hash策略先容
在ip_hash策略中，它選擇最初的server的方法是根據請求客戶真個IP計算出一個雜湊值，再根據雜湊值選擇後臺的伺服器。
1）由IP計算雜湊值的演算法如下， 其中公式中hash初始值為89，iphp->addr[i]表示客戶真個IP， 通過三次雜湊計算得出一個IP的雜湊值：
for (i = 0; i < 3; i++) {
hash = (hash * 113 + iphp->addr[i]) % 6271;
}
2）在選擇下一個server時，ip_hash的選擇策略是這樣的：
它在上一次雜湊值的基礎上，再次雜湊，就會得到一個全新的雜湊值，再根據雜湊值選擇另外一個後臺的伺服器。
雜湊演算法仍然是
for (i = 0; i < 3; i++) {
hash = (hash * 113 + iphp->addr[i]) % 6271;
} 在這種ip_hash策略，假如一個後臺伺服器不能提供提服務（連線超時或讀超時），該伺服器的失敗次數就會加一，當一個伺服器的失敗次數達到max_fails所設定的值，就會在fail_timeout所設定的時間段內不能對外提供服務，這點和RR是一致的。
假如當前server不能提供服務，就會根據當前的雜湊值再雜湊出一個新雜湊值，選擇另一個伺服器繼續嘗試，嘗試的最大次是upstream中server的個數，假如serwin7ver的個數超過20，也就是要最大嘗試次數在20次以上，當嘗試次數達到20次，仍然找不到一個合適的伺服器，ip_hah策略不再嘗試ip雜湊值來選擇server, 而在剩餘的嘗試中，它會轉而使用RR的策略，使用輪循的方法，選擇新的server。
3）除了以上部分不同外，IP_hash的其餘部分和RR完全一樣，由於它的其餘部分功能的實現都是通過呼叫RR中的函式。
4）IP_hash上風是把同一個客戶IP的請求分配給同一個後臺伺服器。
1、RR（預設）
每個請求按時間順序逐一分配到不同的後端伺服器，假如後端伺服器down掉，能自動剔除。
例如：
upstream tomcats {
server 10.1.1.107:88 max_fails=3 fail_timeout=3s weight=9;
server 10.1.1.132:80 max_fails=3 fail_timeout=3s weight=9;
}
2、ip_hash
每個請求按訪問ip的hash結果分配，這樣每個訪客固定訪問一個後端伺服器，可以解決session的題目。
例如：
upstream tomcats {
ip_hash;
server 10.1.1.107:88;
server 10.1.1.132:80;
}
3、fair（第三方）
按後端伺服器的響應時間來分配請求，響應時間短的優先分配。
4、url_hash（第三方）
按訪問url的hash結果來分配請求，使每個url定向到同一個後端伺服器，後端伺服器為快取時比較有效。
下面，我們針對RR和ip_hash的負載均衡策略進行分析。由於每一種負載均衡策略都是在upstream的框架中使用，upstream控制總的工作流程，負載均衡策略僅僅提供選擇或開釋server的函式，所以，我們在分析RR時結合upstream（ngx_http_upstream.c）。ip_hash大部分內容與RR一致，只是重新實現RR中的ngx_http_upstream_get_peer函式。
二、RR策略
RR機制分為三個部分：初始化upstream，獲取一個可用的後臺伺服器和開釋後臺伺服器。
以下分析以此配置為例:
upstream backend {
server A max_fails=3 fail_timeout=4s weight=9;
server B max_fails=3 fail_timeout=4s weight=9;
server C max_fails=3 fail_timeout=4s weight=9;
server D backup;
Server E backup;
}
2.1 初始化upstream
對於例子中的upstream backend來說，
首先初始化各個server, 除了設定IP和埠號外，還要設定如下置weight，current_weight，max_fails和fail_timeout。其中max_fails和fail_timeout 這兩個引數是組合使用的，表示server 假如失敗次數達到max_fails 次，並保持fail_timeout秒之內該伺服器不能被訪問。
對於serverA來說，設定如下
serverA.weight =9;
serverA.current_weight = 9; //初始值即是配置檔案中的weight.
serverA.max_fails = 3;
serverA.fail_timeout = 4;
接著，建立兩個server型別（在下文先容中，server型別等同於peer型別，都是用來指明儲存upstream中一個server的資訊）的陣列，peers和backup，分別儲存正常的輪循server和備用server. 並竊冬按照陣列中各個server的weight值的大小，由高到底排序。
本例中，在陣列peers中儲存serverA、serverB和serverC, 並記錄server的總個數peers->number=3; 在陣列backup中儲存serverD和serverE, 並記錄server的總個數backup->number=2;
最後，設定upstream中各個變數的值。
rrp 表示當前要輪循的server陣列，初始設定為Upstream->rrp = peers.
tries 表示嘗試的次數，當嘗試一個server失敗後，tries的值就會減一。初始設定為peers的總個數。
Next 表示當peers陣列中server都失敗，不能提供服務了，通過upstream->next，切換到back陣列中選擇server.
2.2 具體的RR策略
2.2.1 ） 選擇最初要輪循的server, 把它給rrp->current變數，跳轉到2.2.2 當一個客戶端請求到達nginx後，nginx就會在upstream的peers 陣列中挑選一個current_weight最大的server作為當前請求最初要輪循的server. 在peers陣列中選取current_weight最大的演算法如下：
由於peers陣列中的server是按照weight值的大小排序好的。
它是通過雙重迴圈，滿足下列條件後,
if (peer[n].current_weight * 1000 / peer[i].current_weight > peer[n].weight * 1000 / peer[i].weight) //peer[i].current_weight不為0
並且該server的current_weight大於0，就選擇sever n, 把編號n賦給rrp->current，成功返回。
假如當upstream的peers陣列中的所有server的current_weight都為零時，立即無條件地把所有server的current_weight設定為初始值。for (i = 0; i < peers->number; i++) {
peer[i].current_weight = peer[i].weight;
}
然後，當所有server的current_weight設定為初始值後，重新查詢peers 陣列中current_weight最大的server。把編號賦給rrp->current，返回。
2.2.2 判定當前rrp->current所指向的server是否有效，假如無效，就會讓rrp->current++，判定peers陣列中下一個server，是否有效。至到找到有效的server為止. 跳轉到2.2.3; 否則跳轉到2.2.2.1
判定server是否有效的方法是：
1）假如server的失敗次數（peers->peer[i].fails）沒有達到了max_fails所設定的最大失敗次數，則該server是有效的。
2）假如server已經達到了max_fails所設定的最大失敗次數，從這一時刻開始算起，在fail_timeout 所設定的時間段內，server是無效的。
3）當server的失敗次數（peers->peer[i].fails）為最大的失敗次數，當間隔現在的時間超過了fail_timeout 所設定的時間段， 則令peers->peer[i].fails =0，使得該server重新有效。
2.2.2.1假如peers中所有的server都是無效的; 就會嘗試往backup的陣列中找一個有效的server, 假如找到， 跳轉到2.2.3; 假如仍然找不到，表示此時upstream中無server可以使用。就會清空所有peers陣列中所有的失敗次數的記錄，使所有server都變成了有效。這樣做的目的是為了防止下次再有請求訪問時，仍找不到一個有效的server.
for (i = 0; i < peers->number; i++) {
peers->peer[i].fails = 0;
}
並返回錯誤碼給nginx, nginx得到此錯誤碼後，就不再向後臺server發請求，而是在nginx的錯誤日誌中輸出“no live upstreams while connecting to upstream”的記錄（這就是no live產生的真正原因），並直接返回給請求的客戶端一個502的錯誤。
2.2.3 當找到一個有效的server後，令該server的current_weight減一，然後，nginx就會嘗試與該server建立連線。假如成功建立連線，跳轉到2.2.4; 否則 跳轉到2.2..3.1
2.2..3.1 假如nginx在等待了proxy_connect_timeout所設定的時間段後（如3秒），連線仍然沒有建立成功，nginx就在錯誤日誌中輸出“upstream timed out (110: Connection timed out) while connecting to upstream”的記錄（這就是timed out（連線超時）產生的真正原因）.
2.2.3 .2 接著，讓當前server的失敗次數加一（peer->fails++; 假如該server最大失敗次達到最大失敗次數，將在一段時間內該server是無效的），假如當前nginx與後臺伺服器的嘗試次數沒有達到upstream中server的總個數，重新跳轉到2.2.2, 輪循下一個server, 繼續嘗試。假如達到最大嘗試次數，就表示uptream中所有的server都嘗試了一遍，沒有server可以提供服務，返回一個504的錯誤給客戶端。
2.2.4 當nginx與server建立連線成功後，假如server響應請求，把處理結果返回給nginx,
跳轉到2.2.5; 否則跳轉到2.2.4.1
2.2.4.1 假如nginx在等待了proxy_read_timeout所設定的時間段後（如30秒），server仍然沒有對nginx傳送來的請求作出響應，nginx就在錯誤日誌中輸出“upstream timed out (110: Connection timed out)while reading response header from upstream”的記錄（這就是timed out（讀超時）產生的真正原因）.
2.2.4.2 接著，讓當前server的失敗次數加一（peer->fails++; 假如該server最大失敗次達到最大失敗次數，將在一段時間內該server是無效的），假如當前nginx與後臺伺服器的嘗試次數沒有達到upstream中server的總個數，重新跳轉到2.2.2, 輪循下一個server, 繼續嘗試。假如達到最大嘗試次數，就表示uptream中所有的server都嘗試了一遍，沒有server可以提供服務，返回一個504的錯誤給客戶端。
2.2.5 Nginx收到後臺server傳送過來的結果後，就會返回給客戶端一個200的正確結果。這樣，nginx作為反向代理的功能也就完成了。
三、Ip_hash策略
3.1 Ip_hash和RR 的策略有兩點不同在於：
當一個客戶請求到nginx後，
1）nginx如何選擇一個最初的server,
2）以及當前選擇的server不能提供服務時，如何選擇下一個server.
3.2 RR策略回顧
從第二部分對RR的先容中，我們知道：
當一個客戶請求到達後，RR策略是從upstream的所有server中選擇一個當前權重（current_weight）最大的server作為最初的server.
upstream的所有server是按照由高到低排序後儲存在一個peers陣列中，當最初選擇的server不能提供服務時，RR策略就會選擇peers陣列中的下一個元素作為當前server，繼續嘗試， 假如已經達到陣列的最大元素，就會從第一個元素再輪循。
3.3 ip_hash策略先容
在ip_hash策略中，它選擇最初的server的方法是根據請求客戶真個IP計算出一個雜湊值，再根據雜湊值選擇後臺的伺服器。
1）由IP計算雜湊值的演算法如下， 其中公式中hash初始值為89，iphp->addr[i]表示客戶真個IP， 通過三次雜湊計算得出一個IP的雜湊值：
for (i = 0; i < 3; i++) {
hash = (hash * 113 + iphp->addr[i]) % 6271;
}
2）在選擇下一個server時，ip_hash的選擇策略是這樣的：
它在上一次雜湊值的基礎上，再次雜湊，就會得到一個全新的雜湊值，再根據雜湊值選擇另外一個後臺的伺服器。
雜湊演算法仍然是
for (i = 0; i < 3; i++) {
hash = (hash * 113 + iphp->addr[i]) % 6271;
} 在這種ip_hash策略，假如一個後臺伺服器不能提供提服務（連線超時或讀超時），該伺服器的失敗次數就會加一，當一個伺服器的失敗次數達到max_fails所設定的值，就會在fail_timeout所設定的時間段內不能對外提供服務，這點和RR是一致的。
假如當前server不能提供服務，就會根據當前的雜湊值再雜湊出一個新雜湊值，選擇另一個伺服器繼續嘗試，嘗試的最大次是upstream中server的個數，假如serwin7ver的個數超過20，也就是要最大嘗試次數在20次以上，當嘗試次數達到20次，仍然找不到一個合適的伺服器，ip_hah策略不再嘗試ip雜湊值來選擇server, 而在剩餘的嘗試中，它會轉而使用RR的策略，使用輪循的方法，選擇新的server。
3）除了以上部分不同外，IP_hash的其餘部分和RR完全一樣，由於它的其餘部分功能的實現都是通過呼叫RR中的函式。
4）IP_hash上風是把同一個客戶IP的請求分配給同一個後臺伺服器。