目錄

前言

一：負(fù)載均衡概述

二：為啥負(fù)載均衡服務(wù)器這么快呢？

?編輯

2.1 七層應(yīng)用程序慢的原因

2.2 四層負(fù)載均衡器LVS快的原因

三：LVS負(fù)載均衡器的三種模式

3.1 NAT模式

?3.1.1?什么是NAT模式

3.1.2 NAT模式實(shí)現(xiàn)LVS的缺點(diǎn)

3.1.3 NAT模式的注意事項(xiàng)

3.2 DR模式?

3.2.1 什么是MAC欺騙？

3.2.2 為什么Real Server需要處于同一個(gè)局域網(wǎng)內(nèi)？

3.2.3 如何實(shí)現(xiàn)VIP的對(duì)內(nèi)可見，對(duì)外隱藏

3.2.4 為什么DR模式要快

3.3 TUN隧道模式

3.3.1 實(shí)現(xiàn)原理

3.3.2 優(yōu)缺點(diǎn)

四：Real Server調(diào)度算法?

4.1 如何監(jiān)控每臺(tái)Real Server的負(fù)載情況？

4.2 客戶端長(zhǎng)連接

前言

? ? ?在互聯(lián)網(wǎng)發(fā)展早期，由于用戶量較少,業(yè)務(wù)需求也比較簡(jiǎn)單。對(duì)于軟件應(yīng)用，我們只需要一臺(tái)高配置的服務(wù)器，把業(yè)務(wù)所有模塊全單機(jī)部署，這樣的軟件架構(gòu)模式稱為單體架構(gòu)模式。

? ? ?隨著用戶量的增加，客戶端請(qǐng)求的并發(fā)量越來(lái)越大，在這個(gè)過(guò)程中單體架構(gòu)會(huì)產(chǎn)生兩個(gè)問(wèn)題。

1）單機(jī)的硬件資源是有限的，哪怕使用高配置服務(wù)器，其硬件資源仍然會(huì)稱為瓶頸，隨著客戶端請(qǐng)求并發(fā)量越來(lái)越大，但單機(jī)性能的上漲受限，進(jìn)而使得軟件的性能逐漸下降，訪問(wèn)延遲越來(lái)越高。

2）容易出現(xiàn)單點(diǎn)故障

? ? ? 為了解決上述的問(wèn)題，我們引入了將應(yīng)用進(jìn)行分布式集群化部署的架構(gòu)，分為兩種水平架構(gòu)部署和垂直架構(gòu)部署。

1）水平架構(gòu)部署：應(yīng)用程序分片集群化部署，例如Redis的分片集群。實(shí)現(xiàn)高性能和高拓展。

2）垂直架構(gòu)部署：為了解決單點(diǎn)故障問(wèn)題，一般會(huì)對(duì)應(yīng)用程序進(jìn)行主備/主從架構(gòu)，例如Redis的主從。

? ??

? ? ? 但是新的架構(gòu)設(shè)計(jì)有兩個(gè)問(wèn)題亟待解決：

?1）客戶端的請(qǐng)求如何均勻的分發(fā)到多臺(tái)目標(biāo)服務(wù)器上呢？

?2）如何檢測(cè)每臺(tái)目標(biāo)服務(wù)器的健康狀態(tài)，避免客戶端向已經(jīng)宕機(jī)的服務(wù)器發(fā)起請(qǐng)求導(dǎo)致請(qǐng)求失敗呢？如何支持目標(biāo)服務(wù)器進(jìn)行動(dòng)態(tài)的上下線呢？

一：負(fù)載均衡概述

? ? ?為了解決前言中提到的兩個(gè)問(wèn)題，于是引入了負(fù)載均衡技術(shù)的設(shè)計(jì)。簡(jiǎn)單來(lái)說(shuō)負(fù)載均衡的核心目的就是做分治，將客戶端的請(qǐng)求均勻的分發(fā)到多臺(tái)目標(biāo)服務(wù)器上，并支持目標(biāo)服務(wù)器動(dòng)態(tài)上下線的功能。?

