本文已收錄至 Github（MD-Notes），若博客中圖片模糊或打不開，可以來我的 Github 倉庫，包含了完整圖文：https://github.com/HanquanHq/MD-Notes，涵蓋了互聯(lián)網(wǎng)大廠面試必問的知識點，講解透徹，長期更新中，歡迎一起學(xué)習(xí)探討 ~

更多內(nèi)容，可以訪問：

面試必會系列專欄：https://blog.csdn.net/sinat_42483341/category_10300357.html
操作系統(tǒng)系列專欄：https://blog.csdn.net/sinat_42483341/category_10519484.html

---

目錄

• LVS 負載均衡
• • • 網(wǎng)絡(luò)協(xié)議原理
    • • 引入
      • 七層模型
      • TCP / IP（詳見5.2節(jié)）
      • 路由表
      • 下一跳機制
      • 路由器、交換機
      • ARP 協(xié)議
      • • ARP 請求
        • ARP 響應(yīng)
        • 案例
      • 網(wǎng)絡(luò)包傳輸?shù)倪^程
      • 負載均衡 & LVS 的引入
      • NAT 網(wǎng)路地址轉(zhuǎn)換
      • • （1）S-NAT 模式：源地址替換協(xié)議
        • （2）D-NAT 模式：目標地址轉(zhuǎn)換協(xié)議（基于3層網(wǎng)絡(luò)層）
        • （3）DR 模型：直接路由模型（基于2層鏈路層）
        • （4）隧道模式
      • LVS
      • 隱藏的Virtual IP 配置原理
      • 負載均衡調(diào)度方法
      • LVS在Linux中自帶的ipvs內(nèi)核模塊
      • LVS 實驗手冊
      • 學(xué)習(xí) keepalived 之前，關(guān)于高可用，你需要知道：
      • keepalived
      • keepalived 實驗手冊

LVS 負載均衡

網(wǎng)絡(luò)協(xié)議原理

引入

中國網(wǎng)絡(luò)上可以產(chǎn)生消費的活躍用戶約2.4億，互聯(lián)網(wǎng)人數(shù)較多，基礎(chǔ)人群大。企業(yè)應(yīng)該把錢花在哪里？營銷上，而不是技術(shù)上。這樣你賺得更多。案例比如，陌陌：CCTV廣告，營銷讓人們下載去使用這個軟件，你可以去百度買關(guān)鍵字排名，你可以去找微博大V，等等。假設(shè)你的營銷手段能讓20%人看到，有2%的人點擊下載，大約1000萬人。這時候你的“首屏廣告”已經(jīng)賺了好多了。再如果有的用戶愿意付費，…，于是，在這個時代，高并發(fā)已經(jīng)是每一家企業(yè)都要面臨的。

假設(shè)高并發(fā)被解決了，在web容器的日志里你要記錄些什么？分析渠道的流量的質(zhì)量，分析不同的渠道給我?guī)矶嗌俚脑L問量。每個渠道的轉(zhuǎn)化率，購買力。這樣就可以知道下一輪投資應(yīng)該在什么渠道多投廣告。中國在從制造向服務(wù)行業(yè)轉(zhuǎn)型（service）。

七層模型

軟件“工程”學(xué)：有分層、解耦的概念，因此我們有七層模型。

TCP / IP（詳見5.2節(jié)）

TCP 是面向連接的，可靠的傳輸協(xié)議，是有確認的。三次握手->數(shù)據(jù)傳輸->四次分手，這個過程稱為一個最小粒度，不可被分割。service mesh 號稱微服務(wù)的下一代，你要懂點網(wǎng)絡(luò)，學(xué)service mesh就好懂了。

子網(wǎng)掩碼：將 IP 地址與子網(wǎng)掩碼做按位與運算，得到網(wǎng)絡(luò)號。

路由表

route -n 查看路由表，路由表是動態(tài)生成的。

192.168.150.2 是網(wǎng)關(guān)，能夠和任何目標地址匹配上。指示了你發(fā)送的數(shù)據(jù)包想要出這個局域網(wǎng)，就需要走 192.168.150.2 ，同一局域網(wǎng)的兩個端點想要通信，不需要走下一跳，可以直接通信。只有在不同局域網(wǎng)之間的通信，才需要下一跳機制。

下一跳機制

