第一次接觸 HAProxy 的時候大多數人都是被那堆配置項勸退的。老實說作為 Linux 下應用最廣的開源負載均衡器之一HAProxy 的配置文件反而沒那么玄乎——它核心就五段global、defaults、frontend、backend、listen。搞懂它們分別管什么再把幾個高頻參數吃透基本就能應對大部分場景了。這篇文章不聊那些花活只講 haproxy 基礎配置、配置文件結構和幾個最簡單實用的功能適合剛上手或者用了一段時間但一直靠復制粘貼的朋友。先說清楚 HAProxy 能干什么。它本質上是一個基于 TCP 和 HTTP 的高性能反向代理最常干的活就是負載均衡把用戶的請求按照某種策略分發(fā)到后面一組真實服務器上同時還要負責健康檢查——某臺后端掛了自動把流量摘掉等它恢復后再加回來。很多團隊也拿它做流量入口的統(tǒng)一收斂點順帶完成簡單的請求路由、訪問控制、監(jiān)控統(tǒng)計。它的特點就一個字穩(wěn)純 C 寫的單進程事件驅動在普通 x86 服務器上扛住幾萬并發(fā)并不稀奇配置正確的情況下跑幾年不重啟也沒問題。這篇文章我會用一套完整的 Web 負載均衡配置作為主線把 global、defaults、frontend、backend 四段逐行講清楚再用 listen 段演示一個最簡單的 TCP 轉發(fā)最后把平時最容易踩的坑列出來。下文中所有配置均基于 HAProxy 2.4 及更新版本較老版本個別參數略有差異但主體框架完全一致老版本用戶在用到具體參數時留意一下版本差異即可。1. HAProxy 配置文件的整體框架與定位1.1 為什么 HAProxy 的配置文件要分成五段理解 HAProxy 的配置最關鍵的一步是理解它的設計哲學接收端和轉發(fā)端分開描述。Nginx 里你經常在一個 location 或 server 塊里既寫監(jiān)聽的端口又寫轉發(fā)的目標但 HAProxy 偏不這么干它把“怎么接流量”和“往哪兒轉發(fā)”拆成兩個獨立對象也就是 frontend 和 backend。這樣的拆分有兩個顯而易見的好處。第一多個 frontend 可以共用同一個 backend。比如你有一個 80 端口的 HTTP 入口和一個 443 端口的 HTTPS 入口兩個入口收到的流量都可以轉發(fā)到同一組 Web 服務器上只在 frontend 這塊分別定義各自的監(jiān)聽方式后端邏輯完全復用。第二一個 frontend 也可以根據 ACL 規(guī)則路由到不同的 backend。比如同一個入口進來的流量路徑帶 /api/ 的轉發(fā)到接口服務集群其余走靜態(tài)頁面集群這只需要在 frontend 里加幾條規(guī)則不用動后端定義。listen 段則是把 frontend 和 backend 合并在一起寫的老式風格適合簡單場景一個端口進來直接轉到一個后端池沒有復雜的路由需求。它寫起來確實省事但一旦場景變復雜——比如多個不同端口、多個目標組——用 listen 會導致配置迅速膨脹且難以閱讀。我的建議是學習階段兩種都要會看新項目一律用 frontend/backend 分離式寫法。還有兩個特殊的段global 和 defaults。global 是進程級配置管的是 HAProxy 自身的行為比如運行身份、最大連接數、日志怎么發(fā)defaults 則是給后面所有 frontend/backend/listen 提供默認值的“模板段”里面寫的參數會被繼承后面的段如果重復定義同名參數就覆蓋它。理解繼承關系很重要這也是很多新手排查配置的盲區(qū)——你明明沒在 backend 里寫某項配置但它就是從 defaults 里繼承來的。1.2 五大配置段的職責邊界與繼承關系把五大段的職責邊界理清楚配置文件就看懂了一半配置段核心職責典型參數示例global進程運行級別非事務性daemon, user, group, maxconn, logdefaults提供全局默認參數供各段繼承mode, timeout, option, retriesfrontend流量入口定義監(jiān)聽端口與路由規(guī)則bind, use_backend, default_backendbackend后端服務器池定義轉發(fā)目標與策略server, balance, check, cookielisten入口后端合并定義適用簡單場景bind, server, mode, balance注意 global 段是特殊的它不受 defaults 的繼承機制影響因為它壓根就不是一個“流量處理單元”它是一個獨立進程的描述。defaults 的繼承對象是 frontend、backend、listen 這三個段。比如你在 defaults 里寫了timeout connect 5s那么后面所有的段即使自己不寫 timeout也會自動帶上這個值。如果你在某個 backend 里改了timeout connect 10s那只有這個 backend 用新值其他段仍然用 defaults 里的 5s。這段繼承邏輯實操中非常有用是配置精簡的核心。一個規(guī)范的單機配置文件通常就是 global 段十幾行 defaults 段十行左右 每個業(yè)務一個 frontend 一個 backend加起來四五十行就夠跑一個像樣的負載均衡了。不要刻意寫長HAProxy 配置的價值不在行數而在每個參數是不是真正合理。需要提醒的是defaults 里盡量只放真正的“通用默認項”別把業(yè)務相關的參數塞進去。比如有的人在 defaults 里寫balance leastconn結果后面所有不同業(yè)務的 backend 都默認用了這個算法但有的業(yè)務其實適合 roundrobin就容易出現流量分不均勻的怪現象。defaults 是兜底不是萬能池。2. 核心配置參數詳解從進程參數到 HTTP 功能搞清結構之后接下來就要鉆進細節(jié)里。HAProxy 的配置參數很多但基礎階段真正高頻使用的其實就那一二十個。我按使用場景把它們分成了四組每組都有實際意義和踩坑點逐組講透。2.1 global 段進程級參數與運行性能調優(yōu)global 段的參數不算多但每一個都影響運行方式。最常用的幾個如下global log 127.0.0.1:514 local0 info chroot /var/lib/haproxy pidfile /var/run/haproxy.pid maxconn 80000 user haproxy group haproxy daemon stats socket /var/lib/haproxy/stats mode 600 level admin逐行解釋一下關鍵項。log指定日志發(fā)送地址和 facility。這里寫的127.0.0.1:514 local0 info表示把日志通過 UDP 發(fā)給本機的 rsyslog 端口facility 用 local0日志級別 info。實操中很多人忽略這行導致出問題時啥都查不到。我強烈建議一開始就配上哪怕沒有獨立日志服務器發(fā)到本機 rsyslog 也足夠用了。日志是排查問題的第一手資料沒有日志的負載均衡等于盲人摸象。maxconn單進程最大連接數。這是一個在性能和資源之間取平衡的值不要盲目調大。它受限于文件描述符上限Linux 下單個進程默認 fd 上限通常是 1024你需要先在系統(tǒng)層面調大ulimit -n否則配置再大也只是個擺設。一個粗略的計算公式是maxconn × 每個連接約消耗 20~40KB 內存 若干 fd。如果機器內存是 16G按 40KB 一個連接算maxconn 設到 30 萬左右理論上可以但實際還要留出系統(tǒng)和其他進程的余量所以我一般建議按可用內存 / 64KB的 60%~70% 來估算寧可保守一點。daemon讓 HAProxy 以后臺 daemon 方式運行這是生產環(huán)境的標準姿勢。沒有這行的話HAProxy 會在前臺運行終端一關就退出了。調試的時候你反而可以臨時去掉 daemon 用前臺模式跑方便直接看輸出但正式部署一定要加回來。stats socket這個別小看。它暴露了一個 Unix socket讓運維員可以在本機執(zhí)行echo show info; show stat | socat stdio /var/lib/haproxy/stats這種命令直接查詢運行數據。配合level admin還可以在線啟用/停用服務器、調整權重是免重啟運維的核心入口。生產環(huán)境我強烈建議配置這個后面排查和做操作都會爽很多。chroot和user/group是安全相關項分別把進程困在指定目錄里和降權運行?；A的配置階段照抄即可但要注意 chroot 的目錄必須存在且 HAProxy 用戶有權限訪問否則啟動會直接報錯。2.2 defaults 段時間參數與通用選項的合理預設defaults 段是配置文件的“聯合作戰(zhàn)地圖”模版。我常用的基礎配置如下defaults mode http log global option httplog option dontlognull option http-server-close option forwardfor except 127.0.0.0/8 option redispatch retries 3 timeout http-request 10s timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout http-keep-alive 10s timeout check 10s maxconn 5000挑重點講。mode http表示默認以七層 HTTP 模式工作HAProxy 會解析請求報文可以做 URI 級的轉發(fā)、ACL、cookie 保持等功能。如果你的場景是純 TCP 轉發(fā)比如數據庫、Redis就要在對應的 frontend/backend 里改成mode tcp。注意 mode 是可以按段覆蓋的defaults 里寫 http某個 listen 段里寫 tcp 是合法的。option httplog開啟 HTTP 請求日志它會記錄請求方法、URI、狀態(tài)碼、響應字節(jié)數、耗時等信息。沒有這個選項日志里就只有 TCP 層的信息排查業(yè)務問題幾乎沒法用。option dontlognull用于過濾掉那些沒有產生任何數據的空連接——很多端口掃描或監(jiān)控探測會產生這種連接不打日志能省不少磁盤。option forwardfor是給后端的真實 IP 傳遞用的。HAProxy 作為代理時后端服務器看到的所有請求來源都是 HAProxy 自身的 IP這會導致后端拿不到客戶端的真實地址。開了這個選項后HAProxy 會往請求頭里追加X-Forwarded-For字段后端用這個字段還原客戶端 IP。做日志分析、限流、黑白名單都靠它。except 127.0.0.0/8的意思是本機發(fā)來的請求不加這個頭防止某些內部應用來源信息被錯誤改寫。option redispatch在高可用場景比較重要。當某個后端服務器因為資源耗盡等原因導致會話無法完成時HAProxy 可以把這個請求重新調度到其他健康的服務器上避免用戶一直卡在故障機上。代價是某些依賴會話一致性的應用未做會話共享的可能會出現狀態(tài)錯亂所以要不要開需要結合業(yè)務判斷但對大部分無狀態(tài) Web 服務來說是值得開的。timeout 系列是 defaults 里的重頭戲也是新手最容易牽連踩坑的地方。行為邏輯timeout connect與后端服務器建立 TCP 連接的超時時間。這個值不要設太大因為正常的局域網連接都在幾十毫秒內完成設 10s 已經非常保守了。如果后端網絡質量差建議排查鏈路而不是盲目調大這個值。timeout client客戶端與 HAProxy 之間的空閑超時時間。注意這說的是“空閑連接”的超時——也就是客戶端發(fā)送完請求后長時間沒有再發(fā)送下一個請求或讀取響應時HAProxy 會斷開連接。設太短會導致長輪詢、WebSocket 等連接被意外斷開設太長又容易積壓一堆半死不活的連接。timeout server與后端服務器之間的空閑超時時間。含義和 client 對應但作用于 HAProxy 到后端那一段。如果后端程序處理請求特別慢比如某些報表類的同步接口要跑幾十秒這個值就需要相應調大否則請求剛算好結果就被掐斷了。timeout http-request接收完整 HTTP 請求頭的超時時間。這個值建議設小一點因為它主要用來防慢速攻擊——惡意客戶端一點一點地發(fā)請求頭把連接拖死。10s 已經夠寬裕正常用戶不會花超過幾秒鐘填一個請求頭。timeout http-keep-aliveHTTP 長連接的空閑超時時間?？蛻舳擞?keep-alive 維持連接、準備發(fā)下一個請求時空閑超過這個值就會被斷開。有個容易誤會的點timeout client和timeout server設的是“空閑超時”不是硬性的最長請求時間。比如 timeout server 1m不是說后端處理請求超過 1 分鐘就會被殺而是說后端和 HAProxy 之間如果超過 1 分鐘沒有任何數據交互這個連接就會被回收。理解這個區(qū)別很重要否則你會在一堆長耗時請求的場景下糾結為什么明明設了很大的值還是斷連。2.3 frontend 段流量入口與基礎路由規(guī)則frontend 的職責是“接住流量”所以配置的核心是監(jiān)聽地址和路由決策?？匆粋€最簡單的 HTTP 入口frontend web_front bind 0.0.0.0:80 mode http default_backend web_serversbind 0.0.0.0:80表示監(jiān)聽本機所有網卡的 80 端口。如果你只希望內網網卡接收流量可以寫成bind 192.168.1.10:80這樣外網網卡即使到達了也不會進這個 frontend等于從入口做了隔離。default_backend是兜底路由前面的請求如果沒匹配到任何別的規(guī)則就統(tǒng)一走這個后端池。實際生產中使用 HTTP 入口一般會加一些簡單的 ACL 路由比如根據路徑區(qū)分 API 請求和靜態(tài)資源frontend web_front bind 0.0.0.0:80 mode http acl api_path path_beg /api/ use_backend api_servers if api_path default_backend web_servers這里acl定義了一個名為 api_path 的規(guī)則條件是請求路徑以 /api/ 開頭。use_backend根據 ACL 規(guī)則選擇對應后端池不滿足就落到 default_backend。這個模式在微服務網關和前后端分離架構里非常常見基本可以覆蓋大多數路由需求?；A階段掌握bind、acl、use_backend、default_backend就夠了。ACL 的匹配字段很多域名、URL、Headers、來源 IP、HTTP 方法等后面有需要再看具體字段的語法這里先不做擴展。另外frontend 的名字是可以隨便起的比如 web_front、api_front但同一個文件里不能重復。名字起得規(guī)范一些多人協作時能把閱讀成本降很多。2.4 backend 段后端服務器池、權重與健康檢查backend 是真正干活的段——定義一組服務器以及負載均衡策略。基礎模板如下backend web_servers balance roundrobin option httpchk GET /health http-check expect status 200 server web1 10.0.0.11:8080 weight 100 check inter 3s fall 3 rise 2 server web2 10.0.0.12:8080 weight 100 check inter 3s fall 3 rise 2 server web3 10.0.0.13:8080 backup check inter 3s fall 3 rise 2balance roundrobin是最常用也最好理解的負載均衡算法——按順序輪流把請求分配給后端服務器。它適合后端性能大致相同的場景。如果后端機器性能差異大可以用balance leastconn新建連接時優(yōu)先分給當前活躍連接數最少的服務器適合長連接和請求處理時間不穩(wěn)定的場景。還有一個常用的balance source它會根據客戶端 IP 做哈希同一個 IP 的請求總是落到同一個后端——對會話保持要求高又沒有共享 session 的老系統(tǒng)比較友好。三個算法的適用場景我整理了一張表算法核心邏輯適用場景注意點roundrobin輪流分發(fā)后端性能近似、連接多為短連接最通用無腦首選leastconn挑選活躍連接數最少者請求耗時差異大、長連接較多需要配合健康檢查使用source按客戶端 IP 哈希需要 IP 級別的會話粘滯后端增刪節(jié)點會導致哈希漂移weight表示權重范圍 1~256默認 1。比如一臺新機器剛上線可以先給個較小權重觀察表現穩(wěn)定后再調正常。注意動態(tài)調整權重有兩種方式一種改配置 reload一種通過前面的 stats socket 執(zhí)行set weight web_servers/web1 50在線調整。后者對線上流量無感是非常實用的運維技巧。check參數是健康檢查的開關。沒有這個參數HAProxy 會把請求送到一個已經宕機的服務器上然后超時報錯。加上check后HAProxy 會按照inter 3s的間隔、每 3 秒對后端做一次健康探測。fall 3表示連續(xù) 3 次探測失敗就把節(jié)點標記為 DOWNrise 2表示連續(xù) 2 次成功后重新標記為 UP。這兩個值要按業(yè)務敏感度調后端重啟速度快的可以設小一點減少流量的空閑時間后端啟動慢比如 Java 應用冷啟動需要幾十秒的rise 就要設大一點防止剛起來還沒就緒就被塞流量。option httpchk GET /health配合http-check expect status 200把健康檢查從簡單的 TCP 端口探測升級成 HTTP 級別的探測。這非常關鍵——一個后端進程可能在正常運行但業(yè)務邏輯已經無法響應了比如數據庫連不上、內部線程池耗盡純 TCP 探測根本發(fā)現不了只有 HTTP 探測能真實反映業(yè)務健康度。幾乎所有面向用戶的 Web 服務都應該在后端應用里實現一個返回 200 狀態(tài)的 /health 接口然后在這里配置對應的健康檢查。沒有健康檢查的負載均衡等于把命運交給了運氣。還有一個backup參數值得了解加上后這臺服務器只在其他非 backup 節(jié)點都不可用時才接收流量。這是一種冷備策略。注意 backup 節(jié)點平時不接流量健康檢查照常執(zhí)行一旦切換到它它會默默抗住所有流量所以要對它的處理能力有清晰認知。別把它當普通節(jié)點用。3. 從零搭建一個 HTTP 負載均衡的完整配置配置文件每個段都過了基礎的關現在把它們拼起來完整走一遍實操流程。假設場景你有三臺后端 Web 服務器IP 分別是 10.0.0.11、10.0.0.12、10.0.0.13端口都是 8080它們對外提供相同的 HTTP 服務?，F在要在前臺的一臺 2C4G 的 Linux 服務器上部署 HAProxy監(jiān)聽 80 端口實現負載均衡、健康檢查、監(jiān)控頁面這三個基礎功能。3.1 環(huán)境準備安裝與目錄規(guī)范先裝 HAProxy。Debian/Ubuntu 系列直接用系統(tǒng) apt 源安裝apt install -y haproxyCentOS/RHEL 系列yum install -y haproxy系統(tǒng)包管理安裝的版本不一定是最新的但勝在穩(wěn)定和干凈適合不折騰的生產環(huán)境。安裝完成后配置文件默認在/etc/haproxy/haproxy.cfgHAProxy 進程以 haproxy 用戶運行。安裝后先驗證一下版本不同主版本的參數兼容性有差異haproxy -v看到輸出后記下版本號后面查閱文檔時用的都是對應版本的行為。我下面展示的配置兼容 1.8 到 2.x 的范圍內常用的參數但如果你用的是 3.x 新版?zhèn)€別寫法要參照官方文檔調整。另外一個容易被忽略的目錄管理建議把/etc/haproxy下的配置做成haproxy.cfg主文件加多個獨立片段文件的方式主文件里用include /etc/haproxy/conf.d/*.cfg引入。這樣每個業(yè)務模塊一個文件互不干擾后續(xù)維護時找一個業(yè)務改一個文件不會在巨型單文件里反復翻找。3.2 完整配置逐行注釋版下面就是整合后的完整配置。這個配置我直接在生產環(huán)境里驗證過重點參數都有注釋global log 127.0.0.1:514 local0 info maxconn 20000 user haproxy group haproxy daemon stats socket /var/lib/haproxy/stats mode 600 level admin defaults mode http log global option httplog option dontlognull option forwardfor except 127.0.0.0/8 option redispatch retries 3 timeout http-request 10s timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout http-keep-alive 10s timeout check 10s frontend web_front bind 0.0.0.0:80 default_backend web_servers # 可選啟用完整統(tǒng)計頁面 stats enable stats uri /haproxy-stats stats realm HAProxy\ Statistics stats auth admin:YourStrongPass stats refresh 30s stats admin if LOCALHOST backend web_servers balance roundrobin option httpchk GET /health http-check expect status 200 server web1 10.0.0.11:8080 weight 100 check inter 3s fall 3 rise 2 server web2 10.0.0.12:8080 weight 100 check inter 3s fall 3 rise 2 server web3 10.0.0.13:8080 backup check inter 3s fall 3 rise 2一段一段說。global 里maxconn 20000這是一臺 2C4G 服務器比較合理的估算值。硬要算的話按每個連接約 30KB 內存值20000 個連接最多占用約 600MB 內存加上進程本身和系統(tǒng)開銷4G 內存夠用。實際情況是 Web 短連接場景下同時到達 2 萬的連接數已經是很大的并發(fā)量了初期的服務完全不需要設更高。defaults 里的參數在上面已經全部解釋過不再重復。注意這臺前臺的 80 端口壓力不會太大所以 timeout 系列我都給了比較中庸的值如果想調優(yōu)再根據業(yè)務特征微調。frontend 段增加了一個統(tǒng)計功能。stats enable開啟頁面stats uri /haproxy-stats指定訪問路徑stats auth指定訪問用戶名和密碼stats refresh 30s表示頁面每 30 秒自動刷新。訪問http://前臺IP/haproxy-stats就能看到各后端的實時狀態(tài)包括當前連接數、會話總數、健康狀態(tài)等。這是個非常實用的運維頁面哪怕不做監(jiān)控系統(tǒng)集成手動看一眼也比猜強得多。stats admin if LOCALHOST限制只有本機訪問時才允許通過頁面修改后端狀態(tài)防止生產環(huán)境被人惡意操作。這里有個細節(jié)要提醒stats uri的路徑不要和業(yè)務路徑沖突。如果業(yè)務里剛好有/haproxy-stats這個路徑那就會被統(tǒng)計頁“劫持”。所以在規(guī)劃路徑時建議選一個業(yè)務永遠不會用到的路徑或者直接在文件名上加個隨機字符串前綴。backend 的三臺服務器中web1、web2 是正常節(jié)點web3 是 backup 冷備。健康檢查用的是GET /health后端應用需要實現這個接口正常時返回 200異常時返回非 200 狀態(tài)碼HAProxy 就會把節(jié)點自動摘除。3.3 配置校驗、啟動與常見啟動問題配置寫完后先做語法校驗再啟動。這個習慣極其重要不要跳過haproxy -c -f /etc/haproxy/haproxy.cfg-c表示僅檢查配置輸出提示說明配置有效Configuration file is valid如果配置里有錯誤它會明確打印出錯的參數和行號。這個校驗操作是零成本的幾秒鐘的事卻能把大量奇葩問題攔在重啟之前。校驗通過后有兩種啟動方式。用 systemd 管理systemctl restart haproxy systemctl status haproxy另一種方式是直接以前臺模式跑一下做快速驗證尤其是排查啟動時的問題非常方便haproxy -f /etc/haproxy/haproxy.cfg前臺運行的好處是日志直接打到終端啟動報錯一目了然。確認沒問題再CtrlC停掉改用 systemd 正式啟動。啟動后立刻做三件事第一驗證端口監(jiān)聽。ss -lntp | grep :80確認 80 端口已被 HAProxy 監(jiān)聽。第二驗證負載均衡。從本機用 curl 連續(xù)請求幾次后端接口觀察統(tǒng)計頁面的各節(jié)點請求數是否大致均勻增長。如果全跑到一臺機器上八成是算法配置有誤或健康檢查把大部分節(jié)點標 DOWN 了要看統(tǒng)計頁確認。第三驗證健康檢查。停掉其中一臺后端的 Web 服務等待約 10 秒覆蓋 inter 3s × fall 3 的周期再到 HAProxy 統(tǒng)計頁上看該節(jié)點應該已經變成紅色 DOWN 狀態(tài)。此時繼續(xù)發(fā)起請求流量只分布在剩余健康節(jié)點上。重啟這臺后端服務后等待 rise 2 × inter 3s 周期節(jié)點恢復 UP流量自動重新分布。這個驗證過程建議每次變更配置后都做一遍防止配置在“看起來正常”的狀態(tài)下對故障毫無反應。4. 用 listen 段實現一個最簡單的 TCP 轉發(fā)前面講的都是 HTTP 層面的負載均衡但 HAProxy 最初的優(yōu)勢其實在于 TCP 層的四層轉發(fā)能力。它的性能天花板很高很多團隊用它來轉發(fā) MySQL、Redis、各種自研 TCP 協議流量效果同樣出色。4.1 listen 段寫法和適用場景當場景非常簡單——一個端口進、一個端口出、不需要復雜的路由判斷——listen 段是最低成本的方案。看一個經典例子把本機的 3306 端口流量轉發(fā)到兩臺數據庫服務器上實現 MySQL 的讀寫分離或高可用入口這里以讀流量均衡為例listen mysql_front bind 0.0.0.0:3306 mode tcp balance roundrobin option tcplog server db1 10.0.0.21:3306 weight 100 check inter 5s fall 3 rise 2 server db2 10.0.0.22:3306 weight 100 check inter 5s fall 3 rise 2兩行的體量就完成了一個四層 TCP 負載均衡。mode tcp告訴 HAProxy 不要解析上層協議直接把 TCP 流量按字節(jié)流透傳開銷極小。這里option tcplog替代了 HTTP 場景的 httplog記錄 TCP 層的連接信息。listen 段的寫法在結構上的角色是 frontend 和 backend 的合體bind 定義入口server 定義目標池平衡策略直接寫在同一個塊里。適用場景就是入口和目標都唯一的簡單轉發(fā)如果你的場景里有多個不同入口要轉到不同目標還是用 frontend/backend 分離結構更清晰。4.2 tcp 模式下的健康檢查細節(jié)TCP 模式的健康檢查默認是純 TCP 連接探測HAProxy 去嘗試連一下后端的 IP:端口能連上就算健康。對 MySQL 來說這個探測方式夠用——如果能建立 TCP 連接通常意味著 mysqld 進程在監(jiān)聽端口但如果 MySQL 服務還在但業(yè)務層面已經卡死純 TCP 探測就會誤判為健康。進階做法是用更精確的業(yè)務級探測。比如 MySQL 場景可以配置option mysql-check user haproxy_check它會用指定的 MySQL 賬號連接一次后端用真實的認證流程做健康檢查這比 TCP 端口探測可靠得多。類似的還有 Redis 的option redis-check、PostgreSQL 的option pgsql-check。各數據庫場景的健康檢查做對了之后故障切換的準確率會提升一個量級。另外注意 TCP 模式下沒有option forwardfor這類 HTTP 頭操作后端的客戶端 IP 獲取方式不能在 HAProxy 層解決只能在業(yè)務應用層自行記錄對端地址此時對端地址就是 HAProxy 的 IP無法直接還原真實客戶端 IP。如果你的業(yè)務必須拿到真實客戶端 IP建議改用 proxy protocol這個是另一個進階話題基礎階段先了解有這個解決路徑即可。5. 常見問題與排查技巧實錄HAProxy 本身運行極穩(wěn)定真正的故障大多來自配置不當或周邊環(huán)境。下面這些問題是我實操中遇到頻率最高的每一個都有具體的現象和排查路徑。5.1 配置正確但啟動失敗端口權限與語法錯誤“配置文件明明校驗過了怎么啟動還是失敗”這是我被問過最多的問題之一。校驗通過只能說明語法沒有基本錯誤很多運行時問題需要啟動才會暴露。最常見的是非 root 用戶綁定 80 或 443 端口失敗。Linux 約定 1024 以下的端口只有 root 才能綁定HAProxy 默認以 haproxy 用戶運行如果 bind 了 80 端口又沒有配置特權啟動會提示Permission denied。解決辦法有幾種最常見的是保持 bind :80 寫法然后讓 HAProxy 以 root 身份啟動后切換到 haproxy 用戶global 里的 user/group 配置會在綁定完端口后才生效也可以加setcap cap_net_bind_serviceep /usr/sbin/haproxy給可執(zhí)行文件單獨授權但這在部分系統(tǒng)上需要額外配置。最簡單穩(wěn)妥的方式是讓 HAProxy 先以 root 啟動綁定端口后再切換到低權限用戶這也是全局配置里推薦的標準姿勢。另一個坑是配置文件里殘留了 Windows 換行符\r\n。把文件從 Windows 機器上編輯后傳到服務器上HAProxy 解析到行尾的\r就會報格式錯誤或參數異常。解決方式是用sed -i s/\r$// /etc/haproxy/haproxy.cfg清洗一遍再校驗。還有一個隱蔽的坑include引入的片段文件里如果定義了重名的 frontend 或 backend 名字啟動時會直接報duplicate name。這種問題在多人協作時尤其容易踩建議每個業(yè)務的配置文件頂部都寫清楚業(yè)務名和占用端口做一層清單登記從根源上避免撞名。5.2 能啟動但轉發(fā)不正常健康檢查引發(fā)的“靜默故障”很多“奇怪”的轉發(fā)問題本質上都是健康檢查沒配好。最典型的場景HAProxy 啟動了端口也監(jiān)聽了但請求梭到后端全部 503 或 504。查統(tǒng)計頁往往能看到節(jié)點狀態(tài)是 DOWN。排查思路分三步。第一步確認后端的 /health 接口是否真的返回 200。有的應用把健康檢查路徑寫錯了比如后端實際是/actuator/health配置里卻寫成/health返回 404HAProxy 根據http-check expect status 200判斷為不健康節(jié)點被摘除流量自然全掛。第二步確認 HAProxy 到后端的網絡是否通。用telnet 10.0.0.11 8080手動測試。第三步確認健康檢查超時時間是否合理。timeout check如果設得太短比如 1s而健康檢查接口本身響應較慢例如要查數據庫狀態(tài)需要 2s那每次探測都超時節(jié)點會反復抖動在 UP/DOWN 之間流量時通時斷。這種抖動比完全 DOWN 更折磨人因為它表現成偶發(fā)的 502非常難定位。我自己調試這類問題最常用的伎倆是開日志看。把 rsyslog 配好然后請求幾次出問題的接口去 /var/log/haproxy.log 里看那一行日志的狀態(tài)碼和耗時基本能判斷出問題出在 HAProxy 本身還是后端。日志里如果顯示后端返回 503問題大概率在后端如果顯示連接超時問題大概率在 HAProxy 到后端這條鏈路上。5.3 流量分布不均算法選擇與節(jié)點狀態(tài)排查流量分布不均是另一個高頻問題。你配置了 roundrobin但統(tǒng)計頁上每個節(jié)點的流量卻有明顯的傾斜甚至全跑在同一臺上。第一件要查的事那臺“偏瘦”的節(jié)點是不是處于 DOWN 或 MAINT 狀態(tài)。MAINT 表示節(jié)點被管理員手動停用或正在維護它不會接任何流量觀察這個狀態(tài)首先要看是不是有人通過 stats 頁面或 socket 執(zhí)行了 disable。第二件要查的事后端節(jié)點是否真的在 CHECK 狀態(tài)。如果配置里漏寫了check參數HAProxy 默認不會對這個節(jié)點做健康檢查但這反而會讓流量正常發(fā)過去——除非這臺機器本身都已經宕機了。如果一臺節(jié)點已經掛了但沒有配 checkHAProxy 還是會固執(zhí)地把流量往它上面發(fā)表現就是一部分請求超時、一部分成功。第三件事才是回顧算法本身。roundrobin 在連接數少時表現可能顯得“不均勻”——它按請求輪轉但如果客戶端使用了 keep-alive連接超時前會連續(xù)復用同一個后端連接長時間看統(tǒng)計頁就發(fā)現某些節(jié)點連接數特別多。這不是配置錯誤而是連接復用的正?，F象。如果你希望更均勻可以把模式改成leastconn或者減小timeout http-keep-alive強制更頻繁地建立新連接。5.4 連接頻繁斷開或超時timeout 參數的全鏈路思維和 timeout 相關的問題排查時一定要有“全鏈路”視角。一次完整請求經過的鏈路是客戶端 ? HAProxy ? 后端。任何一個環(huán)節(jié)的空閑超時都可能掐斷連接但表現往往都集中在前后端兩側的服務端日志里很難直接看清。舉例說明某業(yè)務是前端頁面定期向后端輪詢數據間隔 20 秒。如果timeout client設成 10s那么頁面發(fā)起下一次輪詢時客戶端發(fā)現之前的空閑連接早被 HAProxy 回收了于是重新走 TCP 握手建立新連接。這個現象本身不是錯誤但會讓網絡連接數量持續(xù)增高。如果后端的應用框架比較陳舊頻繁重連時會積累 TIME_WAIT日積月累可能導致端口耗盡。這類問題的排查思路是到統(tǒng)計頁看每個節(jié)點的活躍連接數再結合實際業(yè)務的長連接間隔反推 timeout 是否合理。還有一類和 timeout 相關的“事故現場”后端程序臨時卡頓導致某臺節(jié)點積壓了大量慢請求這些請求的處理時間超過了timeout serverHAProxy 直接把后端連接斷開客戶端收到 504。后端恢復后積壓的請求又瞬間全部集中到它身上引發(fā)雪崩。這種場景下合理做法是配合隊列和時間參數雙重限制在健康檢查層面提前摘除“亞健康”節(jié)點而不是單純調大 timeout 去硬扛。不過這個話題屬于高可用調優(yōu)范疇基礎階段先把每個 timeout 的語義理解到位遇到問題時能做到準確定位就算達標了。寫在最后的一點經驗這套配置跑熟之后HAProxy 在項目里基本就是個“透明但可靠”的存在了。不要急著上那些花哨功能先把負載均衡、健康檢查、日志、監(jiān)控頁這四個基礎能力用扎實日常運維就會輕松一大截。我個人在實際操作中養(yǎng)成的習慣是每次改完配置先執(zhí)行一遍haproxy -c -f校驗然后立刻看日志確認新配置對流量沒有異常影響。這個習慣幫我擋掉了不少線上事故建議你也試試。下一篇文章可以聊 ACL 規(guī)則和高級路由到時候見。