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

更多內容，可以訪問：

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

---

目錄

• LVS 負載均衡
• • • 網絡協議原理
    • • 引入
      • 七層模型
      • TCP / IP（詳見5.2節）
      • 路由表
      • 下一跳機制
      • 路由器、交換機
      • ARP 協議
      • • ARP 請求
        • ARP 響應
        • 案例
      • 網絡包傳輸的過程
      • 負載均衡 & LVS 的引入
      • NAT 網路地址轉換
      • • （1）S-NAT 模式：源地址替換協議
        • （2）D-NAT 模式：目標地址轉換協議（基于3層網絡層）
        • （3）DR 模型：直接路由模型（基于2層鏈路層）
        • （4）隧道模式
      • LVS
      • 隱藏的Virtual IP 配置原理
      • 負載均衡調度方法
      • LVS在Linux中自帶的ipvs內核模塊
      • LVS 實驗手冊
      • 學習 keepalived 之前，關于高可用，你需要知道：
      • keepalived
      • keepalived 實驗手冊

LVS 負載均衡

網絡協議原理

引入

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

假設高并發被解決了，在web容器的日志里你要記錄些什么？分析渠道的流量的質量，分析不同的渠道給我帶來多少的訪問量。每個渠道的轉化率，購買力。這樣就可以知道下一輪投資應該在什么渠道多投廣告。中國在從制造向服務行業轉型（service）。

七層模型

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

TCP / IP（詳見5.2節）

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

子網掩碼：將 IP 地址與子網掩碼做按位與運算，得到網絡號。

路由表

route -n 查看路由表，路由表是動態生成的。

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

下一跳機制

基于下一跳機制：每一個互聯網的設備，內存中不需要存儲全網的數據，只需要存儲它周邊一個網絡當中的數據。有人做過一個實驗，從美國向外發送所有的數據包，另一端都能夠按照正確的順序拼接。這個實驗證明了基于下一跳的TCP傳輸方式是可以保證可靠傳輸的！

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

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

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

• IP 地址的最終目標是 端點 間的
• MAC 地址的目標是是 節點 間的

路由器、交換機

路由器就是要連接不同的網段，它是用來選擇路線的。它里面有路由表，可以進行路由轉發的判定。

交換機是負責同一個網絡中轉發，他只要轉發就行了。

ARP 協議

發送端必須獲取到目的MAC地址，MAC地址通過ARP協議來獲取。
arp -a本質就是一個IP地址->MAC地址的對應表，表中每一個條目分別記錄了網絡上其他主機的IP地址和對應的MAC地址。
ARP表在初始的時候是空的。

ARP 請求

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

ARP 響應

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

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

案例

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

網絡包傳輸的過程

看下圖，一個網絡包在發送的過程中，每經過一跳，它的目標mac地址、源mac地址都要通過路由器發生改變，而源IP、目標IP始終是不變的。

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

負載均衡 & LVS 的引入

同一網絡當中IP地址不能重復出現，否則會沖突，不知道應該發給誰。那怎么使用多個服務器實現多并發呢？

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

路由器只是三層的設備，只需要做轉發。

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

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

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

NAT 網路地址轉換

網路地址轉換一般出現在路由器上
首先我們要知道，私有地址不會出現在互聯網上

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

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

（2）D-NAT 模式：目標地址轉換協議（基于3層網絡層）

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

弊端：

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

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

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

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

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

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

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

（4）隧道模式

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

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

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

LVS

LVS是Linux Virtual Server的簡寫，意即Linux虛擬服務器，是一個虛擬的服務器集群系統。

我們定義一些名詞縮寫：

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

隱藏的Virtual IP 配置原理

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

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

將VIP配置在環回接口lo上

負載均衡調度方法

四種靜態調度方法：
rr: 輪叫調度（Round-Robin Scheduling）
wrr:加權輪叫調度（Weighted Round-Robin Scheduling）
dh: 目標地址散列調度（Destination Hashing Scheduling）
sh:源地址散列調度（Source Hashing Scheduling）

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

LVS在Linux中自帶的ipvs內核模塊

ipvs內核模塊
yum install ipvsadm -y

管理集群服務

添加：-A -t|u|f service-address [-s scheduler] -t: TCP協議的集群 -u: UDP協議的集群 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

管理集群服務中的RS

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

LVS 實驗手冊

DR模型（直接路由模型）

學習 keepalived 之前，關于高可用，你需要知道：

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

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

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

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

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

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

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

keepalived

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

keepalived 實驗手冊

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。