千萬(wàn)級(jí)流量架構(gòu)下的負(fù)載均衡解析

本人免費(fèi)整理了Java高級(jí)資料，涵蓋了Java、Redis、MongoDB、MySQL、Zookeeper、Spring Cloud、Dubbo高并發(fā)分布式等教程，一共30G，需要自己領(lǐng)取。
傳送門：https://mp.weixin.qq.com/s/JzddfH-7yNudmkjT0IRL8Q

一、負(fù)載均衡

• 負(fù)載均衡算法

• 轉(zhuǎn)發(fā)實(shí)現(xiàn)

• 二、集群下的 Session 管理

• Sticky Session

• Session Replication

• Session Server

一、負(fù)載均衡

集群中的應(yīng)用服務(wù)器（節(jié)點(diǎn)）通常被設(shè)計(jì)成無(wú)狀態(tài)，用戶可以請(qǐng)求任何一個(gè)節(jié)點(diǎn)。

負(fù)載均衡器會(huì)根據(jù)集群中每個(gè)節(jié)點(diǎn)的負(fù)載情況，將用戶請(qǐng)求轉(zhuǎn)發(fā)到合適的節(jié)點(diǎn)上。

負(fù)載均衡器可以用來(lái)實(shí)現(xiàn)高可用以及伸縮性：

• 高可用：當(dāng)某個(gè)節(jié)點(diǎn)故障時(shí)，負(fù)載均衡器會(huì)將用戶請(qǐng)求轉(zhuǎn)發(fā)到另外的節(jié)點(diǎn)上，從而保證所有服務(wù)持續(xù)可用；

• 伸縮性：根據(jù)系統(tǒng)整體負(fù)載情況，可以很容易地添加或移除節(jié)點(diǎn)。

負(fù)載均衡器運(yùn)行過(guò)程包含兩個(gè)部分：

1. 根據(jù)負(fù)載均衡算法得到轉(zhuǎn)發(fā)的節(jié)點(diǎn)；

2. 進(jìn)行轉(zhuǎn)發(fā)。

負(fù)載均衡算法

1. 輪詢（Round Robin）

輪詢算法把每個(gè)請(qǐng)求輪流發(fā)送到每個(gè)服務(wù)器上。

下圖中，一共有 6 個(gè)客戶端產(chǎn)生了 6 個(gè)請(qǐng)求，這 6 個(gè)請(qǐng)求按 (1, 2, 3, 4, 5, 6) 的順序發(fā)送。(1, 3, 5) 的請(qǐng)求會(huì)被發(fā)送到服務(wù)器 1，(2, 4, 6) 的請(qǐng)求會(huì)被發(fā)送到服務(wù)器 2。

該算法比較適合每個(gè)服務(wù)器的性能差不多的場(chǎng)景，如果有性能存在差異的情況下，那么性能較差的服務(wù)器可能無(wú)法承擔(dān)過(guò)大的負(fù)載（下圖的 Server 2）。

2. 加權(quán)輪詢（Weighted Round Robbin）

加權(quán)輪詢是在輪詢的基礎(chǔ)上，根據(jù)服務(wù)器的性能差異，為服務(wù)器賦予一定的權(quán)值，性能高的服務(wù)器分配更高的權(quán)值。

例如下圖中，服務(wù)器 1 被賦予的權(quán)值為 5，服務(wù)器 2 被賦予的權(quán)值為 1，那么 (1, 2, 3, 4, 5) 請(qǐng)求會(huì)被發(fā)送到服務(wù)器 1，(6) 請(qǐng)求會(huì)被發(fā)送到服務(wù)器 2。

3. 最少連接（least Connections）

由于每個(gè)請(qǐng)求的連接時(shí)間不一樣，使用輪詢或者加權(quán)輪詢算法的話，可能會(huì)讓一臺(tái)服務(wù)器當(dāng)前連接數(shù)過(guò)大，而另一臺(tái)服務(wù)器的連接過(guò)小，造成負(fù)載不均衡。

例如下圖中，(1, 3, 5) 請(qǐng)求會(huì)被發(fā)送到服務(wù)器 1，但是 (1, 3) 很快就斷開(kāi)連接，此時(shí)只有 (5) 請(qǐng)求連接服務(wù)器 1；(2, 4, 6) 請(qǐng)求被發(fā)送到服務(wù)器 2，只有 (2) 的連接斷開(kāi)，此時(shí) (6, 4) 請(qǐng)求連接服務(wù)器 2。該系統(tǒng)繼續(xù)運(yùn)行時(shí)，服務(wù)器 2 會(huì)承擔(dān)過(guò)大的負(fù)載。