基于下一跳機制：每一個互聯(lián)網(wǎng)的設(shè)備，內(nèi)存中不需要存儲全網(wǎng)的數(shù)據(jù)，只需要存儲它周邊一個網(wǎng)絡(luò)當中的數(shù)據(jù)。有人做過一個實驗，從美國向外發(fā)送所有的數(shù)據(jù)包，另一端都能夠按照正確的順序拼接。這個實驗證明了基于下一跳的TCP傳輸方式是可以保證可靠傳輸?shù)?#xff01;

路由判定：通過按位與找到下一跳

鏈路層：在網(wǎng)絡(luò)層的基礎(chǔ)上，又封裝了一層。在發(fā)送方發(fā)出的網(wǎng)絡(luò)包去尋找接收方的整個過程中，ip地址和port不會發(fā)生變化，變化的是隨著每一次發(fā)到下一跳的時候的mac地址的改變。
arp -a，查看同一局域網(wǎng)內(nèi)，ip地址和硬件地址的映射

TCP/IP 協(xié)議是基于 下一跳 的機制：在不同跳之間，MAC地址會發(fā)生變化，改成下一跳的MAC地址。而IP地址/端口號不會發(fā)生變化。

• IP 地址的最終目標是 端點 間的
• MAC 地址的目標是是 節(jié)點 間的

路由器、交換機

路由器就是要連接不同的網(wǎng)段，它是用來選擇路線的。它里面有路由表，可以進行路由轉(zhuǎn)發(fā)的判定。

交換機是負責同一個網(wǎng)絡(luò)中轉(zhuǎn)發(fā)，他只要轉(zhuǎn)發(fā)就行了。

ARP 協(xié)議

發(fā)送端必須獲取到目的MAC地址，MAC地址通過ARP協(xié)議來獲取。
arp -a本質(zhì)就是一個IP地址->MAC地址的對應(yīng)表，表中每一個條目分別記錄了網(wǎng)絡(luò)上其他主機的IP地址和對應(yīng)的MAC地址。
ARP表在初始的時候是空的。

ARP 請求

主機A的ARP緩存表中不存在主機C的MAC地址，所以主機A會發(fā)送ARP Request來獲取目的MAC。主機A不知道主機C的MAC地址，所以目的MAC地址為廣播地址FF-FF-FF-FF-FF-FF。交換機收到這個特殊的包之后會廣播出去，ARP request報文會在整個網(wǎng)絡(luò)上傳播，該網(wǎng)絡(luò)中所有主機包括網(wǎng)關(guān)都會接受到此ARP request 報文。網(wǎng)關(guān)會阻止該報文發(fā)送到其他網(wǎng)絡(luò)上。

ARP 響應(yīng)

所有主機接收到該ARP request報文后，會檢查它的目的協(xié)議地址（一般是00-00-00-00-00-00-00與所有的匹配）字段與自身的IP地址是否匹配。如果不匹配，則該主機將不會響應(yīng)該ARP request報文。如果匹配，則該主機會將ARP報文中的源MAC地址和源IP地址信息記錄到自己的ARP緩存表中，然后通過ARP Reply報文進行響應(yīng)。

另外，交換機具有記憶，下一次再遇到相同的目標地址時，就不需要廣播了，直接發(fā)送到目標端口。現(xiàn)在通常情況下，計算機聯(lián)網(wǎng)后會主動向外通告自己的mac地址，減少了主動通過ARP拉取的過程。

案例

假如我有另一臺主機B，主機B的IP地址是192.168.150.3，我主機B上添加了一個虛擬網(wǎng)卡192.168.88.88之后，想要在當前這主機A上ping通這個新添加的網(wǎng)卡地址，需要手動配一下路由表條目，否則這個ping會被發(fā)送到網(wǎng)關(guān)192.168.150.2上，導(dǎo)致ping不通。

網(wǎng)絡(luò)包傳輸?shù)倪^程

看下圖，一個網(wǎng)絡(luò)包在發(fā)送的過程中，每經(jīng)過一跳，它的目標mac地址、源mac地址都要通過路由器發(fā)生改變，而源IP、目標IP始終是不變的。

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-AZ1p31gu-1611411055618)(…/images/20200703120617399.png)]

負載均衡 & LVS 的引入

同一網(wǎng)絡(luò)當中IP地址不能重復(fù)出現(xiàn)，否則會沖突，不知道應(yīng)該發(fā)給誰。那怎么使用多個服務(wù)器實現(xiàn)多并發(fā)呢？

