運維面試必問的負載均衡高頻面試題（2021年最新版）

前言

網上的運維基礎面試題文章有非常多，在我的博客中也有一些是這些年運維人員面試的面試題，但是大部分都比較老了，之前一些經典的面試題我已經整理到專欄《運維面試寶典》里，這個專欄里的面試技巧可以說永遠不會過時，而且我會每隔一段時間進行補充和優化，

從一開始開專欄《運維面試寶典》的時候，規劃是10篇文章，現在已經更新了55篇文章，后續還會增加，

現在網上很多題目早已不是當前的熱門題目，沒有必要在這些題目上花太多時間，

很多答案放現在已經不準確，可能會誤導新人，

因此，我花了幾天時間整理了一些時下高頻的 Linux運維面試題，并反復斟酌，給出符合當前版本的決議，

這部分內容會收錄在專欄《我要進大廠》，適合所有有作業經驗的小伙伴和應屆畢業參加校招的小伙伴，

面試系列

這些年我一直在面試一線，幫助小伙伴輔導面試準備及面試復盤，拿到過大大小小的offer，比如阿里，位元組，美團，快手，百度等等
每次面試后我都會將面試的題目進行記錄，并整理成自己的題庫，最近我將這些題目整理出來，并按大廠的標準給出自己的決議，希望在這金三銀四的季節里，能助你一臂之力，

正文

1. Linux作業系統你們用的是哪個版本？

我們用的是centos7.6，內核版本是：

[root@itlaoxin-163 ~]# uname -r
3.10.0-1062.12.1.el7.x86_64

2. LVS 負載均衡有哪些策略？

LVS一共有三種作業模式： DR，Tunnel,NAT

3. 談談你對LVS的理解？

LVS是一個虛擬的服務器集群系統，在unix系統下實作負載均衡的功能；采用IP負載均衡技術和機遇內容請求分發技術來實作，
LVS采用三層結構，分別是：
第一層： 負載調度器
第二層： 服務池
第三層：共享存盤

負載調度器（load balancer/ Director），是整個集群的總代理，它有兩個網卡，一個網卡面對訪問網站的客戶端，一個網卡面對整個集群的內部，負責將客戶端的請求發送到一組服務器上執行，而客戶也認為服務是來自這臺主的，舉個生動的例子，集群是個公司，負載調度器就是在外接攬生意，將接攬到的生意分發給后臺的真正干活的真正的主機們，當然需要將活按照一定的演算法分發下去，讓大家都公平的干活，

服務器池（server pool/ Realserver），是一組真正執行客戶請求的服務器，可以當做WEB服務器，就是上面例子中的小員工，

共享存盤（shared storage），它為服務器池提供一個共享的存盤區，這樣很容易使得服務器池擁有相同的內容，提供相同的服務，一個公司得有一個后臺賬目吧，這才能協調，不然客戶把錢付給了A，而換B接待客戶，因為沒有相同的賬目，B說客戶沒付錢，那這樣就不是客戶體驗度的問題了，

4. 負載均衡的原理是什么？

當客戶端發起請求時，請求直接發給Director Server（調度器），這時會根據設定的調度演算法，將請求按照演算法的規定智能的分發到真正的后臺服務器，以達到將壓力均攤，

但是我們知道，http的連接時無狀態的，假設這樣一個場景，我登錄某寶買東西，當我看上某款商品時，我將它加入購物車，但是我重繪了一下頁面，這時由于負載均衡的原因，調度器又選了新的一臺服務器為我提供服務，我剛才的購物車內容全都不見了，這樣就會有十分差的用戶體驗，

所以就還需要一個存盤共享，這樣就保證了用戶請求的資料是一樣的

5. LVS由哪兩部分組成的？

LVS 由2部分程式組成，包括 ipvs 和 ipvsadm，

1.ipvs(ip virtual server)：一段代碼作業在內核空間，叫ipvs，是真正生效實作調度的代碼，
2. ipvsadm：另外一段是作業在用戶空間，叫ipvsadm，負責為ipvs內核框架撰寫規則，定義誰是集群服務，而誰是后端真實的服務器(Real Server)

6. 與lvs相關的術語有哪些？

DS：Director Server，指的是前端負載均衡器節點，
RS：Real Server，后端真實的作業服務器，
VIP：Virtual IP 向外部直接面向用戶請求，作為用戶請求的目標的IP地址，
DIP：Director Server IP，主要用于和內部主機通訊的IP地址，
RIP：Real Server IP，后端服務器的IP地址，
CIP：Client IP，訪問客戶端的IP地址，