最少連接算法就是將請(qǐng)求發(fā)送給當(dāng)前最少連接數(shù)的服務(wù)器上。

例如下圖中，服務(wù)器 1 當(dāng)前連接數(shù)最小，那么新到來(lái)的請(qǐng)求 6 就會(huì)被發(fā)送到服務(wù)器 1 上。

4. 加權(quán)最少連接（Weighted Least Connection）

在最少連接的基礎(chǔ)上，根據(jù)服務(wù)器的性能為每臺(tái)服務(wù)器分配權(quán)重，再根據(jù)權(quán)重計(jì)算出每臺(tái)服務(wù)器能處理的連接數(shù)。

5. 隨機(jī)算法（Random）

把請(qǐng)求隨機(jī)發(fā)送到服務(wù)器上。

和輪詢算法類似，該算法比較適合服務(wù)器性能差不多的場(chǎng)景。

6. 源地址哈希法 (IP Hash)

源地址哈希通過(guò)對(duì)客戶端 IP 計(jì)算哈希值之后，再對(duì)服務(wù)器數(shù)量取模得到目標(biāo)服務(wù)器的序號(hào)。

可以保證同一 IP 的客戶端的請(qǐng)求會(huì)轉(zhuǎn)發(fā)到同一臺(tái)服務(wù)器上，用來(lái)實(shí)現(xiàn)會(huì)話粘滯（Sticky Session）

轉(zhuǎn)發(fā)實(shí)現(xiàn)

1. HTTP 重定向

HTTP 重定向負(fù)載均衡服務(wù)器使用某種負(fù)載均衡算法計(jì)算得到服務(wù)器的 IP 地址之后，將該地址寫入 HTTP 重定向報(bào)文中，狀態(tài)碼為 302?？蛻舳耸盏街囟ㄏ驁?bào)文之后，需要重新向服務(wù)器發(fā)起請(qǐng)求。

缺點(diǎn)：

• 需要兩次請(qǐng)求，因此訪問(wèn)延遲比較高；

• HTTP 負(fù)載均衡器處理能力有限，會(huì)限制集群的規(guī)模。

該負(fù)載均衡轉(zhuǎn)發(fā)的缺點(diǎn)比較明顯，實(shí)際場(chǎng)景中很少使用它。

2. DNS 域名解析

在 DNS 解析域名的同時(shí)使用負(fù)載均衡算法計(jì)算服務(wù)器 IP 地址。

優(yōu)點(diǎn)：

• DNS 能夠根據(jù)地理位置進(jìn)行域名解析，返回離用戶最近的服務(wù)器 IP 地址。

缺點(diǎn)：

• 由于 DNS 具有多級(jí)結(jié)構(gòu)，每一級(jí)的域名記錄都可能被緩存，當(dāng)下線一臺(tái)服務(wù)器需要修改 DNS 記錄時(shí)，需要過(guò)很長(zhǎng)一段時(shí)間才能生效。

大型網(wǎng)站基本使用了 DNS 做為第一級(jí)負(fù)載均衡手段，然后在內(nèi)部使用其它方式做第二級(jí)負(fù)載均衡。也就是說(shuō)，域名解析的結(jié)果為內(nèi)部的負(fù)載均衡服務(wù)器 IP 地址。

3. 反向代理服務(wù)器

反向代理服務(wù)器位于源服務(wù)器前面，用戶的請(qǐng)求需要先經(jīng)過(guò)反向代理服務(wù)器才能到達(dá)源服務(wù)器。反向代理可以用來(lái)進(jìn)行緩存、日志記錄等，同時(shí)也可以用來(lái)做為負(fù)載均衡服務(wù)器。

在這種負(fù)載均衡轉(zhuǎn)發(fā)方式下，客戶端不直接請(qǐng)求源服務(wù)器，因此源服務(wù)器不需要外部 IP 地址，而反向代理需要配置內(nèi)部和外部?jī)商?IP 地址。

優(yōu)點(diǎn)：

• 與其它功能集成在一起，部署簡(jiǎn)單。

缺點(diǎn)：

• 所有請(qǐng)求和響應(yīng)都需要經(jīng)過(guò)反向代理服務(wù)器，它可能會(huì)成為性能瓶頸。

4. 網(wǎng)絡(luò)層