? ? 由于進(jìn)行了分治處理，目標(biāo)服務(wù)器多臺(tái)的性能得到了釋放，因此能夠接受更大的客戶端請(qǐng)求并發(fā)，實(shí)現(xiàn)了高并發(fā)負(fù)載均衡的目標(biāo)。

? ? 那負(fù)載均衡的具體實(shí)現(xiàn)是什么呢？

? 首先實(shí)現(xiàn)負(fù)載均衡的可能方式有兩種:

1）客戶端層面做負(fù)載均衡。

2）把負(fù)載均衡功能解耦出來(lái)單獨(dú)部署成一個(gè)單獨(dú)的負(fù)載均衡服務(wù)器。

? ??首先第一種方案，在客戶端層面做負(fù)載均衡顯然是不可取的，因?yàn)槊恳慌_(tái)Real Server服務(wù)器都有一個(gè)提供服務(wù)的RIP,如果讓客戶端記錄所有的Real Server對(duì)應(yīng)的RIP顯然是非?；闹嚨?。

? ? 比如想象這樣一件事，百度的網(wǎng)頁(yè)放在了多臺(tái)Tomact目標(biāo)服務(wù)器上部署，比如今天突然百度新上線了一臺(tái)Tomcat服務(wù)器，難道要打電話給所有使用百度的用戶，告訴他們新的Tomact服務(wù)器的IP地址，讓后讓他們?nèi)ピL問(wèn)新的Tomcat服務(wù)器？這顯然是不對(duì)的。

? ? ?第二種方案顯然是可行的，其基礎(chǔ)設(shè)計(jì)圖如下:

? ? ? ?注意：在這種設(shè)計(jì)模型下，客戶端其實(shí)根本就不知道后端服務(wù)器集群是否使用了負(fù)載均衡，這對(duì)客戶端都是透明的，客戶端只要向后端服務(wù)器集群暴露的統(tǒng)一流量入口VIP發(fā)起請(qǐng)求就行了，其內(nèi)部是如何進(jìn)行請(qǐng)求分發(fā)的，對(duì)客戶端來(lái)根本就不重要。

? ? ?此時(shí)我們?cè)傧胍粋€(gè)問(wèn)題，Real Server為啥要集群化部署呢？還不是因?yàn)閱闻_(tái)Real Server扛不住很高的并發(fā)因此需要集群化部署。那么疑問(wèn)就來(lái)了，為啥單臺(tái)Real Server抗不住的并發(fā)，需要多臺(tái)Real Server才能抗住的并發(fā)，單臺(tái)負(fù)載均衡服務(wù)器就能抗??？

問(wèn)題：為啥負(fù)載均衡服務(wù)器這么快呢？

二：為啥負(fù)載均衡服務(wù)器這么快呢？

? ? ?負(fù)載均衡服務(wù)器的功能是將客戶端的請(qǐng)求均勻的分發(fā)給目標(biāo)服務(wù)器，其是否快的根本原因就是在于計(jì)算機(jī)接受請(qǐng)求數(shù)據(jù)包->處理請(qǐng)求數(shù)據(jù)包->發(fā)出響應(yīng)數(shù)據(jù)包的這個(gè)過(guò)程是否是足夠快。

2.1 七層應(yīng)用程序慢的原因

? ?

? ? ? 如上圖所示應(yīng)用程序服務(wù)器例如Tomcat等，是屬于應(yīng)用層的服務(wù)器，屬于OSI七層的服務(wù)器。