7. LVS-NAT模式的原理

(a). 當用戶請求到達Director Server，此時請求的資料報文會先到內核空間的PREROUTING鏈， 此時報文的源IP為CIP，目標IP為VIP
(b). PREROUTING檢查發現資料包的目標IP是本機，將資料包送至INPUT鏈
?. IPVS比對資料包請求的服務是否為集群服務，若是，修改資料包的目標IP地址為后端服務器IP， 然后將資料包發至POSTROUTING鏈， 此時報文的源IP為CIP，目標IP為RIP
(d). POSTROUTING鏈通過選路，將資料包發送給Real Server
(e). Real Server比對發現目標為自己的IP，開始構建回應報文發回給Director Server， 此時報文的源IP為RIP，目標IP為CIP
(f). Director Server在回應客戶端前，此時會將源IP地址修改為自己的VIP地址，然后回應給客戶端， 此時報文的源IP為VIP，目標IP為CIP

8. LVS-NAT模型的特性

RS應該使用私有地址，RS的網關必須指向DIP

DIP和RIP必須在同一個網段內

請求和回應報文都需要經過Director Server，高負載場景中，Director Server易成為性能瓶頸

支持埠映射

RS可以使用任意作業系統

缺陷：對Director Server壓力會比較大，請求和回應都需經過director server

9. LVS-DR模式原理

(a) 當用戶請求到達Director Server，此時請求的資料報文會先到內核空間的PREROUTING鏈， 此時報文的源IP為CIP，目標IP為VIP
(b) PREROUTING檢查發現資料包的目標IP是本機，將資料包送至INPUT鏈
? IPVS比對資料包請求的服務是否為集群服務，若是，將請求報文中的源MAC地址修改為DIP的MAC地址，將目標MAC地址修改RIP的MAC地址，然后將資料包發至POSTROUTING鏈， 此時的源IP和目的IP均未修改，僅修改了源MAC地址為DIP的MAC地址，目標MAC地址為RIP的MAC地址
(d) 由于DS和RS在同一個網路中，所以是通過二層來傳輸，POSTROUTING鏈檢查目標MAC地址為RIP的MAC地址，那么此時資料包將會發至Real Server，
(e) RS發現請求報文的MAC地址是自己的MAC地址，就接收此報文，處理完成之后，將回應報文通過lo介面傳送給eth0網卡然后向外發出， 此時的源IP地址為VIP，目標IP為CIP
(f) 回應報文最終送達至客戶端

10. LVS-DR模型的特性

特點1：保證前端路由將目標地址為VIP報文統統發給Director Server，而不是RS

RS可以使用私有地址；也可以是公網地址，如果使用公網地址，此時可以通過互聯網對RIP進行直接訪問

RS跟Director Server必須在同一個物理網路中

所有的請求報文經由Director Server，但回應報文必須不能進過Director Server

不支持地址轉換，也不支持埠映射

RS可以是大多數常見的作業系統

RS的網關絕不允許指向DIP(因為我們不允許他經過director)

RS上的lo介面配置VIP的IP地址

缺陷：RS和DS必須在同一機房中

11. LVS三種負載均衡模式的比較

三種負載均衡： nat，tunneling，dr

12. LVS的負載調度演算法

• 輪叫調度
• 加權輪叫調度
• 最小連接調度
• 加權最小連接調度
• 基于區域性能的最少連接
• 帶復制的基于區域性能最小連接
• 目標地址散列調度
• 源地址散列調度

13. LVS與nginx的區別

lvs的優勢（互聯網老辛）：

• 1. 抗負載能力強，因為lvs作業方式的邏輯是非常簡單的，而且作業在網路的第4層，僅作請求分發用，沒有流量，所以在效率上基本不需要太過考慮，lvs一般很少出現故障，即使出現故障一般也是其他地方（如記憶體、CPU等）出現問題導致lvs出現問題，

• 2.配置性低，這通常是一大劣勢同時也是一大優勢，因為沒有太多的可配置的選項，所以除了增減服務器，并不需要經常去觸碰它，大大減少了人為出錯的幾率，

• 3.作業穩定，因為其本身抗負載能力很強，所以穩定性高也是順理成章的事，另外各種lvs都有完整的雙機熱備方案，所以一點不用擔心均衡器本身會出什么問題，節點出現故障的話，lvs會自動判別，所以系統整體是非常穩定的，

• 4.無流量，lvs僅僅分發請求，而流量并不從它本身出去，所以可以利用它這點來做一些線路分流之用，沒有流量同時也保住了均衡器的IO性能不會受到大流量的影響，

