文章目錄
面向面試的博客，以問答式Q/A方式呈現。
Question1：介紹一下 負載均衡？
Answer1：
含義：
負載均衡是指在現有網絡結構之上，提供了一種廉價有效透明的方法擴展網絡設備和服務器的帶寬、增加吞吐量 、加強網絡數據處理能力、提高網絡的靈活性和可用性的機制。
負載均衡包括兩種，四層負載均衡和七層負載均衡，如下圖所示：
注意：二層負載均衡、三層負載均衡、四層負載均衡、七層負載均衡
OSI標準的從下到上分別是：物理層,數據鏈路層,網絡層,傳輸層,會話層,表示層和應用層；
二層負載均衡是OSI的第二層-數據鏈路層，使用MAC地址，是基於MAC地址的負載均衡，二層負載均衡會通過一個虛擬MAC地址接收請求，然後再分配到真實的MAC地址；
三層負載均衡是OSI的第三層-網絡層，使用的IP協議和IP地址，是基於IP地址的負載均衡，三層負載均衡會通過一個虛擬IP地址接收請求，然後再分配到真實的IP地址；
四層負載均衡是OSI的第四層-傳輸層，使用的TCP協議和UDP協議，四層負載均衡是基於IP+端口的負載均衡；
七層負載均衡是OSI的最高層-應用層，是基於URL等應用層信息的負載均衡。
四層通過虛擬IP+端口接收請求，然後再分配到真實的服務器；七層通過虛擬的URL或主機名接收請求，然後再分配到真實的服務器。
王道在於：哪一層的負載均衡就是使用哪一層的頭部信息進行修改目的地址併網絡轉發，二層負載均衡修改mac地址網絡轉發，三層負載均衡修改ip地址網絡轉發，四層負載均衡修改ip:port組合網絡轉發，七層負載均衡修改url域名網絡轉發。常見地，Nginx做一個軟件層面的負載均衡服務端，既可以做四層負載均衡，根據ip:port組合網絡轉發，又可以根據url域名網絡轉發。
四層負載均衡（ 目標地址和端口交換 ）
工作原理：
所謂四層負載均衡，也稱爲“地址交換”，主要通過報文中的目標地址和端口，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器。
四層負載均衡的具體明細：
以常見的 TCP 爲例，負載均衡設備在接收到第一個來自客戶端的 SYN 請求時，即通過上述方式選擇一個最佳的服務器，並對報文中目標 IP 地址進行修改(改爲後端服務器 IP），直接轉發給該服務器。TCP 的連接建立，即三次握手是客戶端和服務器直接建立的，負載均衡設備只是起到一個類似路由器的轉發動作。在某些部署情況下，爲保證服務器回包可以正確返回給負載均衡設備，在轉發報文的同時可能還會對報文原來的源地址進行修改。
實現四層負載均衡的軟件有：
F5 ：硬件負載均衡器，功能很好，但是成本很高。
lvs ：重量級的四層負載軟件 。
nginx ：輕量級的四層負載軟件，帶緩存功能，正則表達式較靈活 。
haproxy ：模擬四層轉發，較靈活 。
七層負載均衡（內容交換）
工作原理：
所謂七層負載均衡，也稱爲“內容交換”，也就是主要通過報文中的真正有意義的應用層內容，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器。
七層負載均衡相對於四層負載均衡的優點：
七層應用負載的好處，是使得整個網絡更智能化。例如訪問一個網站的用戶流量，可以通過七層的方式，將對圖片類的請求轉發到特定的圖片服務器並可以使用緩存技術；將對文字類的請求可以轉發到特定的文字服務器並可以使用壓縮技術。
實現七層負載均衡的軟件有：
haproxy ：天生負載均衡技能，全面支持七層代理，會話保持，標記，路徑轉移；
nginx ：只在 http 協議和 mail 協議上功能比較好，性能與 haproxy 差不多；
apache ：功能較差
Mysql proxy ：功能尚可。
Question2：簡要介紹一下 負載均衡算法/ 策略？
Answer2：
1、輪循均衡（Round Robin）
每一次來自網絡的請求輪流分配給內部中的服務器，從 1 至 N 然後重新開始。此種均衡算法適合於服務器組中的所有服務器都有相同的軟硬件配置並且平均服務請求相對均衡的情況。
2、權重輪循均衡（Weighted Round Robin）
根據服務器的不同處理能力，給每個服務器分配不同的權值，使其能夠接受相應權值數的服務請求。例如：服務器 A 的權值被設計成 1，B 的權值是 3，C 的權值是 6，則服務器 A、B、C 將分別接受到 10%、30％、60％的服務請求。此種均衡算法能確保高性能的服務器得到更多的使用率，避免低性能的服務器負載過重。
3、隨機均衡（Random）
把來自網絡的請求隨機分配給內部中的多個服務器。
4、權重隨機均衡（Weighted Random）
此種均衡算法類似於權重輪循算法，不過在處理請求分擔時是個隨機選擇的過程。
5、最少連接數均衡（Least Connection）
最少連接數均衡算法對內部中需負載的每一臺服務器都有一個數據記錄，記錄當前該服務器正在處理的連接數量，當有新的服務連接請求時，將把當前請求分配給連接數最少的服務器，使均衡更加符合實際情況，負載更加均衡。此種均衡算法適合長時處理的請求服務，如 FTP。
6、處理能力均衡（CPU、內存）
此種均衡算法將把服務請求分配給內部中處理負荷（根據服務器 CPU 型號、CPU 數量、內存大小及當前連接數等換算而成）最輕的服務器，由於考慮到了內部服務器的處理能力及當前網絡運行狀況，所以此種均衡算法相對來說更加精確，尤其適合運用到第七層（應用層）負載均衡的情況下。
7、響應速度均衡（Response Time 探測時間）
負載均衡設備對內部各服務器發出一個探測請求（例如 Ping），然後根據內部中各服務器對探測請求的最快響應時間來決定哪一臺服務器來響應客戶端的服務請求。此種均衡算法能較好的反映服務器的當前運行狀態，但這最快響應時間僅僅指的是負載均衡設備與服務器間的最快響應時間，而不是客戶端與服務器間的最快響應時間。
8、DNS 響應均衡（Flash DNS）
在此均衡算法下，分處在不同地理位置的負載均衡設備收到同一個客戶端的域名解析請求，並在同一時間內把此域名解析成各自相對應服務器的 IP 地址並返回給客戶端，則客戶端將以最先收到的域名解析 IP 地址來繼續請求服務，而忽略其它的 IP 地址響應。在種均衡策略適合應用在全局負載均衡的情況下，對本地負載均衡是沒有意義的。
9、哈希算法（負載均衡系統可靠性）
一致性哈希一致性 Hash，相同參數的請求總是發到同一提供者。當某一臺提供者掛時，原本發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引起劇烈變動。
10、IP 地址散列（ 保證客戶端服務器對應關係穩定 ）
通過管理髮送方 IP 和目的地 IP 地址的散列，將來自同一發送方的分組(或發送至同一目的地的分組)統一轉發到相同服務器的算法。當客戶端有一系列業務需要處理而必須和一個服務器反覆通信時，該算法能夠以流(會話)爲單位，保證來自相同客戶端的通信能夠一直在同一服務器中進行處理。
11、URL 散列（保證URL和服務器對應關係穩定）
通過管理客戶端請求 URL 信息的散列，將發送至相同 URL 的請求轉發至同一服務器的算法。
Question3：介紹一下 LVS ？
Answer3：
LVS 英文全稱 Linux Virtual Server，即Linux虛擬服務器，其 IP 負載均衡技術是通過 IPVS 模塊（IP Virtual Server，IP虛擬服務模塊）來實現的，IPVS 是 LVS 集羣系統的核心軟件。
IPVS的主要作用：安裝在負載調度器 Director Server 上，同時在 Director Server 上虛擬出一個 IP 地址，用戶必須通過這個虛擬的 IP 地址訪問服務器（注意：這個虛擬 IP 一般稱爲 LVS 的 VIP，即 Virtual IP）。
工作流程：訪問的請求首先經過 VIP 到達負載調度器 Director Server，然後由負載調度器Director Server從 Real Server 列表中選取一個服務節點響應用戶的請求（注意：在用戶的請求到達負載調度器Director Server後，調度器Director Server如何將請求發送到提供服務的 Real Server 節點，而 Real Server 節點如何返回數據給用戶，是 IPVS 實現的重點技術）。
ipvs ： ip virtual server，是 Linux 內核的一部分，工作於內核空間，主要用於使用戶定義的策略生效。
ipvsadm : 是LVS在應用層的一個管理命令，需要使用yum單獨安裝，工作於用戶空間，主要用於用戶定義和管理LVS的配置和集羣服務。
對於上圖的解釋： ipvs 工作於內核空間的 INPUT 鏈上，當收到用戶請求某集羣服務時，經過PREROUTING 鏈（路由前），經檢查本機路由表，送往 INPUT 鏈；在進入 netfilter 的 INPUT 鏈時，ipvs 強行將請求報文通過ipvsadm 定義的集羣服務策略的路徑改爲 FORWORD 鏈（路由後），將報文轉發至後端真實提供服務的主機Real Server（即圖中的RS）。
Question4：介紹一下 LVS 四種模式(NAT、DR、TUN、FULLNAT) ？
Answer4：
1、LVS NAT 模式
①.客戶端將請求發往前端的負載均衡器，請求報文源地址是 CIP(客戶端 IP),後面統稱爲 CIP)，目標地址爲 VIP(負載均衡器前端地址，後面統稱爲 VIP)。
②.負載均衡器收到報文後，發現請求的是在規則裏面存在的地址，那麼它將客戶端請求報文的目標地址改爲了後端服務器的 RIP 地址並將報文根據算法發送出去。
③.報文送到 Real Server 後，由於報文的目標地址是自己，所以會響應該請求，並將響應報文返還給 LVS。
④.然後 lvs 將此報文的源地址修改爲本機併發送給客戶端。
注意：在 NAT 模式中，Real Server 的網關必須指向 LVS，否則報文無法送達客戶端。
LVS NAT 模式特點：
1、NAT 技術將請求的報文和響應的報文都需要通過 LB 進行地址改寫，因此網站訪問量比較大的時候 LB 負載均衡調度器有比較大的瓶頸，一般要求最多之能 10-20 臺節點。
2、只需要在 LB 上配置一個公網 IP 地址就可以了。
3、每臺內部的 realserver 服務器的網關地址必須是調度器 LB 的內網地址。
4、NAT 模式支持對 IP 地址和端口進行轉換。即用戶請求的端口和真實服務器的端口可以不一致。
LVS NAT 模式優點：
集羣中的物理服務器可以使用任何支持 TCP/IP 操作系統，只有負載均衡器需要一個合法的 IP 地址。
LVS NAT 模式缺點：
擴展性有限。當服務器節點（普通 PC 服務器）增長過多時,負載均衡器將成爲整個系統的瓶頸，因爲所有的請求包和應答包的流向都經過負載均衡器。當服務器節點過多時，大量的數據包都交匯在負載均衡器那，速度就會變慢！
2、LVS DR 模式（局域網改寫 mac 地址）
①.客戶端將請求發往前端的負載均衡器，請求報文源地址是 CIP，目標地址爲 VIP。
②.負載均衡器收到報文後，發現請求的是在規則裏面存在的地址，那麼它將客戶端請求報文的源MAC地址改爲自己DIP的MAC地址，目標MAC改爲了RIP的MAC地址，並將此包發送給RS。
③.RS 發現請求報文中的目的 MAC 是自己，就會將次報文接收下來，處理完請求報文後，將響應報文通過 lO 接口送給 eth0 網卡直接發送給客戶端。
注意：需要設置 lO 接口的 VIP 不能響應本地網絡內的 arp 請求。
LVS DR 模式特點：
1、通過在調度器 LB 上修改數據包的目的 MAC 地址實現轉發。注意源地址仍然是 CIP，目的地址仍然是 VIP 地址。
2、請求的報文經過調度器，而 RS 響應處理後的報文無需經過調度器 LB，因此併發訪問量大時使用效率很高（和 NAT 模式比）
3、因爲 DR 模式是通過 MAC 地址改寫機制實現轉發，因此所有 RS 節點和調度器 LB 只能在一個局域網裏面
4、RS 主機需要綁定 VIP 地址在 LO 接口（掩碼 32 位）上，並且需要配置 ARP 抑制。
5、RS 節點的默認網關不需要配置成 LB，而是直接配置爲上級路由的網關，能讓 RS 直接出網就可以。
6、由於 DR 模式的調度器僅做 MAC 地址的改寫，所以調度器 LB 就不能改寫目標端口，那麼 RS服務器就得使用和 VIP 相同的端口提供服務。
7、直接對外的業務比如 WEB 等，RS 的 IP 最好是使用公網 IP。對外的服務，比如數據庫等最好使用內網 IP。
LVS DR 模式優點
和 TUN（隧道模式）一樣，負載均衡器也只是分發請求，應答包通過單獨的路由方法返回給客戶端。與 VS-TUN 相比，VS-DR 這種實現方式不需要隧道結構，因此可以使用大多數操作系統做爲物理服務器。
DR 模式的效率很高，但是配置稍微複雜一點，因此對於訪問量不是特別大的公司可以用
haproxy/nginx取代。日1000-2000W PV或者併發請求1萬一下都可以考慮haproxy/nginx。
LVS DR 模式缺點
所有 RS 節點和調度器 LB 只能在一個局域網裏面。
3、LVS TUN 模式 （IP 封裝、 跨網段 ）
①.客戶端將請求發往前端的負載均衡器，請求報文源地址是 CIP，目標地址爲 VIP。
②.負載均衡器收到報文後，發現請求的是在規則裏面存在的地址，那麼它將在客戶端請求報文的首部再封裝一層 IP 報文,將源地址改爲 DIP，目標地址改爲 RIP,並將此包發送給 RS。
③.RS 收到請求報文後，會首先拆開第一層封裝,然後發現裏面還有一層 IP 首部的目標地址是自己lO 接口上的 VIP，所以會處理次請求報文，並將響應報文通過 lo 接口送給 eth0 網卡直接發送給客戶端。
注意：需要設置 lO 接口的 VIP 不能在共網上出現。
LVS TUN模式特點
1.TUNNEL 模式必須在所有的 realserver 機器上面綁定 VIP 的 IP 地址
2.TUNNEL 模式的 vip ------>realserver 的包通信通過 TUNNEL 模式，不管是內網和外網都能通信，所以不需要 lvs vip 跟 realserver 在同一個網段內。
3.TUNNEL 模式 realserver 會把 packet 直接發給 client 不會給 lvs 了。
4.TUNNEL 模式走的隧道模式，所以運維起來比較難，所以一般不用。
LVS TUN模式優點
負載均衡器只負責將請求包分發給後端節點服務器，而 RS 將應答包直接發給用戶。所以，減少了負載均衡器的大量數據流動，負載均衡器不再是系統的瓶頸，就能處理很巨大的請求量，這種方式，一臺負載均衡器能夠爲很多 RS 進行分發。而且跑在公網上就能進行不同地域的分發。
LVS TUN模式缺點
隧道模式的 RS 節點需要合法 IP，這種方式需要所有的服務器支持”IP Tunneling”(IP
Encapsulation)協議，服務器可能只侷限在部分 Linux 系統上。
4、LVS FULLNAT 模式
無論是 DR 還是 NAT 模式，不可避免的都有一個問題：LVS 和 RS 必須在同一個 VLAN 下，否則LVS 無法作爲 RS 的網關。這引發的兩個問題是：
1、同一個 VLAN 的限制導致運維不方便，跨 VLAN 的 RS 無法接入。
2、LVS 的水平擴展受到制約。當 RS 水平擴容時，總有一天其上的單點 LVS 會成爲瓶頸。
Full-NAT 由此而生，解決的是 LVS 和 RS 跨 VLAN 的問題，而跨 VLAN 問題解決後，LVS 和 RS不再存在 VLAN 上的從屬關係，可以做到多個 LVS 對應多個 RS，解決水平擴容的問題。
Full-NAT 相比 NAT 的主要改進是，在 SNAT/DNAT 的基礎上，加上另一種轉換，轉換過程如下：
- 在包從 LVS 轉到 RS 的過程中，源地址從客戶端 IP 被替換成了 LVS 的內網 IP。內網 IP 之間可以通過多個交換機跨 VLAN 通信。目標地址從 VIP 修改爲 RS IP.
- 當 RS 處理完接受到的包，處理完成後返回時，將目標地址修改爲 LVS ip，原地址修改爲 RS IP，最終將這個包返回給 LVS 的內網 IP，這一步也不受限於 VLAN。
- LVS 收到包後，在 NAT 模式修改源地址的基礎上，再把 RS 發來的包中的目標地址從 LVS 內網 IP 改爲客戶端的 IP,並將原地址修改爲 VIP。
Full-NAT 主要的思想是把網關和其下機器的通信，改爲了普通的網絡通信，從而解決了跨 VLAN的問題。採用這種方式，LVS 和 RS 的部署在 VLAN 上將不再有任何限制，大大提高了運維部署的便利性。
LVS FULLNAT 模式特點
- FULL NAT 模式不需要 LBIP 和 realserver ip 在同一個網段；
- full nat 因爲要更新 sorce ip 所以性能正常比 nat 模式下降 10%
Question5：介紹一下 Keepalive ？
Answer5：
keepalive 起初是爲 LVS 設計的，專門用來監控 lvs 各個服務節點的狀態，後來加入了vrrp 的功能，因此除了 lvs，也可以作爲其他服務（nginx，haproxy）的高可用軟件。VRRP 是 virtual router redundancy protocal（虛擬路由器冗餘協議）的縮寫。VRRP 的出現就是爲了解決靜態路由出現的單點故障，它能夠保證網絡可以不間斷的穩定的運行。所以 keepalive 一方面具有 LVS cluster node healthcheck 功能，另一方面也具有 LVS director failover。
Question6：介紹一下 Nginx反向代理是如何負載均衡的？
Answer6：
Nginx反向代理下的負載均衡
普通的負載均衡軟件，如 LVS，其實現的功能只是對請求數據包的轉發、傳遞，從負載均衡下的節:點服務器來看，接收到的請求還是來自訪問負載均衡器的客戶端的真實用戶；而反向代理就不一樣了，反向代理服務器在接收訪問用戶請求後，會代理用戶 重新發起請求代理下的節點服務器，最後把數據返回給客戶端用戶。在節點服務器看來，訪問的節點服務器的客戶端用戶就是反向代理服務器，而非真實的網站訪問用戶。
upstream_module 和健康檢測
ngx_http_upstream_module 是負載均衡模塊，可以實現網站的負載均衡功能即節點的健康檢查，upstream 模塊允許 Nginx 定義一組或多組節點服務器組，使用時可通過proxy_pass 代理方式把網站的請求發送到事先定義好的對應 Upstream 組 的名字上。
| upstream 模塊內參數 | 參數說明 |
|---|---|
| weight | 服務器權重 |
| max_fails | Nginx 嘗試連接後端主機失敗的此時，這是值是配合 proxy_next_upstream、fastcgi_next_upstream 和 memcached_next_upstream 這三個參數來使用的。當 Nginx接收後端服務器返回這三個參數定義的狀態碼時，會將這個請求轉發給正常工作的的後端服務器。如 404、503、503,max_files=1。 |
| fail_timeout | max_fails 和 fail_timeout 一般會關聯使用，如果某臺 server 在 fail_timeout 時間內出現了max_fails 次連接失敗，那麼 Nginx 會認爲其已經掛掉，從而在 fail_timeout 時間內不再去請求它，fail_timeout 默認是 10s，max_fails 默認是 1，即默認情況只要是發生錯誤就認爲服務器掛了，如果將 max_fails 設置爲 0，則表示取消這項檢查。 |
| backup | 表示當前 server 是備用服務器，只有其它非 backup 後端服務器都掛掉了或很忙纔會分配請求給它 |
| down | 標誌服務器永遠不可用，可配合 ip_hash 使用 |
upstream lvsServer{
server 191.168.1.11 weight=5 ;
server 191.168.1.22:82;
server example.com:8080 max_fails=2 fail_timeout=10s backup;
#域名的話需要解析的哦，內網記得 hosts
}
proxy_pass 請求轉發
proxy_pass 指令屬於 ngx_http_proxy_module 模塊，此模塊可以將請求轉發到另一臺服務器，在實際的反向代理工作中，會通過 location 功能匹配指定的 URI，然後把接收到服務匹配 URI 的請求通過 proyx_pass 拋給定義好的 upstream 節點池。
location /download/ {
proxy_pass http://download/vedio/;
}
#這是前端代理節點的設置
#交給後端 upstream 爲 download 的節點
| proxy 模塊參數 | 說明 |
|---|---|
| proxy_next_upstream | 什麼情況下將請求傳遞到下一個 upstream |
| proxy_limite_rate | 限制從後端服務器讀取響應的速率 |
| proyx_set_header | 設置 http 請求 header 傳給後端服務器節點，如：可實現讓代理後端的服務器節點獲取訪問客戶端的這是 ip |
| client_body_buffer_size | 客戶端請求主體緩衝區大小 |
| proxy_connect_timeout | 代理與後端節點服務器連接的超時時間 |
| proxy_send_timeout | 後端節點數據回傳的超時時間 |
| proxy_read_timeout | 設置 Nginx 從代理的後端服務器獲取信息的時間，表示連接成功建立後，Nginx 等待後端服務器的響應時間 |
| proxy_buffer_size | 設置緩衝區大小 |
| proxy_buffers | 設置緩衝區的數量和大小 |
| proyx_busy_buffers_size | 用於設置系統很忙時可以使用的 proxy_buffers 大小，推薦爲proxy_buffers*2 |
| proxy_temp_file_write_size | 指定 proxy 緩存臨時文件的大小 |
