負載均衡：將四層或者七層的請求分配到多臺后端的服務(wù)器上。

從而分擔整個業(yè)務(wù)的負載。提高系統(tǒng)的穩(wěn)定性，也可以提高高可用（備災(zāi)，其中一臺后端服務(wù)器如果發(fā)生故障不影響整體業(yè)務(wù)）.

負載均衡的算法

round robin 輪詢 rr

負載均衡的默認算法，請求輪流分配給后端服務(wù)器。

輪詢算法適合用于后端處理器能力相近的情況，默認的算法，可以不加。

默認

加權(quán)輪詢-weight round robin

輪詢的升級版，給每個后端服務(wù)器賦予不同的權(quán)重。

處理能力更強的服務(wù)器設(shè)置更高的權(quán)重，處理能力低的設(shè)置低權(quán)重。

高峰時間可以通過這個方法進行流量的優(yōu)化，適用于服務(wù)器處理能力差異比較大的情況。

weight=number

ip_Hash

當我們訪問后端服務(wù)器，根據(jù)客戶端的IP地址，使用hash算法計算出IP地址的hash值，然后再根據(jù)請求發(fā)送到相應(yīng)的后端服務(wù)器。

如果客戶端訪問的ip地址相同，通過hash算法，再一次的請求會分配到上一次訪問的服務(wù)器，保證會話的穩(wěn)定。

負載均衡的會話保持——>ip_Hash

會話保持到期之后，會話中斷，重新請求會重新計算hash值。

ip_hash；

最小連接數(shù)

配合加權(quán)輪詢一起使用，最小連接數(shù)的算法可以將請求發(fā)送到當前連接比較少的后端服務(wù)器。

這種算法適用后端服務(wù)器處理任務(wù)耗時不同的情況，可以有效的避免所有的請求集中在處理能力更強的后端服務(wù)器上。

least_conn；

weight=number

URL_Hash

根據(jù)請求當中url地址來計算hash值，如果客戶端請求的url地址相同，客戶端的請求會被分配到同一個服務(wù)器。

后臺服務(wù)器的數(shù)量發(fā)生變化，會影響結(jié)果。（這個討論無意義）

hash_$request_uri? consistest；

負載均衡的特點

1、根據(jù)算法把請求分配到不同的服務(wù)器

2、客戶端訪問的是代理地址，響應(yīng)也是代理服務(wù)器響應(yīng)。

3、客戶端并不了解后端服務(wù)器的情況

4、可以提高安全性，后端服務(wù)器是隱藏的。

5、負載均衡是有緩存的，可以直接訪問緩存，提高響應(yīng)的速度。

負載均衡的架構(gòu)

我們做個實驗，三臺主機，具體配置如下：

zw4：192.168.254.14（代理服務(wù)器）

zw5：192.168.254.15（后端）

zw6：192.168.254.16（后端）

客戶端：瀏覽器

配置流量分發(fā)，主要是依靠服務(wù)器完成的，主要配置在代理服務(wù)器完成配置算法。

七層代理

upstream：模塊僅支持http協(xié)議，用來處理http的請求和響應(yīng)。

upstream：只能寫在http模塊當中，不能在server也不能在全局。

基于IP的七層

輪詢

配置完之后，我們訪問主機（192.168.254.14）的nginx，會發(fā)現(xiàn)輪流訪問的是設(shè)定的2臺服務(wù)器的nginx，并且狀態(tài)碼為200，表示沒有緩存。

加權(quán)輪詢

這時候權(quán)重高的服務(wù)器被訪問的次數(shù)多一點，狀態(tài)碼依然為200，沒有緩存。

ip_hash

這時候第一次會根據(jù)hash算法匹配到一臺服務(wù)器，之后再訪問都是他了，并且狀態(tài)碼為304，表示訪問緩存，這是根據(jù)IP地址的hash緩存，也是會話保持。

最小連接數(shù)配合輪詢

這時候和輪詢沒什么區(qū)別，這是因為不好演示最小連接數(shù)，狀態(tài)碼依然為200。

URL_hash

這時候第一次會根據(jù)算法匹配到一臺服務(wù)器，之后再訪問都是他了，并且狀態(tài)碼為304表示緩存。注意：這里的緩存是url緩存，url地址不變才導(dǎo)致的訪問服務(wù)器不變，并不是真正的會話保持。

最后我們停掉192.168.254.15的nginx后，會發(fā)現(xiàn)負載均衡依然再正常運行，并且只能訪問192.168.254.16的nginx，證明了高可用。

基于域名的七層

?基于域名的七層代理

首先配置代理服務(wù)器zw4的nginx主配置文件

注意：1、如果使用域名才做七層，需要把客戶端訪問的真實IP地址傳遞給服務(wù)端

? ? ? ? ? ?2、如果經(jīng)過代理，所有經(jīng)過的代理地址也要傳遞給服務(wù)端

接著三臺主機都配置域名解析，記得也要修改另外兩臺后端（zw5和zw6）的nginx上的localhost。

這時候我們發(fā)現(xiàn)負載均衡已正常工作，當然也是默認的輪詢算法。

四層代理

stream：模塊不支持http協(xié)議，僅支持tcp和udp，處理數(shù)據(jù)包流量分發(fā)。

四層代理只能寫在全局模塊當中。

根據(jù)上面的實驗我們依然在代理服務(wù)器zw4上配置nginx的主配置文件，注意server中的端口號不能和下面http模塊中server的端口號一樣，所有這里我們隨便定了個81。

重啟nginx后，我們發(fā)現(xiàn)負載均衡的算法依然是輪詢。

注意：

四層算法默認是輪詢，也支持加權(quán)輪詢和最小連接數(shù)支持。

ip_hash和uri_hash，不能在四層算法中使用，因為四層不能處理響應(yīng)。