什么是負(fù)載均衡，原理是什么？

一、什么是負(fù)載均衡

負(fù)載均衡（LoadBalance）

其意思就是分?jǐn)偟蕉鄠€操作單元上進行執(zhí)行，例如Web服務(wù)器、FTP服務(wù)器、企業(yè)關(guān)鍵應(yīng)用服務(wù)器和其它關(guān)鍵任務(wù)服務(wù)器等，從而共同完成工作任務(wù)。

單從字面上的意思來理解就可以解釋N臺服務(wù)器平均分擔(dān)負(fù)載，不會因為某臺服務(wù)器負(fù)載高宕機而某臺服務(wù)器閑置的情況。那么負(fù)載均衡的前提就是要有多臺服務(wù)器才能實現(xiàn)，也就是兩臺以上即可。

二、負(fù)載均衡的優(yōu)

減少服務(wù)器的壓力，將原本一臺服務(wù)器索要承受的訪問量分給多臺，并提高項目的可用性，當(dāng)一臺服務(wù)器掛掉的時候不會導(dǎo)致項目癱瘓。

三、四層負(fù)載均衡和七層負(fù)載均衡

四層負(fù)載均衡工作在OSI模型的傳輸層，主要工作是轉(zhuǎn)發(fā)，它在接收到客戶端的流量以后通過修改數(shù)據(jù)包的地址信息將流量轉(zhuǎn)發(fā)到應(yīng)用服務(wù)器。

七層負(fù)載均衡工作在OSI模型的應(yīng)用層，因為它需要解析應(yīng)用層流量，所以七層負(fù)載均衡在接到客戶端的流量以后，還需要一個完整的TCP/IP協(xié)議棧。七層負(fù)載均衡會與客戶端建立一條完整的連接并將應(yīng)用層的請求流量解析出來，再按照調(diào)度算法選擇一個應(yīng)用服務(wù)器，并與應(yīng)用服務(wù)器建立另外一條連接將請求發(fā)送過去，因此七層負(fù)載均衡的主要工作就是代理。 七層負(fù)載均衡 也稱為“內(nèi)容交換”，也就是主要通過報文中的真正有意義的應(yīng)用層內(nèi)容，再加上負(fù)載均衡設(shè)備設(shè)置的服務(wù)器選擇方式，決定最終選擇的內(nèi)部服務(wù)器。

七層負(fù)載均衡的優(yōu)點：這種方式可以對客戶端的請求和服務(wù)器的響應(yīng)進行任意意義上的修改，極大的提升了應(yīng)用系統(tǒng)在網(wǎng)絡(luò)層的靈活性；安全性高。

七層負(fù)載均衡，主要還是著重于應(yīng)用廣泛的HTTP協(xié)議，所以其應(yīng)用范圍主要是眾多的網(wǎng)站或者內(nèi)部信息平臺等基于B/S開發(fā)的系統(tǒng)。 四層負(fù)載均衡則對應(yīng)其他TCP應(yīng)用，例如基于C/S開發(fā)的ERP等系統(tǒng)。

四、負(fù)載均衡的使用軟件

負(fù)載均衡軟件有Nginx、LVS、HaProxy等是目前使用最廣泛的三種負(fù)載均衡軟件。

四、負(fù)載均衡算法

一般來說負(fù)載均衡設(shè)備都會默認(rèn)支持多種負(fù)載均衡分發(fā)策略，例如：

輪詢（RoundRobin）將請求順序循環(huán)地發(fā)到每個服務(wù)器。當(dāng)其中某個服務(wù)器發(fā)生故障，AX就把其從順序循環(huán)隊列中拿出，不參加下一次的輪詢，直到其恢復(fù)正常。

比率（Ratio）：給每個服務(wù)器分配一個加權(quán)值為比例，根椐這個比例，把用戶的請求分配到每個服務(wù)器。當(dāng)其中某個服務(wù)器發(fā)生故障，AX就把其從服務(wù)器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復(fù)正常。

優(yōu)先權(quán)（Priority）：給所有服務(wù)器分組，給每個組定義優(yōu)先權(quán)，將用戶的請求分配給優(yōu)先級高的服務(wù)器組（在同一組內(nèi)，采用預(yù)先設(shè)定的輪詢或比率算法，分配用戶的請求）；當(dāng)高優(yōu)先級中所有服務(wù)器或者指定數(shù)量的服務(wù)器出現(xiàn)故障，AX將把請求送給次優(yōu)先級的服務(wù)器組。這種方式，實際為用戶提供一種熱備份的方式。