在操作系統(tǒng)內(nèi)核進(jìn)程獲取網(wǎng)絡(luò)數(shù)據(jù)包，根據(jù)負(fù)載均衡算法計(jì)算源服務(wù)器的 IP 地址，并修改請(qǐng)求數(shù)據(jù)包的目的 IP 地址，最后進(jìn)行轉(zhuǎn)發(fā)。

源服務(wù)器返回的響應(yīng)也需要經(jīng)過(guò)負(fù)載均衡服務(wù)器，通常是讓負(fù)載均衡服務(wù)器同時(shí)作為集群的網(wǎng)關(guān)服務(wù)器來(lái)實(shí)現(xiàn)。

優(yōu)點(diǎn)：

• 在內(nèi)核進(jìn)程中進(jìn)行處理，性能比較高。

缺點(diǎn)：

• 和反向代理一樣，所有的請(qǐng)求和響應(yīng)都經(jīng)過(guò)負(fù)載均衡服務(wù)器，會(huì)成為性能瓶頸。

5. 鏈路層

在鏈路層根據(jù)負(fù)載均衡算法計(jì)算源服務(wù)器的 MAC 地址，并修改請(qǐng)求數(shù)據(jù)包的目的 MAC 地址，并進(jìn)行轉(zhuǎn)發(fā)。

通過(guò)配置源服務(wù)器的虛擬 IP 地址和負(fù)載均衡服務(wù)器的 IP 地址一致，從而不需要修改 IP 地址就可以進(jìn)行轉(zhuǎn)發(fā)。也正因?yàn)?IP 地址一樣，所以源服務(wù)器的響應(yīng)不需要轉(zhuǎn)發(fā)回負(fù)載均衡服務(wù)器，可以直接轉(zhuǎn)發(fā)給客戶端，避免了負(fù)載均衡服務(wù)器的成為瓶頸。

這是一種三角傳輸模式，被稱為直接路由。對(duì)于提供下載和視頻服務(wù)的網(wǎng)站來(lái)說(shuō)，直接路由避免了大量的網(wǎng)絡(luò)傳輸數(shù)據(jù)經(jīng)過(guò)負(fù)載均衡服務(wù)器。

這是目前大型網(wǎng)站使用最廣負(fù)載均衡轉(zhuǎn)發(fā)方式，在 Linux 平臺(tái)可以使用的負(fù)載均衡服務(wù)器為 LVS（Linux Virtual Server）。

參考：

• Comparing Load Balancing Algorithms

• Redirection and Load Balancing

二、集群下的 Session 管理

一個(gè)用戶的 Session 信息如果存儲(chǔ)在一個(gè)服務(wù)器上，那么當(dāng)負(fù)載均衡器把用戶的下一個(gè)請(qǐng)求轉(zhuǎn)發(fā)到另一個(gè)服務(wù)器，由于服務(wù)器沒(méi)有用戶的 Session 信息，那么該用戶就需要重新進(jìn)行登錄等操作。

Sticky Session

需要配置負(fù)載均衡器，使得一個(gè)用戶的所有請(qǐng)求都路由到同一個(gè)服務(wù)器，這樣就可以把用戶的 Session 存放在該服務(wù)器中。

缺點(diǎn)：

• 當(dāng)服務(wù)器宕機(jī)時(shí)，將丟失該服務(wù)器上的所有 Session。

Session Replication

在服務(wù)器之間進(jìn)行 Session 同步操作，每個(gè)服務(wù)器都有所有用戶的 Session 信息，因此用戶可以向任何一個(gè)服務(wù)器進(jìn)行請(qǐng)求。

缺點(diǎn)：

• 占用過(guò)多內(nèi)存；

• 同步過(guò)程占用網(wǎng)絡(luò)帶寬以及服務(wù)器處理器時(shí)間。

Session Server

使用一個(gè)單獨(dú)的服務(wù)器存儲(chǔ) Session 數(shù)據(jù)，可以使用傳統(tǒng)的 MySQL，也使用 Redis 或者 Memcached 這種內(nèi)存型數(shù)據(jù)庫(kù)。

優(yōu)點(diǎn)：

• 為了使得大型網(wǎng)站具有伸縮性，集群中的應(yīng)用服務(wù)器通常需要保持無(wú)狀態(tài)，那么應(yīng)用服務(wù)器不能存儲(chǔ)用戶的會(huì)話信息。Session Server 將用戶的會(huì)話信息單獨(dú)進(jìn)行存儲(chǔ)，從而保證了應(yīng)用服務(wù)器的無(wú)狀態(tài)。

缺點(diǎn)：

• 需要去實(shí)現(xiàn)存取 Session 的代碼。