Linux運維工程師面試題（3）
1 LVS 的工作模式有幾種，分別是什么
2 LVS 由哪幾部分組成
3 LVS 相關(guān)的術(shù)語有哪些
4 LVS 集群的負(fù)載調(diào)度算法有哪些
5 使用LVS 可不可以把iptables給禁用刪除
6 haproxy 調(diào)度算法有哪些
7 nginx 實現(xiàn)負(fù)載均衡的分發(fā)策略有那些
8 四層負(fù)載和七層負(fù)載的區(qū)別
9 負(fù)載均衡的作用有哪些
10 LVS、HAProxy、Nginx三款負(fù)載均衡的優(yōu)缺點及區(qū)別

Linux運維工程師面試題（3）

祝各位小伙伴們早日找到自己心儀的工作。 持續(xù)學(xué)習(xí)才不會被淘汰。 地球不爆炸，我們不放假。 機(jī)會總是留給有有準(zhǔn)備的人的。 加油，打工人！

1 LVS 的工作模式有幾種，分別是什么

三種：

• NAT 模式：修改請求報文的目標(biāo)IP，多目標(biāo)IP的DNAT

• DR 模式（默認(rèn)模式）：操縱封裝新的MAC地址

• TUN 模式：在原請求IP報文之外新加—個IP首部

2 LVS 由哪幾部分組成

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

1. ipvs (ip virtual server)：一段代碼工作在內(nèi)核空間，叫ipvs，是真正生效實現(xiàn)調(diào)度的代碼；

2. ipvsadm：另外一段是工作在用戶空間，叫ipvsadm，負(fù)責(zé)為ipvs內(nèi)核框架編寫規(guī)則，定義誰是集群服務(wù)，而誰是后端真實的服務(wù)器（Real Server）。

3 LVS 相關(guān)的術(shù)語有哪些

• DS：Director Server，指的是前端負(fù)載均衡器節(jié)點。

• RS：Real Server，后端真實的工作服務(wù)器。

• VIP：Virtual IP，向外部直接面向用戶請求，作為用戶請求的目標(biāo)的IP地址。

• DIP：Director Server IP，主要用于和內(nèi)部主機(jī)通訊的IP地址。

• RIP：Real Server IP，后端服務(wù)器的IP地址。

• CIP：Client IP，訪問客戶端的IP地址。

4 LVS 集群的負(fù)載調(diào)度算法有哪些

• 輪叫（輪詢、輪流）調(diào)度（Round-Robin Scheduling）rr

• 加權(quán)輪叫（輪詢）調(diào)度（Weighted Round-Robin Scheduling）wrr

• 最小連接調(diào)度（Least-Connection Scheduling）lc

• 加權(quán)最小連接調(diào)度（Weighted Least-Connection Scheduling）wlc（默認(rèn)調(diào)度算法）

• 基于局部性的最少鏈接（Locality-Based Least Connections Scheduling）lblc

• 帶復(fù)制的基于局部性最少鏈接（Locality-Based Least Connections with Replication Scheduling）lblcr

• 目標(biāo)地址散列調(diào)度（Destination Hashing Scheduling）dh

• 源地址散列調(diào)度（Source Hashing Scheduling）sh

5 使用LVS 可不可以把iptables給禁用刪除

可以，禁用iptables并不會影響LVS的使用。LVS是在Linux內(nèi)核層面實現(xiàn)的負(fù)載均衡技術(shù)，其底層并不依賴于iptables進(jìn)行流量轉(zhuǎn)發(fā)。LVS使用IP隧道或網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT）等技術(shù)將來自客戶端的流量轉(zhuǎn)發(fā)到后端服務(wù)器上，而不依賴于iptables規(guī)則。

6 haproxy 調(diào)度算法有哪些

tcp代表四層負(fù)載，http代表七層負(fù)載。

靜態(tài)算法：

• static-rr-------->tcp/http：基于權(quán)重的輪詢調(diào)度，不支持運行時利用socat進(jìn)行權(quán)重的動態(tài)調(diào)整(只支持0和1，不支持其它值及后端服務(wù)器慢啟動，其后端主機(jī)數(shù)量沒有限制，相當(dāng)于LVS中的wrr。

• first------------->tcp/http：根據(jù)服務(wù)器在列表中的位置，自上而下進(jìn)行調(diào)度，但是其只會當(dāng)?shù)谝慌_服務(wù)器的連接數(shù)達(dá)到上限，新請求才會分配給下一臺服務(wù)，因此會忽略服務(wù)器的權(quán)重設(shè)置，此方式使用較少。不支持用socat進(jìn)行動態(tài)修改權(quán)重，可以設(shè)置0和1，可以設(shè)置其它值但無效。

