一.負載均衡

1.1.什么是負載均衡

負載均衡：Load Balance，簡稱LB，是一種服務或基于硬件設備等實現的高可用反向代理技術，負載均

衡將特定的業務(web服務、網絡流量等)分擔給指定的一個或多個后端特定的服務器或設備，從而提高了

公司業務的并發處理能力、保證了業務的高可用性、方便了業務后期的水平動態擴展

阿里云SLB介紹 ：https://yq.aliyun.com/articles/1803

1.2.為什么用負載均衡

Web服務器的動態水平擴展-->對用戶無感知

增加業務并發訪問及處理能力-->解決單服務器瓶頸問題

節約公網IP地址-->降低IT支出成本

隱藏內部服務器IP-->提高內部服務器安全性

配置簡單-->固定格式的配置文件

功能豐富-->支持四層和七層，支持動態下線主機

性能較強-->并發數萬甚至數十萬

1.3.負載均衡類型

1.3.1硬件：

F5 美國F5網絡公司 https://f5.com/zh

Netscaler 美國思杰公司 https://www.citrix.com.cn/products/citrix-adc/、

Array 華耀 https://www.arraynetworks.com.cn/
AD-1000 深信服?深信服 - 讓每個用戶的數字化更簡單、更安全

1.3.2.四層負載均衡

1.通過ip+port決定負載均衡的去向。

2.對流量請求進行NAT處理，轉發至后臺服務器。

3.記錄tcp、udp流量分別是由哪臺服務器處理，后續該請求連接的流量都通過該服務器處理。

4.支持四層的軟件

lvs：重量級四層負載均衡器。

Nginx：輕量級四層負載均衡器，可緩存。（nginx四層是通過upstream模塊）

Haproxy：模擬四層轉發。

1.3.3.七層負載均衡

1.通過虛擬ur|或主機ip進行流量識別，根據應用層信息進行解析，決定是否需要進行負載均衡。

2.代理后臺服務器與客戶端建立連接，如nginx可代理前后端，與前端客戶端tcp連接，與后端服務器建立

tcp連接,

3.支持7層代理的軟件：

Nginx:基于http協議(nginx七層是通過proxy_pass)

Haproxy:七層代理，會話保持、標記、路徑轉移等。

1.3.4 四層和七層的區別

所謂的四到七層負載均衡，就是在對后臺的服務器進行負載均衡時，依據四層的信息或七層的信息來決定怎么樣轉發流量

四層的負載均衡，就是通過發布三層的IP地址（VIP），然后加四層的端口號，來決定哪些流量需要做負載均衡，對需要處理的流量進行NAT處理，轉發至后臺服務器，并記錄下這個TCP或者UDP的流量是由哪臺服務器處理的，后續這個連接的所有流量都同樣轉發到同一臺服務器處理

七層的負載均衡，就是在四層的基礎上（沒有四層是絕對不可能有七層的），再考慮應用層的特征，比如同一個Web服務器的負載均衡，除了根據VIP加80端口辨別是否需要處理的流量，還可根據七層的URL、瀏覽器類別、語言來決定是否要進行負載均衡。

1.分層位置:四層負載均衡在傳輸層及以下，七層負載均衡在應用層及以下

2.性能 :四層負載均衡架構無需解析報文消息內容，在網絡吞吐量與處理能力上較高:七層可支持解析應用

層報文消息內容，識別URL、Cookie、HTTP header等信息。、

3.原理 :四層負載均衡是基于ip+port;七層是基于虛擬的URL或主機IP等。

4.功能類比:四層負載均衡類似于路由器;七層類似于代理服務器。

5.安全性:四層負載均衡無法識別DDoS攻擊;七層可防御SYN Cookie/Flood攻擊

二.haproxy簡介

HAProxy是法國開發者 威利塔羅(Willy Tarreau) 在2000年使用C語言開發的一個開源軟件

是一款具備高并發(萬級以上)、高性能的TCP和HTTP負載均衡器

支持基于cookie的持久性，自動故障切換，支持正則表達式及web狀態統計

企業版網站：https://www.haproxy.com

社區版網站：http://www.haproxy.org

github：https://github.com/haprox

企業版本和社區版功能對比

三.haproxy的安裝和服務信息

3.1.實驗環境

功能 ? ? ? ? ? ? ? ? ? ?IP

Client ? ? ? ? ? ? ? ? eth0：172.,25.254.140

haproxy ? ? ? ? ? ? ? eth0：172.25.254.134

RS1 ? ? ? ? ? ? ? ? ? ? eth0：172.25.254.137

RS2 ? ? ? ? ? ? ? ? ? ? eth0：172.25.254.138

3.2.軟件安裝

軟件包下載地址

https://github.com/haproxy/wiki/wiki/Packages

安裝軟件包：

[root@haproxy ~]# dnf install haproxy -y

查看版本

[root@haproxy ~]# haproxy -v

關閉防火墻

[root@haproxy ~]# systemctl disable --now firewalld

haproxy軟件基本信息

3.3.haproxy的基本配置信息

官方文檔：http://cbonte.github.io/haproxy-dconv/

HAProxy 的配置文件haproxy.cfg由兩大部分組成，分別是：

global：全局配置段

進程及安全配置相關的參數

性能調整相關參數

Debug參數

proxies：代理配置段

defaults：為frontend, backend, listen提供默認配置

frontend：前端，相當于nginx中的server {}

backend：后端，相當于nginx中的upstream {}

listen：同時擁有前端和后端配置,配置簡單,生產推薦使用

RS1/2配置

訪問側式

環境搭建完成

1.3 線程與CPU核心綁定

原因