為什么Tomcat承受的并發(fā)少？因為Tomcat是在協(xié)議的第7層，也就是應(yīng)用層的軟件，是整個網(wǎng)絡(luò)通信過程中最末端的層次。況且Tomcat是Java開發(fā)的，它跑在JVM上，又要進行用戶態(tài)內(nèi)核態(tài)的切換，這樣就更慢了。（Nginx也是在7層應(yīng)用層，所以Nginx的帶寬是有上限的，官方壓測單機并發(fā)5萬。但是LVS是在4層的，可以承受更大的并發(fā)；socket可以看做是在第4層的，是一個規(guī)范的接口）

路由器只是三層的設(shè)備，只需要做轉(zhuǎn)發(fā)。

現(xiàn)在我們從通信的角度考慮，如果有一個負載均衡服務(wù)器設(shè)備，可以根本不需要和客戶端握手，收到數(shù)據(jù)包就直接轉(zhuǎn)發(fā)出去，是數(shù)據(jù)包級別的轉(zhuǎn)發(fā)。這樣能夠提高性能，但看不到數(shù)據(jù)包的內(nèi)容（uri 等），所以要求后臺的客戶端是鏡像的，一模一樣的。這就是一種 數(shù)據(jù)包級別的四層負載均衡技術(shù)。

我們得到下面這樣的拓撲模型，可以解決負載均衡的問題。

首先，我們統(tǒng)一下命名：
CIP：客戶端client IP地址
VIP：負載均衡服務(wù)器的虛擬virtual IP
DIP：用于分發(fā)的dispacher IP
RIP：真實的服務(wù)器的real IP

NAT 網(wǎng)路地址轉(zhuǎn)換

網(wǎng)路地址轉(zhuǎn)換一般出現(xiàn)在路由器上
首先我們要知道，私有地址不會出現(xiàn)在互聯(lián)網(wǎng)上

（1）S-NAT 模式：源地址替換協(xié)議

假設(shè)你和你女朋友在家都要訪問百度，你的IP:port是192.168.1.8:12121，你女朋友IP:port是192.168.1.6:12121，如果不進行地址轉(zhuǎn)換的話，你們倆的地址發(fā)到百度8.8.8.8:80之后，百度看到的都是6.6.6.6:12121，這時候百度服務(wù)器就懵了，不知道這倆有什么區(qū)別。那怎么解決這個問題呢？
使用NAT網(wǎng)絡(luò)地址轉(zhuǎn)換，路由器自己維護一張轉(zhuǎn)換表，把你倆的192.168.1.8:12121和192.168.1.6:12121分別轉(zhuǎn)換成6.6.6.6:123和6.6.6.6:321，用不同的端口發(fā)送給百度。等收到返回的數(shù)據(jù)包后，再按照自己記錄的轉(zhuǎn)換表，把網(wǎng)絡(luò)包發(fā)送回給你和你女朋友。你家、你單位、你的虛擬機都是選的NAT這種模式。

（2）D-NAT 模式：目標地址轉(zhuǎn)換協(xié)議（基于3層網(wǎng)絡(luò)層）

可以用下圖這種方式實現(xiàn)負載均衡：客戶端發(fā)來的請求到負載均衡服務(wù)器，負載均衡服務(wù)器將請求分發(fā)到后面的server上，server將響應(yīng)返回給負載均衡服務(wù)器，注意這之間需要多次源IP與目標IP的替換。

弊端：

• 它在通信的時候是非對稱的，負載均衡服務(wù)器的帶寬成為瓶頸：客戶端給服務(wù)端發(fā)送的請求數(shù)據(jù)量是很小的，但是服務(wù)端給客戶端返回的數(shù)據(jù)量很大。于是，下行的數(shù)據(jù)使服務(wù)器帶寬成為瓶頸。早期的 ADSL 電話線理論上可以達到 6M 的全速單一方向帶寬，分為上行和下行，如果平分的話，上下行都是3M。所以運營商做了手腳進行了調(diào)整，將下行的帶寬調(diào)的很大，將上傳的帶寬調(diào)的比較小。
• 地址轉(zhuǎn)換消耗算力
  

怎么解決上述弊端？如果能夠讓 real server 返回的數(shù)據(jù)不經(jīng)過負載均衡服務(wù)器，而是直接返回給客戶端就好了。

（3）DR 模型：直接路由模型（基于2層鏈路層）

DR 模型，替換的是MAC地址而不是IP地址，也就是我們所說的“MAC地址欺騙”

于是我們想啊，如果有這么一種技術(shù)：每一個server都能夠配一個VIP，但由于IP不能重復(fù)，這個VIP對外隱藏，只對內(nèi)可見（其實是對ARP協(xié)議進行手術(shù)）。兩臺server共同在負載均衡服務(wù)器上對外暴露同一個VIP，別人請求只能請求到這臺負載均衡服務(wù)器上來，這樣就能從server直接向客戶端返回數(shù)據(jù)包，而不需要走負載均衡服務(wù)器了。

