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

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

負(fù)載均衡的算法

round robin 輪詢 rr

負(fù)載均衡的默認(rèn)算法，請(qǐng)求輪流分配給后端服務(wù)器。

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

默認(rèn)

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

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

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

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

weight=number

ip_Hash

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

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

負(fù)載均衡的會(huì)話保持——>ip_Hash

會(huì)話保持到期之后，會(huì)話中斷，重新請(qǐng)求會(huì)重新計(jì)算hash值。

ip_hash；

最小連接數(shù)

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

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

least_conn；

weight=number

URL_Hash

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

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

hash_$request_uri? consistest；

負(fù)載均衡的特點(diǎn)

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

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

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

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

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

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

我們做個(gè)實(shí)驗(yàn)，三臺(tái)主機(jī)，具體配置如下：

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

zw5：192.168.254.15（后端）

zw6：192.168.254.16（后端）

客戶端：瀏覽器

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

七層代理

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

upstream：只能寫在http模塊當(dāng)中，不能在server也不能在全局。

基于IP的七層

輪詢

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

加權(quán)輪詢

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

ip_hash

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

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

這時(shí)候和輪詢沒什么區(qū)別，這是因?yàn)椴缓醚菔咀钚∵B接數(shù)，狀態(tài)碼依然為200。

URL_hash

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

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

基于域名的七層

?基于域名的七層代理

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

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

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

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

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

四層代理

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

四層代理只能寫在全局模塊當(dāng)中。

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

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

注意：

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

ip_hash和uri_hash，不能在四層算法中使用，因?yàn)樗膶硬荒芴幚眄憫?yīng)。