動態(tài)算法：

• roundrobin------->tcp/http：基于權(quán)重的輪詢動態(tài)調(diào)度算法，支持權(quán)重的運行時調(diào)整，不同于lvs中的rr輪訓(xùn)模式，haproxy中的roundrobin支持慢啟動(新加的服務(wù)器會逐漸增加轉(zhuǎn)發(fā)數(shù))，其每個后端backend中最多支持4095個real server，支持對real server權(quán)重動態(tài)調(diào)整，roundrobin為默認(rèn)調(diào)度算法，此算法使用廣泛。

• leastconn--------->tcp/http：加權(quán)的最少連接的動態(tài)，支持權(quán)重的運行時調(diào)整和慢啟動，即：根據(jù)當(dāng)前連接最少的后端服務(wù)器而非權(quán)重進(jìn)行優(yōu)先調(diào)度(新客戶端連接)，比較適合長連接的場景使用，比如：MySQL等場景。

• random------------>tcp/http：在1.9版本開始增加random的負(fù)載平衡算法，其基于隨機(jī)數(shù)作為一致性hash的key，隨機(jī)負(fù)載平衡對于大型服務(wù)器場或經(jīng)常添加或刪除服務(wù)器非常有用，支持weight的動態(tài)調(diào)整，weight較大的主機(jī)有更大概率獲取新請求。

其他算法：以下靜態(tài)和動態(tài)取決于hash_type是否consistent

• source---------->tcp/http：源地址hash，基于用戶源地址hash并將請求轉(zhuǎn)發(fā)到后端服務(wù)器，后續(xù)同一個源地址請求將被轉(zhuǎn)發(fā)至同一個后端web服務(wù)器。此方式當(dāng)后端服務(wù)器數(shù)據(jù)量發(fā)生變化時，會導(dǎo)致很多用戶的請求轉(zhuǎn)發(fā)至新的后端服務(wù)器，默認(rèn)為靜態(tài)方式，但是可以通過hash-type支持的選項更改。 這個算法一般是在不插入Cookie的TCP模式下使用，也可給拒絕會話cookie的客戶提供最好的會話粘性，適用于session會話保持但不支持cookie和緩存的場景。 源地址有兩種轉(zhuǎn)發(fā)客戶端請求到后端服務(wù)器的服務(wù)器選取計算方式，分別是取模法和一致性hash。

• uri--------------->http：基于對用戶請求的URI的左半部分或整個uri做hash，再將hash結(jié)果對總權(quán)重進(jìn)行取模后，根據(jù)最終結(jié)果將請求轉(zhuǎn)發(fā)到后端指定服務(wù)器，適用于后端是緩存服務(wù)器場景，默認(rèn)是靜態(tài)算法，也可以通過hash-type指定map-based和consistent，來定義使用取模法還是一致性hash。

• url_param---->http：url_param對用戶請求的url中的params部分中的一個參數(shù)key對應(yīng)的value值作hash計算，并由服務(wù)器總權(quán)重相除以后派發(fā)至某挑出的服務(wù)器；通常用于追蹤用戶，以確保來自同一個用戶的請求始終發(fā)往同一個real server，如果無沒key，將按roundrobin算法。

• hdr-------------->http：針對用戶每個http頭部(header)請求中的指定信息做hash，此處由name指定的http首部將會被取出并做hash計算，然后由服務(wù)器總權(quán)重取模以后派發(fā)至某挑出的服務(wù)器，如果無有效值，則會使用默認(rèn)的輪詢調(diào)度。

• rdp-cookie---->tcp：rdp-cookie 對windows遠(yuǎn)程桌面的負(fù)載，使用cookie保持會話，默認(rèn)是靜態(tài)，也可以通過hash-type指定map-based和consistent，來定義使用取模法還是—致性hash。

各算法使用場景

first ?# 使用較少

static-rr # 做了session共享的web集群
roundrobin
random

leastconn # 數(shù)據(jù)庫
source ?# 基于客戶端公網(wǎng)IP的會話保持

uri--------->http # 緩存服務(wù)器，CDN服務(wù)商，藍(lán)汛、百度、阿里云、騰訊
url_param--->http # 可以實現(xiàn)session保持

hdr ? # 基于客戶端請求報文頭部做下一步處理
rdp-cookie # 基于windows主機(jī),很少使用

7 nginx 實現(xiàn)負(fù)載均衡的分發(fā)策略有那些

• 輪詢（默認(rèn)）：每個請求按時間順序逐一分配到不同的后端服務(wù)器，如果后端某個服務(wù)器宕機(jī)，能自動剔除故障系統(tǒng)。