• 5.lvs基本上能支持所有應用，因為lvs作業在第4層，所以它可以對幾乎所有應用做負載均衡，包括http、資料庫、聊天室等，

nginx與LVS的對比：

• nginx作業在網路的第7層，所以它可以針對http應用本身來做分流策略，比如針對域名、目錄結構等，相比之下lvs并不具備這樣的功能，所以nginx單憑這點可以利用的場合就遠多于lvs了；但nginx有用的這些功能使其可調整度要高于lvs，所以經常要去觸碰，由lvs的第2條優點來看，觸碰多了，人為出現問題的幾率也就會大，

• nginx對網路的依賴較小，理論上只要ping得通，網頁訪問正常，nginx就能連得通，nginx同時還能區分內外網，如果是同時擁有內外網的節點，就相當于單機擁有了備份線路；lvs就比較依賴于網路環境，目前來看服務器在同一網段內并且lvs使用direct方式分流，效果較能得到保證，另外注意，lvs需要向托管商至少申請多于一個ip來做visual ip，

• nginx安裝和配置比較簡單，測驗起來也很方便，因為它基本能把錯誤用日志列印出來，lvs的安裝和配置、測驗就要花比較長的時間，因為同上所述，lvs對網路依賴性比較大，很多時候不能配置成功都是因為網路問題而不是配置問題，出了問題要解決也相應的會麻煩的多，

• nginx也同樣能承受很高負載且穩定，但負載度和穩定度差lvs還有幾個等級：nginx處理所有流量所以受限于機器IO和配置；本身的bug也還是難以避免的；nginx沒有現成的雙機熱備方案，所以跑在單機上還是風險比較大，單機上的事情全都很難說，

• nginx可以檢測到服務器內部的故障，比如根據服務器處理網頁回傳的狀態碼、超時等等，并且會把回傳錯誤的請求重新提交到另一個節點，目前lvs中ldirectd也能支持針對服務器內部的情況來監控，但lvs的原理使其不能重發請求，比如用戶正在上傳一個檔案，而處理該上傳的節點剛好在上傳程序中出現故障，nginx會把上傳切到另一臺服務器重新處理，而lvs就直接斷掉了，

兩者配合使用：

nginx用來做http的反向代理，能夠upsteam實作http請求的多種方式的均衡轉發，由于采用的是異步轉發可以做到如果一個服務器請求失敗，立即切換到其他服務器，直到請求成功或者最后一臺服務器失敗為止，這可以最大程度的提高系統的請求成功率，

lvs采用的是同步請求轉發的策略，這里說一下同步轉發和異步轉發的區別，同步轉發是在lvs服務器接收到請求之后，立即redirect到一個后端服務器，由客戶端直接和后端服務器建立連接，異步轉發是nginx在保持客戶端連接的同時，發起一個相同內容的新請求到后端，等后端回傳結果后，由nginx回傳給客戶端，

進一步來說：當做為負載均衡服務器的nginx和lvs處理相同的請求時，所有的請求和回應流量都會經過nginx；但是使用lvs時，僅請求流量經過lvs的網路，回應流量由后端服務器的網路回傳，

也就是，當作為后端的服務器規模龐大時，nginx的網路帶寬就成了一個巨大的瓶頸，

但是僅僅使用lvs作為負載均衡的話，一旦后端接受到請求的服務器出了問題，那么這次請求就失敗了，但是如果在lvs的后端在添加一層nginx（多個），每個nginx后端再有幾臺應用服務器，那么結合兩者的優勢，既能避免單nginx的流量集中瓶頸，又能避免單lvs時一錘子買賣的問題，

14. 負載均衡的作用有哪些？

1、轉發功能

按照一定的演算法【權重、輪詢】，將客戶端請求轉發到不同應用服務器上，減輕單個服務器壓力，提高系統并發量，

2、故障移除

通過心跳檢測的方式，判斷應用服務器當前是否可以正常作業，如果服務器期宕掉，自動將請求發送到其他應用服務器，

3、恢復添加

如檢測到發生故障的應用服務器恢復作業，自動將其添加到處理用戶請求隊伍中，

15. nginx實作負載均衡的分發策略

Nginx 的 upstream目前支持的分配演算法：
1)、輪詢 ——1：1 輪流處理請求（默認）

  每個請求按時間順序逐一分配到不同的應用服務器，如果應用服務器down掉，自動剔除，剩下的繼續輪詢， 