? 在應(yīng)用層的應(yīng)用程序進(jìn)程在跨主機(jī)跨進(jìn)程進(jìn)行通信的時(shí)候，首先需要在傳輸控制層通過(guò)三次握手建立長(zhǎng)連接，且請(qǐng)求數(shù)據(jù)包需要通過(guò)網(wǎng)絡(luò)IO到用戶空間的應(yīng)用程序進(jìn)程當(dāng)中，在進(jìn)行處理。這個(gè)過(guò)程涉及到以下幾個(gè)耗時(shí)的步驟：

? 1）內(nèi)核網(wǎng)絡(luò)協(xié)議棧接受數(shù)據(jù)包時(shí)涉及到的中斷，CPU拷貝。

? 2）用戶態(tài)的應(yīng)用程序進(jìn)程通過(guò)網(wǎng)絡(luò)IO去讀取Sockt緩沖區(qū)的數(shù)據(jù)時(shí)，涉及到 中斷，用戶態(tài)內(nèi)核態(tài)的切換，CPU拷貝

? 3）用戶態(tài)的應(yīng)用程序進(jìn)程處理數(shù)據(jù)包，進(jìn)行業(yè)務(wù)邏輯處理的耗時(shí)

? 4）用戶態(tài)的應(yīng)用程序進(jìn)程發(fā)出響應(yīng)數(shù)據(jù)包的時(shí)候，涉及到的一系列的中斷，上下文切換,CPU拷貝的代價(jià)。

上述原因就是應(yīng)用程序服務(wù)器慢的原因。

2.2 四層負(fù)載均衡器LVS快的原因

? ? 首先LVS在邏輯上到了四層但又沒(méi)有到四層，邏輯上到了四層是LVS只是看了一下請(qǐng)求報(bào)文中的目標(biāo)地址和端口。如果是LVS負(fù)載均衡服務(wù)器的IP地址和端口號(hào)就進(jìn)行負(fù)載，否則就不進(jìn)行處理。

? 之所以需要看請(qǐng)求報(bào)文中的目標(biāo)地址和端口號(hào)的本質(zhì)目的就是，一臺(tái)計(jì)算機(jī)上有很多端口號(hào)，但只有負(fù)載均衡器監(jiān)聽的端口號(hào)才需要進(jìn)行處理。

? 之所以說(shuō)LVS又沒(méi)到四層的原因是，LVS在傳輸控制層不需要進(jìn)行三次握手，只是看了一下端口號(hào)。

? ? LVS的性能快在是基于四層的且不需要建立連接。相較于七層應(yīng)用程序進(jìn)程來(lái)說(shuō)快太多了，可以看成LVS就是只做了數(shù)據(jù)包的轉(zhuǎn)發(fā)，不需要對(duì)數(shù)據(jù)包進(jìn)行修改，所以很快。

? ? ? ?但是一定要注意的是使用LVS負(fù)載均衡服務(wù)器的時(shí)候，Real Server必須是鏡像，也就是提供完全一樣的服務(wù)。

? ? 因?yàn)長(zhǎng)VS僅僅只是四層負(fù)載均衡服務(wù)器，其沒(méi)有涉及到應(yīng)用層，甚至都不知道應(yīng)用層使用的是HTTP還是FTP等。因此自然也不能根據(jù)HTTP請(qǐng)求的報(bào)文信息來(lái)決定把請(qǐng)求分發(fā)到哪個(gè)目標(biāo)服務(wù)器上。所以Real Server必須是鏡像的。

? ? ?但基于七層負(fù)載的Nginx，因?yàn)槠涫腔趹?yīng)用層的負(fù)載均衡，可以根據(jù)HTTP請(qǐng)求的報(bào)文信息來(lái)決定把請(qǐng)求分發(fā)到哪個(gè)目標(biāo)服務(wù)器上，比如Cookie，消息體，RequestHeader等。因此Nginx的目標(biāo)服務(wù)器可以是提供不一樣的服務(wù)的，Nginx可以根據(jù)HTTP請(qǐng)求報(bào)文的信息來(lái)進(jìn)行負(fù)載。

三：LVS負(fù)載均衡器的三種模式