最少連接數(shù)（LeastConnection）：AX會記錄當(dāng)前每臺服務(wù)器或者服務(wù)端口上的連接數(shù)，新的連接將傳遞給連接數(shù)最少的服務(wù)器。當(dāng)其中某個服務(wù)器發(fā)生故障，AX就把其從服務(wù)器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復(fù)正常。

最快響應(yīng)時間（Fast Reponse time）：新的連接傳遞給那些響應(yīng)最快的服務(wù)器。當(dāng)其中某個服務(wù)器發(fā)生故障，AX就把其從服務(wù)器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復(fù)正常。

哈希算法( hash): 將客戶端的源地址，端口進行哈希運算，根據(jù)運算的結(jié)果轉(zhuǎn)發(fā)給一臺服務(wù)器進行處理，當(dāng)其中某個服務(wù)器發(fā)生故障，就把其從服務(wù)器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復(fù)正常。

基于數(shù)據(jù)包的內(nèi)容分發(fā)：例如判斷HTTP的URL，如果URL中帶有.jpg的擴展名，就把數(shù)據(jù)包轉(zhuǎn)發(fā)到指定的服務(wù)器。

五、健康檢查

健康檢查用于檢查服務(wù)器開放的各種服務(wù)的可用狀態(tài)。負(fù)載均衡設(shè)備一般會配置各種健康檢查方法，例如Ping，TCP，UDP，HTTP，F(xiàn)TP，DNS等。Ping屬于第三層的健康檢查，用于檢查服務(wù)器IP的連通性，而TCP/UDP屬于第四層的健康檢查，用于檢查服務(wù)端口的UP/DOWN，如果要檢查的更準(zhǔn)確，就要用到基于7層的健康檢查，例如創(chuàng)建一個HTTP健康檢查，Get一個頁面回來，并且檢查頁面內(nèi)容是否包含一個指定的字符串，如果包含，則服務(wù)是UP的，如果不包含或者取不回頁面，就認(rèn)為該服務(wù)器的Web服務(wù)是不可用（DOWN）的。比如，負(fù)載均衡設(shè)備檢查到172.16.20.3這臺服務(wù)器的80端口是DOWN的，負(fù)載均衡設(shè)備將不把后面的連接轉(zhuǎn)發(fā)到這臺服務(wù)器，而是根據(jù)算法將數(shù)據(jù)包轉(zhuǎn)發(fā)到別的服務(wù)器。創(chuàng)建健康檢查時可以設(shè)定檢查的間隔時間和嘗試次數(shù)，例如設(shè)定間隔時間為5秒，嘗試次數(shù)為3，那么負(fù)載均衡設(shè)備每隔5秒發(fā)起一次健康檢查，如果檢查失敗，則嘗試3次，如果3次都檢查失敗，則把該服務(wù)標(biāo)記為DOWN，然后服務(wù)器仍然會每隔5秒對DOWN的服務(wù)器進行檢查，當(dāng)某個時刻發(fā)現(xiàn)該服務(wù)器健康檢查又成功了，則把該服務(wù)器重新標(biāo)記為UP。健康檢查的間隔時間和嘗試次數(shù)要根據(jù)綜合情況來設(shè)置，原則是既不會對業(yè)務(wù)產(chǎn)生影響，又不會對負(fù)載均衡設(shè)備造成較大負(fù)擔(dān)。

六、會話保持

如何保證一個用戶的兩次http請求轉(zhuǎn)發(fā)到同一個服務(wù)器，這就要求負(fù)載均衡設(shè)備配置會話保持。

會話保持用于保持會話的連續(xù)性和一致性，由于服務(wù)器之間很難做到實時同步用戶訪問信息，這就要求把用戶的前后訪問會話保持到一臺服務(wù)器上來處理。舉個例子，用戶訪問一個電子商務(wù)網(wǎng)站，如果用戶登錄時是由第一臺服務(wù)器來處理的，但用戶購買商品的動作卻由第二臺服務(wù)器來處理，第二臺服務(wù)器由于不知道用戶信息，所以本次購買就不會成功。這種情況就需要會話保持，把用戶的操作都通過第一臺服務(wù)器來處理才能成功。當(dāng)然并不是所有的訪問都需要會話保持，例如服務(wù)器提供的是靜態(tài)頁面比如網(wǎng)站的新聞頻道，各臺服務(wù)器都有相同的內(nèi)容，這種訪問就不需要會話保持。