2)、權重 ——you can you up
通過配置權重，指定輪詢幾率，權重和訪問比率成正比，用于應用服務器性能不均的情況，
3)、ip_哈希演算法
每個請求按訪問ip的hash結果分配，這樣每個訪客固定訪問一個應用服務器，可以解決session共享的問題，

16. keepalived 是什么？

廣義上講是高可用，狹義上講是主機的冗余和管理

Keepalived起初是為LVS設計的，專門用來監控集群系統中各個服務節點的狀態，它根據TCP/IP參考模型的第三、第四層、第五層交換機制檢測每個服務節點的狀態，如果某個服務器節點出現例外，或者作業出現故障，Keepalived將檢測到，并將出現的故障的服務器節點從集群系統中剔除，這些作業全部是自動完成的，不需要人工干涉，需要人工完成的只是修復出現故障的服務節點，

后來Keepalived又加入了VRRP的功能，VRRP（VritrualRouterRedundancyProtocol,虛擬路由冗余協議)出現的目的是解決靜態路由出現的單點故障問題，通過VRRP可以實作網路不間斷穩定運行，因此Keepalvied一方面具有服務器狀態檢測和故障隔離功能，另外一方面也有HAcluster功能，

所以keepalived的核心功能就是健康檢查和失敗且換，
所謂的健康檢查，就是采用tcp三次握手，icmp請求，http請求，udp echo請求等方式對負載均衡器后面的實際的服務器(通常是承載真實業務的服務器)進行保活；

而失敗切換主要是應用于配置了主備模式的負載均衡器，利用VRRP維持主備負載均衡器的心跳，當主負載均衡器出現問題時，由備負載均衡器承載對應的業務，從而在最大限度上減少流量損失，并提供服務的穩定性

17. 你是如何理解VRRP協議的

為什么使用VRRP？
主機之間的通信都是通過配置靜態路由或者(默認網關)來完成的，而主機之間的路由器一旦發生故障，通信就會失效，因此這種通信模式當中，路由器就成了一個單點瓶頸，為了解決這個問題，就引入了VRRP協議，

VRRP協議是一種容錯的主備模式的協議，保證當主機的下一跳路由出現故障時，由另一臺路由器來代替出現故障的路由器進行作業，通過VRRP可以在網路發生故障時透明的進行設備切換而不影響主機之間的資料通信，

VRRP的三種狀態：
VRRP路由器在運行程序中有三種狀態：

1. Initialize狀態： 系統啟動后就進入Initialize，此狀態下路由器不對VRRP報文做任何處理；
2. Master狀態；
3. Backup狀態；
   一般主路由器處于Master狀態，備份路由器處于Backup狀態，

18. keepalived的作業原理？

keepalived采用是模塊化設計，不同模塊實作不同的功能，

keepalived主要有三個模塊，分別是core、check和vrrp，

core：是keepalived的核心，負責主行程的啟動和維護，全域組態檔的加載決議等

check： 負責healthchecker(健康檢查)，包括了各種健康檢查方式，以及對應的配置的決議包括LVS的配置決議；可基于腳本檢查對IPVS后端服務器健康狀況進行檢查

vrrp：VRRPD子行程，VRRPD子行程就是來實作VRRP協議的

Keepalived高可用對之間是通過 VRRP進行通信的， VRRP是通過競選機制來確定主備的，主的優先級高于備，因此，作業時主會優先獲得所有的資源，備節點處于等待狀態，當主宕機的時候，備節點就會接管主節點的資源，然后頂替主節點對外提供服務

在Keepalived服務對之間，只有作為主的服務器會一直發送 VRRP廣播包,告訴備它還活著，此時備不會搶占主，當主不可用時，即備監聽不到主發送的廣播包時，就會啟動相關服務接管資源，保證業務的連續性.接管速度最快

19. 出現腦裂的原因

什么是腦裂？

• 在高可用（HA）系統中，當聯系2個節點的“心跳線”斷開時，本來為一整體、動作協調的HA系統，就分裂成為2個獨立的個體，
• 由于相互失去了聯系，都以為是對方出了故障，兩個節點上的HA軟體像“裂腦人”一樣，爭搶“共享資源”、爭起“應用服務”，就會發生嚴重后果，共享資源被瓜分、兩邊“服務”都起不來了；或者兩邊“服務”都起來了，但同時讀寫“共享存盤”，導致資料損壞

都有哪些原因導致腦裂？

高可用服務器對之間心跳線鏈路發生故障，導致無法正常通信，

因心跳線壞了（包括斷了，老化），

因網卡及相關驅動壞了，ip配置及沖突問題（網卡直連）