? ? 我們已經(jīng)講了為什么要有負(fù)載均衡，也講了負(fù)載均衡的作用以及四層負(fù)載均衡LVS為什么快，現(xiàn)在開始思考LVS如何實(shí)現(xiàn)呢？

3.1 NAT模式

NAT模式實(shí)現(xiàn)LVS圖示

?3.1.1?什么是NAT模式

? ?所謂NAT模式，其實(shí)是(Network Adress Transfer) 網(wǎng)絡(luò)地址轉(zhuǎn)換協(xié)議的縮寫。其原理用一句話說(shuō)就是在數(shù)據(jù)報(bào)文即將發(fā)出去之前對(duì)數(shù)據(jù)報(bào)文的IP地址和端口號(hào)進(jìn)行修改。

3.1.2 NAT模式實(shí)現(xiàn)LVS的缺點(diǎn)

1. NAT網(wǎng)絡(luò)地址轉(zhuǎn)換協(xié)議是網(wǎng)絡(luò)層處理的，性能比數(shù)據(jù)鏈路層MAC欺騙要慢。

2. LVS負(fù)載均衡服務(wù)器是后端服務(wù)器高并發(fā)流量的入口，頻繁的進(jìn)行NAT網(wǎng)絡(luò)地址轉(zhuǎn)換會(huì)消耗CPU的性能，并且還需要消耗內(nèi)存空間存放地址映射關(guān)系。

3. 無(wú)論是客戶端發(fā)給服務(wù)器的請(qǐng)求，還是服務(wù)器給客戶端的響應(yīng)都需要經(jīng)過(guò)LVS，會(huì)對(duì)LVS造成過(guò)大的壓力,大大消耗LVS的網(wǎng)絡(luò)帶寬；而且請(qǐng)求的數(shù)據(jù)包和響應(yīng)的數(shù)據(jù)包的大小是不對(duì)稱的，因此會(huì)使得LVS的吞吐量進(jìn)一步下降。

? ? ?這里著重講一下上述第三點(diǎn)的原理

? ? ? 首先負(fù)載均衡機(jī)制的核心目的是讓客戶端的請(qǐng)求合理均分地分發(fā)給多臺(tái)目標(biāo)服務(wù)器上。其本質(zhì)地目的是用多臺(tái)目標(biāo)服務(wù)器均攤客戶端請(qǐng)求流量，以便能夠承載更大地并發(fā)。那么目標(biāo)服務(wù)器地響應(yīng)應(yīng)該由目標(biāo)服務(wù)器直接返回給對(duì)應(yīng)的客戶端即可。這樣LVS只需要承擔(dān)客戶端請(qǐng)求的網(wǎng)絡(luò)帶寬，而目標(biāo)服務(wù)器響應(yīng)的網(wǎng)絡(luò)帶寬由多臺(tái)目標(biāo)服務(wù)器共同承擔(dān)，自然LVS的吞吐量就上升了。

? ? ? ?請(qǐng)求和響應(yīng)數(shù)據(jù)包大小不對(duì)稱很常見，比如我們打開網(wǎng)頁(yè)請(qǐng)求百度的主頁(yè)。在這個(gè)情景下，請(qǐng)求數(shù)據(jù)包很小，但是響應(yīng)數(shù)據(jù)包確實(shí)整個(gè)頁(yè)面的文字和圖片，響應(yīng)數(shù)據(jù)包比請(qǐng)求數(shù)據(jù)包大很多，而請(qǐng)求和響應(yīng)數(shù)據(jù)包都經(jīng)過(guò)LVS，這種不對(duì)稱，會(huì)進(jìn)一步降低LVS的吞吐量。

3.1.3 NAT模式的注意事項(xiàng)

? ?在使用NAT的模式的時(shí)候要注意，Real Server的默認(rèn)網(wǎng)關(guān)要設(shè)置為L(zhǎng)VS負(fù)載均衡服務(wù)器。否則NAT模式會(huì)失效。