負載均衡服務(wù)器在轉(zhuǎn)發(fā)數(shù)據(jù)包的時候，將封裝的目標 mac 地址修改為 real server 的 mac 地址。mac 地址是點到點的，代表的是一跳的距離，要保證負載均衡服務(wù)器與你的 server 在同一個網(wǎng)絡(luò)中，不能下一跳跳到別的網(wǎng)絡(luò)去。這種修改 mac 地址的模式是基于2層鏈路層的，沒有修改3層網(wǎng)絡(luò)層。

缺點：是不能跨網(wǎng)絡(luò)，負載均衡服務(wù)器和真實服務(wù)器 RS（real server）要在同一個局域網(wǎng)。這是一個約束。
優(yōu)勢：速度快，成本低

（4）隧道模式

假設(shè)我們有好多好多的RS（real server），現(xiàn)在這些RS和負載均衡服務(wù)器不在同一個機房了。怎么解決這個問題？使用隧道技術(shù)。啥是隧道技術(shù)？

在CIP->VIP外面包裹一層DIP->RIP地址，這樣數(shù)據(jù)包就可以順利的從負載均衡服務(wù)器被發(fā)送到 server1
server1收到這個數(shù)據(jù)包之后，把外層的DIP->RIP撕掉，就能看到真正的CIP->VIP，自己處理之后，根據(jù)CIP->VIP直接返回給客戶端。

我們以往用到的PPPOE這種協(xié)議就是這種技術(shù)。我們所說的 VPN，翻墻，用到的也是這種技術(shù)。

LVS

LVS是Linux Virtual Server的簡寫，意即Linux虛擬服務(wù)器，是一個虛擬的服務(wù)器集群系統(tǒng)。

我們定義一些名詞縮寫：

早期的小型運營商使用的 LVS：

隱藏的Virtual IP 配置原理

隱藏VIP方法：對外隱藏，對內(nèi)可見 ：
kernel parameter:
目標mac地址為全F，交換機觸發(fā)廣播
/proc/sys/net/ipv4/conf/*IF*/
arp_ignore: 定義接收到ARP請求時的響應(yīng)級別；
0：只要本地配置的有相應(yīng)地址，就給予響應(yīng)；
1：僅在請求的目標(MAC)地址配置請求到達的接口上的時候，才給予響應(yīng)；

arp_announce：定義將自己地址向外通告時的通告級別；
0：將本地任何接口上的任何地址向外通告；
1：試圖僅向目標網(wǎng)絡(luò)通告與其網(wǎng)絡(luò)匹配的地址；
2：僅向與本地接口上地址匹配的網(wǎng)絡(luò)進行通告；

將VIP配置在環(huán)回接口lo上

負載均衡調(diào)度方法

四種靜態(tài)調(diào)度方法：
rr: 輪叫調(diào)度（Round-Robin Scheduling）
wrr:加權(quán)輪叫調(diào)度（Weighted Round-Robin Scheduling）
dh: 目標地址散列調(diào)度（Destination Hashing Scheduling）
sh:源地址散列調(diào)度（Source Hashing Scheduling）

動態(tài)調(diào)度方法：
lc: 最小連接調(diào)度（Least-Connection Scheduling）
wlc: 加權(quán)最小連接調(diào)度（Weighted Least-Connection Scheduling）
sed: 最短期望延遲
nq: never queue
LBLC: 基于局部性的最少鏈接（Locality-Based Least Connections Scheduling）
DH:
LBLCR:帶復(fù)制的基于局部性最少鏈接（Locality-Based Least Connections with Replication Scheduling）

LVS在Linux中自帶的ipvs內(nèi)核模塊

ipvs內(nèi)核模塊
yum install ipvsadm -y

管理集群服務(wù)

添加：-A -t|u|f service-address [-s scheduler] -t: TCP協(xié)議的集群 -u: UDP協(xié)議的集群 service-address: IP:PORT -f: FWM: 防火墻標記 service-address: Mark Number 修改：-E 刪除：-D -t|u|f service-address 12345678

例如，ipvsadm -A -t 192.168.9.100:80 -s rr

管理集群服務(wù)中的RS