因心跳線間連接的設備故障（網卡及交換機）

因仲裁的機器出問題（采用仲裁的方案）

高可用服務器上開啟了 iptables防火墻阻擋了心跳訊息傳輸，

高可用服務器上心跳網卡地址等資訊配置不正確，導致發送心跳失敗

其他服務配置不當等原因，如心跳方式不同，心跳廣插沖突、軟體Bug等，

20. 如何解決keepalived腦裂問題？

在實際生產環境中，我們從以下方面防止腦裂：

• 同時使用串行電纜和以太網電纜連接、同時使用兩條心跳線路，這樣一條線路斷了，另外一潭訓是好的，依然能傳送心跳訊息

• 當檢查腦裂時強行關閉一個心跳節點（這個功能需要特殊設備支持，如stonith、fence）相當于備節點接收不到心跳訊息，通過單獨的線路發送關機命令關閉主節點的電源

• 做好對腦裂的監控報警
  解決常見方案：

• 如果開啟防火墻，一定要讓心跳訊息通過，一般通過允許IP段的形式解決

• 可以拉一條以太網網線或者串口線作為主被節點心跳線路的冗余

• 開發檢測程式通過監控軟體檢測腦裂

21. zabbix如何監控腦裂？

監控只是監控發生腦裂的可能性，不能保證一定是發生了腦裂，因為正常的主備切換VIP也是會到備上的

監控腳本：

[root@slave ~]# mkdir -p /scripts && cd /scripts
[root@slave scripts]# vim check_keepalived.sh
#!/bin/bash

if [ `ip a show ens33 |grep 192.168.32.250|wc -l` -ne 0 ]
then
    echo "keepalived is error!"
else
    echo "keepalived is OK !"
fi

22. nginx做負載均衡實作的策略有哪些

• 輪詢（默認）
• 權重
• ip_hash
• fair(第三方插件）
• url_hash（第三方插件）

23. nginx做負載均衡用到哪些模塊

upstream 定義負載節點池，
location 模塊 進行URL匹配，
proxy模塊 發送請求給upstream定義的節點池，

24. 負載均衡有哪些實作方式

• 硬體負載
• HTTP重定向負載均衡
• DNS負載均衡
• 反向代理負載均衡
• IP層負載均衡
• 資料鏈路層負載均衡
• 

25. nginx如何實作四層負載？

四層負載分為動態和靜態負載
Nginx的四層靜態負載均衡需要啟用ngx_stream_core_module模塊
默認情況下，ngx_stream_core_module是沒有啟用的，需要在安裝Nginx時，添加–with-stream配置引數啟用
配置HTTP負載均衡時，都是配置在http指令下，配置四層負載均衡，則是在stream指令下，結構如下所示.

stream {
 upstream mysql_backend {
  server 192.168.175.100:3306 max_fails=2 fail_timeout=10s weight=1;
  least_conn;
 }
 server { #監聽埠，默認使用的是tcp協議，如果需要UDP協議，則配置成listen 3307 udp; listen 3307; #失敗重試 proxy_next_upstream on;
  proxy_next_upstream_timeout 0;
  proxy_next_upstream_tries 0; #超時配置 #配置與上游服務器連接超時時間，默認60s proxy_connect_timeout 1s; #配置與客戶端上游服務器連接的兩次成功讀/寫操作的超時時間，如果超時，將自動斷開連接 #即連接存活時間，通過它可以釋放不活躍的連接，默認10分鐘 proxy_timeout 1m; #限速配置 #從客戶端讀資料的速率，單位為每秒位元組數，默認為0，不限速 proxy_upload_rate 0; #從上游服務器讀資料的速率，單位為每秒位元組數，默認為0，不限速 proxy_download_rate 0; #上游服務器 proxy_pass mysql_backend;
 }
}

使用Nginx的四層動態負載均衡有兩種方案：使用商業版的Nginx和使用開源的nginx-stream-upsync-module模塊，注意：四層動態負載均衡可以使用nginx-stream-upsync-module模塊，七層動態負載均衡可以使用nginx-upsync-module模塊，

最后

金三銀四的季節，相信有不少同學正準備跳槽，

近期我會對運維的高頻問題進行整理匯總，對每個題目決議時都會按較高的標準進行深入剖析，有很多是去大公司面試的面試真題，可能只看一遍并不能完全明白，但是相信反復閱讀，定能有所識訓，

原創不易，如果你覺得本文寫的還不錯，對你有幫助，請通過【點贊】讓我知道，支持我寫出更好的文章