? ? ? ?看看3.1的圖例Real Server處理完客戶端的數(shù)據(jù)包后，會(huì)封裝(RIP->CIP)的響應(yīng)數(shù)據(jù)包，如果默認(rèn)網(wǎng)關(guān)不配置成LVS負(fù)載均衡服務(wù)器，這個(gè)響應(yīng)數(shù)據(jù)包很可能不經(jīng)過(guò)LVS負(fù)載均衡器將數(shù)據(jù)包轉(zhuǎn)換為(VIP->CIP),就直接返回給客戶端。但客戶端發(fā)出的請(qǐng)求數(shù)據(jù)包確是(CIP->VIP)，因此(RIP->CIP)的數(shù)據(jù)包會(huì)被直接丟棄。

? ? ? ?Real Server響應(yīng)數(shù)據(jù)包在NAT模式下必須要經(jīng)過(guò)LVS服務(wù)器做S-NAT之后，由LVS負(fù)載均衡器將數(shù)據(jù)包返回給客戶端，

3.2 DR模式?

? ? ?DR模式的提出本質(zhì)上是為了解決NAT模式存在的問(wèn)題，其思想是既然NAT的模式目標(biāo)服務(wù)器的響應(yīng)需要經(jīng)過(guò)LVS負(fù)載均衡服務(wù)器導(dǎo)致其吞吐量下降，那DR模式下目標(biāo)服務(wù)器的響應(yīng)就直接返回給客戶端達(dá)到減輕LVS壓力的目的，從而提高LVS的吞吐量。

? ?為了實(shí)現(xiàn)DR模式，涉及到的重要技術(shù)就是 MAC欺騙 和 VIP對(duì)內(nèi)可見對(duì)外隱藏。

DR模式重要的幾個(gè)特點(diǎn)：?

1.? LVS負(fù)載均衡服務(wù)器做基于數(shù)據(jù)鏈路層的MAC欺騙。

2.? 每臺(tái)Real Server都具有VIP，但是對(duì)內(nèi)可見，對(duì)外隱藏。

3.? 同一臺(tái)LVS負(fù)載均衡服務(wù)器所負(fù)載的多臺(tái)Real Server需處于和LVS負(fù)載均衡服務(wù)器在同一個(gè)局域網(wǎng)內(nèi)。

4.? Real Server的響應(yīng)不經(jīng)過(guò)LVS負(fù)載均衡服務(wù)器，會(huì)直接返回給客戶端。

3.2.1 什么是MAC欺騙？

? ? 如上圖所示LVS服務(wù)器接收到（CIP->VIP）的數(shù)據(jù)包之后，其并沒(méi)有做D-NAT轉(zhuǎn)換，修改其IP到某一臺(tái)RIP。而是通過(guò)Real Server調(diào)度算法，選擇一臺(tái)目標(biāo)服務(wù)器，根據(jù)其RIP通過(guò)arp協(xié)議獲取到RIP對(duì)應(yīng)的MAC地址，封裝到當(dāng)前數(shù)據(jù)包的MAC頭上。

? ? ?客戶端請(qǐng)求的目標(biāo)地址就是VIP，就是LVS負(fù)載均衡服務(wù)器本身，本應(yīng)當(dāng)接收包，但是卻通過(guò)修改MAC地址到另一臺(tái)Real Server的MAC地址而將數(shù)據(jù)包轉(zhuǎn)發(fā)出去的過(guò)程稱為MAC欺騙。

重點(diǎn)：MAC欺騙是基于二層數(shù)據(jù)鏈路層的技術(shù)，其速度要比基于四層的NAT技術(shù)要快。

3.2.2 為什么Real Server需要處于同一個(gè)局域網(wǎng)內(nèi)？