絕大多數(shù)的負(fù)載均衡產(chǎn)品都支持兩類基本的會話保持方式：源/目的地址會話保持和cookie會話保持，另外像hash，URL Persist等也是比較常用的方式，但不是所有設(shè)備都支持。基于不同的應(yīng)用要配置不同的會話保持，否則會引起負(fù)載的不均衡甚至訪問異常。我們主要分析B/S結(jié)構(gòu)的會話保持。

七、基于B/S結(jié)構(gòu)的應(yīng)用：

對于普通B/S結(jié)構(gòu)的應(yīng)用內(nèi)容，例如網(wǎng)站的靜態(tài)頁面，可以不用配置任何的會話保持，但是對于一個基于B/S結(jié)構(gòu)尤其是中間件平臺的業(yè)務(wù)系統(tǒng)來說，必須配置會話保持，一般情況下，我們配置源地址會話保持可以滿足需求，但是考慮到客戶端可能有上述不利于源地址會話保持的環(huán)境，采用Cookie會話保持是一個更好的方式。Cookie會話保持會把負(fù)載均衡設(shè)備選擇的Server信息保存在Cookie中發(fā)送到客戶端，客戶端持續(xù)訪問時，會把該Cookie帶來，負(fù)載均衡器通過分析Cookie把會話保持到之前選定的服務(wù)器。Cookie分為文件Cookie和內(nèi)存cookie，文件cookie保存在客戶端計算機硬盤上，只要該cookie文件不過期，則無論是否重復(fù)關(guān)閉開放瀏覽器都能保持到同一臺服務(wù)器。內(nèi)存Cookie則是把Cookie信息保存在內(nèi)存中，Cookie的生存時間從打開瀏覽器訪問開始，關(guān)閉瀏覽器結(jié)束。由于現(xiàn)在的瀏覽器對Cookie都有一定默認(rèn)的安全設(shè)置，有些客戶端可能規(guī)定不準(zhǔn)使用文件Cookie，所以現(xiàn)在的應(yīng)用程序開發(fā)多使用內(nèi)存Cookie。

然而，內(nèi)存Cookie也不是萬能的，比如瀏覽器為了安全可能會完全禁用Cookie，這樣Cookie會話保持就失去了作用。我們可以通過Session-id來實現(xiàn)會話保持，即將session-id作為url參數(shù)或者放在隱藏字段<input type="hidden">中，然后分析Session-id進行分發(fā)。

另一種方案是：將每一會話信息保存到一個數(shù)據(jù)庫中。由于這個方案會增加數(shù)據(jù)庫的負(fù)載，所以這個方案對性能的提高并不好。數(shù)據(jù)庫最好是用來存儲會話時間比較長的會話數(shù)據(jù)。為了避免數(shù)據(jù)庫出現(xiàn)單點故障，并且提高其擴展性，數(shù)據(jù)庫通常會復(fù)制到多臺服務(wù)器上，通過負(fù)載均衡器來分發(fā)請求到數(shù)據(jù)庫服務(wù)器上。

基于源/目的地址會話保持其實不太好用，因為客戶可能是通過DHCP，NAT或者Web代理來連接Internet的，其IP地址可能經(jīng)常變換，這使得這個方案的服務(wù)質(zhì)量無法保障。

NAT(Network Address Translation，網(wǎng)絡(luò)地址轉(zhuǎn)換):當(dāng)在專用網(wǎng)內(nèi)部的一些主機本來已經(jīng)分配到了本地IP地址(即僅在本專用網(wǎng)內(nèi)使用的專用地址)，但現(xiàn)在又想和因特網(wǎng)上的主機通信(并不需要加密)時，可使用NAT方法。這種方法需要在專用網(wǎng)連接到因特網(wǎng)的路由器上安裝NAT軟件。裝有NAT軟件的路由器叫做NAT路由器，它至少有一個有效的外部全球IP地址。這樣，所有使用本地地址的主機在和外界通信時，都要在NAT路由器上將其本地地址轉(zhuǎn)換成全球IP地址，才能和因特網(wǎng)連接。

網(wǎng)站標(biāo)題：什么是負(fù)載均衡，原理是什么？
文章地址：http://www.muchs.cn/news21/97671.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供App開發(fā)、商城網(wǎng)站、手機網(wǎng)站建設(shè)、響應(yīng)式網(wǎng)站、移動網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)