• 權(quán)重 weight：weight 的值越大，被訪問概率越高，主要用于后端每臺服務(wù)器性能不均衡的情況下。其次是為在主從的情況下設(shè)置不同的權(quán)值，達(dá)到合理有效的地利用主機(jī)資源。

• ip_hash（IP綁定）：每個請求按訪問IP的哈希結(jié)果分配，使來自同一個IP的訪客固定訪問一臺后端服務(wù)器，并且可以有效解決動態(tài)網(wǎng)頁存在的session共享問題

• url_hash（第三方插件）：必須安裝Nginx的hash軟件包，按訪問url的hash結(jié)果來分配請求，使每個url定向到同一個后端服務(wù)器，可以進(jìn)一步提高后端緩存服務(wù)器的效率。

• fair（第三方插件）：必須安裝upstream_fair模塊。對比 weight、ip_hash更加智能的負(fù)載均衡算法，fair算法可以根據(jù)頁面大小和加載時間長短智能地進(jìn)行負(fù)載均衡，響應(yīng)時間短的優(yōu)先分配。

8 四層負(fù)載和七層負(fù)載的區(qū)別

• 四層：IP+PORT轉(zhuǎn)發(fā)

• 七層：協(xié)議+內(nèi)容交換

四層負(fù)載：

在四層負(fù)載設(shè)備中，把client發(fā)送的報文目標(biāo)地址(原來是負(fù)載均衡設(shè)備的IP地址)，根據(jù)均衡設(shè)備設(shè)置的選擇web服務(wù)器的規(guī)則選擇對應(yīng)的web服務(wù)器IP地址，這樣client就可以直接跟此服務(wù)器建立TCP連接并發(fā)送數(shù)據(jù)，而四層負(fù)載自身不參與建立連接，而和LVS不同，haproxy是偽四層負(fù)載均衡，因為haproxy需要分別和前端客戶端及后端服務(wù)器建立連接。

七層負(fù)載：

七層負(fù)載均衡服務(wù)器起了一個反向代理服務(wù)器的作用，服務(wù)器建立一次TCP連接要三次握手，而client要訪問Web Server要先與七層負(fù)載設(shè)備進(jìn)行三次握手后建立TCP連接，把要訪問的報文信息發(fā)送給七層負(fù)載均衡；然后七層負(fù)載均衡再根據(jù)設(shè)置的均衡規(guī)則選擇特定的Web Server，然后通過三次握手與此臺Web Server建立TCP連接，然后Web Server把需要的數(shù)據(jù)發(fā)送給七層負(fù)載均衡設(shè)備，負(fù)載均衡設(shè)備再把數(shù)據(jù)發(fā)送給client；所以，七層負(fù)載均衡設(shè)備起到了代理服務(wù)器的作用，七層代理需要和Client和后端服務(wù)器分別建立連接。

簡單說：4層是修改用戶請求的目標(biāo)路由直接轉(zhuǎn)發(fā)到服務(wù)器；7層是把用戶的報文拆分開，由負(fù)載均衡替代用戶發(fā)送到服務(wù)端。同樣的返回報文的時候先發(fā)給負(fù)載均衡器，然后負(fù)載均衡修改報文后再發(fā)給用戶。所以我們看到的日志的用戶ip是負(fù)載均衡器的ip地址，因此需要做ip透傳x-forward。

9 負(fù)載均衡的作用有哪些

1. 轉(zhuǎn)發(fā)功能：按照一定的算法【權(quán)重、輪詢】，將客戶端請求轉(zhuǎn)發(fā)到不同應(yīng)用服務(wù)器上，減輕單個服務(wù)器壓力，提高系統(tǒng)并發(fā)量。

2. 故障移除：通過心跳檢測的方式，判斷應(yīng)用服務(wù)器當(dāng)前是否可以正常工作，如果服務(wù)器期宕掉，自動將請求發(fā)送到其他應(yīng)用服務(wù)器。

3. 恢復(fù)添加：如檢測到發(fā)生故障的應(yīng)用服務(wù)器恢復(fù)工作，自動將其添加到處理用戶請求隊伍中。

10 LVS、HAProxy、Nginx三款負(fù)載均衡的優(yōu)缺點及區(qū)別

LVS 的優(yōu)點：

1. 抗負(fù)載能力強(qiáng)、工作在第4層僅作分發(fā)之用，沒有流量的產(chǎn)生，這個特點也決定了它在負(fù)載均衡軟件里的性能最強(qiáng)的；無流量，同時保證了均衡器IO的性能不會受到大流量的影響；

2. 工作穩(wěn)定，自身有完整的雙機(jī)熱備方案，如LVS+Keepalived和LVS+Heartbeat；

3. 應(yīng)用范圍比較廣，可以對所有應(yīng)用做負(fù)載均衡；