? ? ? 在進(jìn)行LVS部署的時(shí)候，需要注意同一臺(tái)LVS負(fù)載均衡服務(wù)器所負(fù)載的多臺(tái)Real Server需處于同一個(gè)局域網(wǎng)內(nèi)。

? 其原因是LVS負(fù)載均衡服務(wù)器在進(jìn)行MAC欺騙時(shí)，會(huì)通過(guò)Real Server調(diào)度策略選擇一臺(tái)Real Server的RIP，然后通過(guò)arp協(xié)議獲取此RIP對(duì)應(yīng)的MAC地址。

? ?這里要注意arp協(xié)議是局域網(wǎng)內(nèi)部的基于交換機(jī)的廣播協(xié)議，所以自然要求多臺(tái)Real Server和LVS負(fù)載均衡服務(wù)器在同一個(gè)局域網(wǎng)內(nèi)部。

3.2.3 如何實(shí)現(xiàn)VIP的對(duì)內(nèi)可見，對(duì)外隱藏

? ? ?因?yàn)樾枰_(dá)到目標(biāo)服務(wù)器直接向客戶端返回響應(yīng)的目的，所以目標(biāo)服務(wù)器返回的數(shù)據(jù)包應(yīng)該是 （VIP->CIP），也就是說(shuō)目標(biāo)服務(wù)器Real Server 需要具備VIP的網(wǎng)絡(luò)接口。

? ? ? 但是互聯(lián)網(wǎng)中自然不能出現(xiàn)多個(gè)相同的VIP地址，所以只有負(fù)載均衡器LVS，能夠?qū)IP暴露到公網(wǎng)中，而每一個(gè)Real Server都應(yīng)該知道自己有VIP，但不能將VIP暴露出去。

那么如何實(shí)現(xiàn)VIP的對(duì)內(nèi)可見，對(duì)外隱藏呢？

? ? ? 修改Linux內(nèi)核參數(shù)

目錄 /proc/sys/net/ipv4/conf/*interface*/

arp_ignore:定義網(wǎng)卡接收到ARP請(qǐng)求時(shí)的響應(yīng)級(jí)別:

? ? ?0: 只要本地的所有網(wǎng)絡(luò)接口配置了相應(yīng)的地址，就給予響應(yīng)，返回相應(yīng)地址所對(duì)應(yīng)的網(wǎng)卡的MAC地址。

? ? ?1：僅在請(qǐng)求的目標(biāo)網(wǎng)絡(luò)接口上查找ARP請(qǐng)求相應(yīng)的地址，如果有就返回此網(wǎng)卡的MAC地址。

arp_announce: 定義網(wǎng)絡(luò)接口連接互聯(lián)網(wǎng)時(shí)向外通告時(shí)的通告級(jí)別

? ? ?0：將本地所有網(wǎng)絡(luò)接口上的任何地址向外通告；

? ? ?1：試圖僅向目標(biāo)網(wǎng)絡(luò)通告與其網(wǎng)絡(luò)匹配的地址；

? ? ?2：僅將連接互聯(lián)網(wǎng)的網(wǎng)卡上配置的所有地址進(jìn)行通告

需要進(jìn)行配置 arp_ignore=1 arp_announce=2

arp_ignore=1 的含義是 網(wǎng)絡(luò)接口接收ARP請(qǐng)求后，不將其它網(wǎng)絡(luò)接口的地址暴露出去。

arp_annouce=2 的含義是 當(dāng)前網(wǎng)絡(luò)接口連接互聯(lián)網(wǎng)后，不會(huì)將其它網(wǎng)絡(luò)接口的地址通告出去。

注意一臺(tái)計(jì)算機(jī)可能有多個(gè)interface，只需配置 RIP所在的interface即可。

同時(shí)還要注意需要在Real Server里創(chuàng)建Loopback網(wǎng)卡的網(wǎng)絡(luò)接口做為VIP，也就是VIP要配置到Loopback網(wǎng)卡上。