HAProxy默認以單線程模式運行，但現代版本支持多線程（通過nbthread參數配置）。線程綁定的核心目的和優勢包括：

性能優化：將線程綁定到特定CPU核心（通過cpu-map配置），減少上下文切換開銷，提升緩存命中率，尤其在高并發場景下顯著降低延遲。

資源隔離：避免線程在不同核心間遷移導致的性能波動，確保關鍵流量處理的穩定性。

NUMA架構適配：在多處理器NUMA系統中，綁定線程到本地內存節點可減少跨節點訪問延遲。

通過配置nbproc和cpu-map實現進程與CPU核心的綁定。

global

? ? nbthread 4 ?# 啟用4個工作線程

? ? cpu-map 1 0 ?# 線程1綁定到CPU核心0

? ? cpu-map 2 1 ?# 線程2綁定到CPU核心1

? ? cpu-map 3 2 ?# 線程3綁定到CPU核心2

cpu-map 4 3 ?# 線程4綁定到CPU核心3

綁定后減少線程跨核心切換的開銷，提升處理效率，適用于高并發場景

#添加多線程

1.vim /etc/haproxy/haproxy.cfg

2.修改完重啟文件件?systemctl restart haproxy

進程會在下面多n個

2.通過文件配置具體內容

2.1前端（Frontend）監聽

Haproxy配置前端監聽特定端口（如80或443），接收客戶端請求。前端定義訪問控制、SSL證書等參數

每次修改完文件后都要重啟服務systemctl restart haproxy

負載均衡算法的具體配置

靜態負載均衡算法

采用“慢更新”策略：先給一點點訪問壓力，當沒問題后在給一部分

服務器加入時逐步增加負載，但權重固定不可動態調整。

適用場景：服務器性能差異小且負載穩定。

缺點：靈活性低，無法適應突發流量或服務器性能變化。

動態負載均衡算法

roundrobin（輪詢）

根據權重比例分配請求，結合實時LVS負載計算最優目標服務器，誰的值小就給誰

• 支持動態權重調整（無需重啟）。
• 適用場景：服務器性能差異大或負載波動頻繁。

文件配置：

先將這部分全部注釋掉

然后添加?roundrobin（輪詢）配置

測試訪問是否是輪詢、

leastconn（最小連接數）

優先分配請求給當前連接數最少的服務器，權重高的服務器在連接數相近時優先。

支持動態權重調整。

適用場景：長連接服務（如數據庫）。

重啟之后訪問測試

第二種修改權重的方法：

source（源地址哈希）

根據客戶端IP哈希固定分配請求到同一服務器。

優點：會話保持。

缺點：服務器故障時影響所有關聯客戶端。

重啟，訪問

發現鏈接只打在一臺主機上

map-base（取模）

總結：對主機標識取模分配請求，服務器故障需全局重新計算。

主機有數字，該數字除以服務器的個數然后取余，余數跟對應的服務器建立鏈接，掛了一臺服務器算法就得重新計算鏈接

如果有一臺主機（服務器）掛科了，所有主機都要重新建立VIP

適用場景：服務器數量固定且故障率低。

這個可以和其他算法共存

一致性hash

一致性哈希，當服務器的總權重發生變化時，對調度結果影響是局部的，不會引起大的變動hash（o） mod n

該hash算法是動態的，支持使用 socat等工具進行在線權重調整，支持慢啟動

算法：

1、后端服務器哈希環點keyA=hash(后端服務器虛擬ip)%(2^32)

2、客戶機哈希環點key1=hash(client_ip)%(2^32) 得到的值在[0---4294967295]之間

3、將keyA和key1都放在hash環上，將用戶請求調度到離key1最近的keyA對應的后端服務器

hash環偏斜問題

增加虛擬服務器IP數量，比如：一個后端服務器根據權重為1生成1000個虛擬IP，再hash。而后端服務器權 重為2則生成2000的虛擬IP，再bash,最終在hash環上生成3000個節點，從而解決hash環偏斜問題

hash對象

Hash對象到后端服務器的映射關系：

一致性hash示意圖

后端服務器在線與離線的調度方式

URI哈希

基于請求URI哈希分配，相同URI指向同一服務器。

僅支持HTTP模式（mode http）。

適用場景：靜態資源緩存優化。

此時可以通過VIP訪問兩個服務器對應的index

url_param（URL參數哈希）

根據指定URL參數（如user_id）哈希分配請求。

適用場景：需按業務參數保持會話一致性。

重啟服務

訪問出現的都是同一個

hdr(User-Agent)（用戶代理哈希）

根據請求頭中的User-Agent分配請求。

適用場景：針對不同客戶端類型差異化處理。

現在我們訪問的都是同一個頁面

指定瀏覽器，就可以保證訪問該瀏覽器時出現固定的頁面

Cookie會話保持

通過cookie或stick-table實現會話粘滯，確保用戶請求始終指向同一后端服務器。

適用場景：登錄態等強會話依賴服務。

backend web_backend

? balance roundrobin

? cookie SERVERID insert nocache

? server server1 192.168.1.10:80 cookie s1 check

? server server2 192.168.1.11:80 cookie s2 check

bash

動態權重調整

# 動態修改服務器權重（需啟用stats socket）

echo "set server backend/server1 weight 50" | sudo socat stdio /var/run/haproxy.sock

動態配置與ACL規則

使用ACL（訪問控制列表）實現高級路由，例如按路徑、域名或Header分流。

frontend web_front

? bind *:80

? acl path_blog path_beg /blog

? use_backend blog_backend if path_blog

? default_backend web_backend

以上算法可根據實際業務需求組合使用，例如：

電商場景：source + Cookie保證會話一致性。

CDN加速：URI哈希提升緩存命中率。
?