4. 配置性比較低，這是一個缺點也是一個優(yōu)點，因為沒有可太多配置的東西，所以并不需要太多接觸，大大減少了人為出錯的幾率；

LVS的缺點：

1. 軟件本身不支持正則處理，不能做動靜分離，這就凸顯了Nginx/HAProxy+Keepalived的優(yōu)勢。

2. 如果網(wǎng)站應(yīng)用比較龐大，LVS/DR+Keepalived就比較復(fù)雜了，特別是后面有Windows Server應(yīng)用的機(jī)器，實施及配置還有維護(hù)過程就比較麻煩，相對而言，Nginx/HAProxy+Keepalived就簡單多了。

Nginx的優(yōu)點：

1. 工作在OSI第7層，可以針對http應(yīng)用做一些分流的策略。比如針對域名、目錄結(jié)構(gòu)。它的正則比HAProxy更為強(qiáng)大和靈活；

2. Nginx對網(wǎng)絡(luò)的依賴非常小，理論上能ping通就就能進(jìn)行負(fù)載功能，這個也是它的優(yōu)勢所在；

3. Nginx安裝和配置比較簡單，測試起來比較方便；

4. 可以承擔(dān)高的負(fù)載壓力且穩(wěn)定，一般能支撐超過幾萬次的并發(fā)量；

5. Nginx可以通過端口檢測到服務(wù)器內(nèi)部的故障，比如根據(jù)服務(wù)器處理網(wǎng)頁返回的狀態(tài)碼、超時等等，并且會把返回錯誤的請求重新提交到另一個節(jié)點；

6. Nginx不僅僅是一款優(yōu)秀的負(fù)載均衡器/反向代理軟件，它同時也是功能強(qiáng)大的Web應(yīng)用服務(wù)器。LNMP現(xiàn)在也是非常流行的web環(huán)境，大有和LAMP環(huán)境分庭抗禮之勢，Nginx在處理靜態(tài)頁面、特別是抗高并發(fā)方面相對apache有優(yōu)勢；

7. Nginx現(xiàn)在作為Web反向加速緩存越來越成熟了，速度比傳統(tǒng)的Squid服務(wù)器更快，有需求的朋友可以考慮用其作為反向代理加速器；

Nginx的缺點：

1. Nginx不支持url來檢測。

2. Nginx僅能支持http和Email，這個它的弱勢。

3. Nginx的Session的保持，Cookie的引導(dǎo)能力相對欠缺。

HAProxy的優(yōu)點：

1. HAProxy是支持虛擬主機(jī)的，可以工作在4、7層(支持多網(wǎng)段)；

2. 能夠補充Nginx的一些缺點比如Session的保持，Cookie的引導(dǎo)等工作；

3. 支持url檢測后端的服務(wù)器；

4. 它跟LVS一樣，本身僅僅就只是一款負(fù)載均衡軟件；單純從效率上來講HAProxy更會比Nginx有更出色的負(fù)載均衡速度，在并發(fā)處理上也是優(yōu)于Nginx的；

5. HAProxy可以對Mysql讀進(jìn)行負(fù)載均衡，對后端的MySQL節(jié)點進(jìn)行檢測和負(fù)載均衡，不過在后端的MySQL slaves數(shù)量超過10臺時性能不如LVS；

6. HAProxy的算法較多，達(dá)到8種；

LVS：是基于四層的轉(zhuǎn)發(fā) HAproxy：是基于四層和七層的轉(zhuǎn)發(fā)，是專業(yè)的代理服務(wù)器 Nginx：是WEB服務(wù)器，緩存服務(wù)器，又是反向代理服務(wù)器，可以做七層的轉(zhuǎn)發(fā)

區(qū)別：LVS由于是基于四層的轉(zhuǎn)發(fā)所以只能做端口的轉(zhuǎn)發(fā)，而基于URL的、基于目錄的這種轉(zhuǎn)發(fā)LVS就做不了

工作選擇：HAproxy和Nginx由于可以做七層的轉(zhuǎn)發(fā)，所以URL和目錄的轉(zhuǎn)發(fā)都可以做，在很大并發(fā)量的時候我們就要選擇LVS，像中小型公司的話并發(fā)量沒那么大，選擇HAproxy或者Nginx足已，由于HAproxy由是專業(yè)的代理服務(wù)器，配置簡單，所以中小型企業(yè)推薦使用HAproxy

以上面試題僅僅個人總結(jié)，想到什么就寫什么，沒有任何順序，寫的有什么不對的地方請各位大佬評論、留言，我會及時更正。

原文鏈接: [Linux運維工程師面試題（3）](https://blog.waluna.top/2023/02/25/1349/).