其根本原因是Looback網(wǎng)卡是內(nèi)核應(yīng)用程序模擬的網(wǎng)卡，不是物理網(wǎng)卡，不會(huì)連接互聯(lián)網(wǎng)主動(dòng)通告，也不會(huì)接收ARP請(qǐng)求。

3.2.4 為什么DR模式要快

? ? ?上面講過(guò)NAT模式，這里討論DR模式為什么要比NAT模式快，其原因主要有以下幾點(diǎn)：

1. DR模式是基于二層數(shù)據(jù)鏈路層的MAC欺騙，而NAT模式是基于四層的網(wǎng)絡(luò)地址轉(zhuǎn)換協(xié)議，因此DR模式比NAT模式更快，更節(jié)省CPU資源。

2. DR模式下目標(biāo)服務(wù)器的響應(yīng)不會(huì)經(jīng)過(guò)LVS負(fù)載均衡服務(wù)器，大大減輕了LVS負(fù)載均衡服務(wù)器的網(wǎng)絡(luò)帶寬壓力，節(jié)約了網(wǎng)卡資源，提升了吞吐量。、

3.3 TUN隧道模式

? ? ?每一種新技術(shù)的誕生，很多時(shí)候都是為了解決舊技術(shù)存在的痛點(diǎn)。學(xué)習(xí)新技術(shù)時(shí)，先了解技術(shù)的發(fā)展歷史，理解舊技術(shù)的痛點(diǎn)在哪，學(xué)習(xí)新技術(shù)就能游刃有余。

? ? ? ? DR模式的痛點(diǎn)：

? ? ? ? DR模式雖然相較于NAT模式性能有較大的提升，但是其限制LVS服務(wù)器需要和所有的Real Server在同一個(gè)局域網(wǎng)中。無(wú)法突破地域的限制。

? ? ? ?TUN隧道模式目的就是突破地域的限制，使得LVS服務(wù)器和所有的Real Server可以部署在不同的局域網(wǎng)中。

設(shè)計(jì)圖：

3.3.1 實(shí)現(xiàn)原理

? ? ?如上圖可以知道在TUN隧道模式下，LVS負(fù)載均衡服務(wù)器在轉(zhuǎn)發(fā)數(shù)據(jù)包前通告Real Server調(diào)度算法選擇一臺(tái)Real Server，且在目標(biāo)數(shù)據(jù)包外層再封裝一個(gè)（VIP->RIP）的數(shù)據(jù)包。這種情況可以理解為"數(shù)據(jù)包背著數(shù)據(jù)包"。

? ? ?在這種情況下外層數(shù)據(jù)包是由(VIP->RIP),因此不需要做基于二層數(shù)據(jù)鏈路層的MAC欺騙，直接將數(shù)據(jù)包轉(zhuǎn)發(fā)給Real Server，因此LVS服務(wù)器和Real Server自然不需要在同一個(gè)局域網(wǎng)內(nèi)部署。

3.3.2 優(yōu)缺點(diǎn)

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

? ? 相較于DR模式，突破了地域的限制，LVS服務(wù)器可以和Real Server部署在不同的局域網(wǎng)中，提高了部署的靈活性。

缺點(diǎn)：

? ? TUN隧道模式的性能肯定是比NAT模式要高的，但其性能比DR模式要慢。因?yàn)檫@種"數(shù)據(jù)包背著數(shù)據(jù)包"，使得數(shù)據(jù)包更大，在高并發(fā)的場(chǎng)景下其會(huì)消耗更多的網(wǎng)絡(luò)帶寬，網(wǎng)卡資源會(huì)成為其性能瓶頸。

四：Real Server調(diào)度算法?

? ???

LVS（Linux Virtual Server）主要有以下幾種實(shí)現(xiàn)調(diào)度算法：

靜態(tài)調(diào)度算法：只基于算法本身進(jìn)行調(diào)度