添加：-a -t|u|f service-address -r server-address [-g|i|m] [-w weight]-t|u|f service-address：事先定義好的某集群服務(wù)-r server-address: 某RS的地址，在NAT模型中，可使用IP：PORT實現(xiàn)端口映射；[-g|i|m]: LVS類型 -g: DR-i: TUN-m: NAT[-w weight]: 定義服務(wù)器權(quán)重 修改：-e 刪除：-d -t|u|f service-address -r server-address # ipvsadm -a -t 172.16.100.1:80 -r 192.168.10.8 –g # ipvsadm -a -t 172.16.100.1:80 -r 192.168.10.9 -g 查看-L|l-n: 數(shù)字格式顯示主機地址和端口--stats：統(tǒng)計數(shù)據(jù)--rate: 速率--timeout: 顯示tcp、tcpfin和udp的會話超時時長-:c 顯示當前的ipvs連接狀況 刪除所有集群服務(wù)-C：清空ipvs規(guī)則 保存規(guī)則，下次重啟電腦還可以使用-S # ipvsadm -S > /path/to/somefile 載入此前的規(guī)則：-R # ipvsadm -R < /path/form/somefile 123456789101112131415161718192021222324252627

LVS 實驗手冊

DR模型（直接路由模型）

學(xué)習(xí) keepalived 之前，關(guān)于高可用，你需要知道：

1、如果你的LVS負載均衡服務(wù)器掛掉了，你整個公司的業(yè)務(wù)就下線了，這是不能容忍的。
這屬于單點故障。
解決方法：一變多！但是入口的IP地址只能有一個，怎么變多？怎么實現(xiàn)多點？有2種形式：要么是主備，要么是主主
主備模型：備用機要以最快的速度接管原來的VIP（virtual IP），只有主機對外提供服務(wù)，只有主機掛了的時候，備機才頂上去。
主主模型：所有的LVS都是主，現(xiàn)在要借用其他形式搞定只有一個的入口IP地址，比如動態(tài)DNS。主和主之間是協(xié)作的形式。
我們首先討論主備，有兩個點需要考慮：方向性、效率性。

怎么知道主機掛沒掛？
可以由備機輪詢主機，但是這樣會對主或多或少造成一些壓力。
可以由主機發(fā)廣播到所有的備機，但是網(wǎng)絡(luò)是不可靠的，所以有一種重試機制。

如果已經(jīng)確定主機掛了，誰來作為新的主機？
使用加權(quán)重的方式，這也是paxos和zookeeper的區(qū)別。官方壓測200ms就能選出新的主機出來。

2、如果你后臺的某一個RS（Real Server）掛掉了，負載均衡服務(wù)器還會對另外兩臺正常連接，會造成一部分人的業(yè)務(wù)請求異常，另一部分人的業(yè)務(wù)正常。

怎么知道RS掛了？可以用ping嗎？
不可以！ping命令是網(wǎng)絡(luò)層的只能檢驗網(wǎng)絡(luò)能不能通，連TCP握手都不做，而web服務(wù)是應(yīng)用層的。能ping通不能代表web服務(wù)可用。那怎么知道RS掛沒掛？最簡單的方式是“訪問一下”。
“訪問一下”這個操作，它的底層驗證的是 應(yīng)用層的HTTP協(xié)議，你發(fā)一個請求，返回的是200ok，就說明是可用的。

LVS內(nèi)核中有模塊：ipvs負載均衡模塊。你想要檢測各個RS是否可用的話，可以直接去修改模塊的源碼，也可以使用第三方實現(xiàn)。第三方可以是人，也可以是自動化（也就有了自動化運維）。

這個自動化的程序就是 keepalived！它可以代替人工，實現(xiàn)自動運維。解決LVS單點故障，實現(xiàn)HA

keepalived

（1）監(jiān)控自己的LVS服務(wù)
（2）每一臺機器上都安裝keepalived。Master（主機）通告自己還活著，Backup（備機）監(jiān)聽Master狀態(tài)。如果Master掛了，一堆Backup推舉選出一個新的Master.
（3）你不需要再手動配置VIP，添加LVS（ipvs模塊）配置，只需要寫到配置文件中即可。
（4）對后端的RS（real server）做健康檢查，及時剔除不可用的節(jié)點
（5）最后，keepalived不僅僅用來解決LVS，它是一個通用的環(huán)境，主要作為linux上的HA的實現(xiàn)。例如，當你并發(fā)量不大的時候，nginx可以作為公司的負載均衡來使用，此時nginx成為了單點故障。這個問題也可以用keepalived來解決。

keepalived 實驗手冊

總結(jié)

以上是生活随笔為你收集整理的面试必会系列 - 5.3 LVS负载均衡的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。