1. 輪詢調(diào)度算法（Round Robin）

2. 加權(quán)輪詢調(diào)度算法（Weighted Round Robin）

3. 源地址哈希算法 sh

4. 目標(biāo)地址哈希算法 dh

動(dòng)態(tài)調(diào)度算法：根據(jù)各個(gè)Real Server的負(fù)載情況和算法來(lái)進(jìn)行調(diào)度。優(yōu)先調(diào)度負(fù)載程度最輕的Real Server

1. 最少連接數(shù)調(diào)度算法（Least Connection）

2. 加權(quán)最少連接數(shù)調(diào)度算法（Weighted Least Connection）

3. 最短期望延遲算法(Shortest Expected Delay Scheduling) sed

4. 最少隊(duì)列算法(Never Queue Scheduling) nq

5. 基于局部的最少連接算法：

6. 帶復(fù)制的基于局部的最少連接算法(Locality-Based Least Connections with Replication) lblcr

7. FO算法(Weighted Fail Over) fo

8. OVF算法(Overflow-connection) ovf

? ? 每種調(diào)度算法的詳情可見：LVS的12種Real Server調(diào)度算法

4.1 如何監(jiān)控每臺(tái)Real Server的負(fù)載情況？

? ? 在使用動(dòng)態(tài)調(diào)度算法的時(shí)候，需要監(jiān)控各個(gè)Real Server的負(fù)載情況，比如連接數(shù)指標(biāo)，那么LVS負(fù)載均衡器是如何知道每臺(tái)Real Server上建立了多少長(zhǎng)連接呢？

? ?其實(shí)很簡(jiǎn)單，客戶端的握手報(bào)文會(huì)發(fā)送給LVS負(fù)載均衡器，因此LVS負(fù)載均衡器自然知道哪個(gè)客戶端想要與哪臺(tái)Real Server握手，LVS服務(wù)器監(jiān)聽到客戶端發(fā)來(lái)的ACK包，就知道連接建立成功，于是連接數(shù)+1統(tǒng)計(jì)就可以。

注意：在DR模式和TUN隧道模式下，Real Server的響應(yīng)數(shù)據(jù)包會(huì)直接發(fā)回給客戶端，不會(huì)經(jīng)過(guò)LVS服務(wù)器，因此三次握手的全過(guò)程并不能完全監(jiān)控到，四次握手也是如此。

4.2 客戶端長(zhǎng)連接

? ? ?首先一定要明白的一點(diǎn)是LVS負(fù)載均衡服務(wù)器不會(huì)與客戶端建立連接，也不會(huì)與Real Server建立連接，真正建立連接的是客戶端與目標(biāo)服務(wù)器。

? ??思考一個(gè)問(wèn)題：客戶端每發(fā)送的數(shù)據(jù)包都會(huì)經(jīng)過(guò)Real Server調(diào)度算法進(jìn)行負(fù)載均衡均分到多臺(tái)Real Server嗎？

? ? 回答：在使用長(zhǎng)連接時(shí)，LVS負(fù)載均衡服務(wù)器只會(huì)把客戶端的長(zhǎng)連接通過(guò)Real Server調(diào)度算法均攤到Real Server，讓每臺(tái)Real Server都分?jǐn)偟揭欢康目蛻舳碎L(zhǎng)連接。但連接建立后，客戶端所有數(shù)據(jù)報(bào)文雖然也會(huì)發(fā)送給LVS服務(wù)器，但是此時(shí)LVS服務(wù)器如果判斷當(dāng)前客戶端與Real Server已經(jīng)建立過(guò)長(zhǎng)連接，就會(huì)直接轉(zhuǎn)發(fā)請(qǐng)求到目標(biāo)Real Server，不會(huì)再進(jìn)行Real Server負(fù)載均衡調(diào)度。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-637151.html

到了這里，關(guān)于高并發(fā)負(fù)載均衡---LVS的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！