乾貨：haproxy和nginx負載均衡

出於對負載均衡工具的疑問，分別對haproxy和nginx的負載均衡進行了抓包分析，分析的過程跟你們分享下。先說下對haproxy抓包獲得的結論吧：haproxy在負載均衡的一臺後端掛掉後，若是還沒達到探測的時間點時，請求還會往掛掉的這臺轉發，請求會丟失。

haproxy負載均衡的實驗過程以下：

1: 先看下haproxy的配置。配置inter 20000爲20s檢測一次，這個是爲了更明顯的抓下haproxy的負載均衡探測機制。

listen test9090
        bind 127.0.0.1:9090
        mode tcp
        server localhost90 127.0.0.1:90 check inter 20000
        server localhost91 127.0.0.1:91 check inter 20000

2: 後端我是用nginx進行測試，看下nginx的配置以下。可在/var/www/html/建個index.html進行測試

server {
            listen       90;
            listen       91;
            location /{
                    root /var/www/html;
            }
    }

先用curl 127.0.0.1:9090進行測試，並在機器上開兩個窗口看下抓包是否均衡正常，兩個窗口運行的命令分別以下：tcpdump -i lo -nn 'port 90' tcpdump -i lo -nn 'port 91'看下負載均衡可否正常工做。

上面抓包的截圖證實nginx監聽的90和91端口都有在監聽。使用抓包來檢測比看日誌來更細點，因此仍是用抓包來分析了。

3: 抓包查看haproxy的健康檢測機制

由於咱們配置了inter 20000，也就是告訴haproxy20s檢測一次，抓包查看也是20s檢查一下。注意下，這個檢測是在客戶端無任務請求的時候進行探測的，也就是處理請求跟探測是分開的。

4: 模擬線上故障，nginx掛掉91端口

把listen 91這個nginx的配置去除，而後reload一下，會發現前端的請求若是分發到91端口的話，就會掛掉，經抓包發現haproxy須要探測三次纔會把故障的給切下線。咱們配置的是20s探測一次，也是最長可能得探測60s才能把故障的切除掉。若是這60s內有1w請求的話，那就會丟掉5k個。若是用在線上的話，探測機制確定不會是20s一次，通常最多3s會切換掉。

nginx負載均衡的配置以下：

1: 先看下nginx的反向代理負載均衡配置，以下：

upstream backend {
        server 127.0.0.1:90 weight=1 max_fails=3 fail_timeout=30;
        server 127.0.0.1:91 weight=5 max_fails=3 fail_timeout=30;
    }仍是把配置打向後端的90和91端口，而後後面再模擬故障的發生。

server {
            listen 9090;
            location / {
                    proxy_pass http://backend;
            }
    }前端仍是使用9090來監聽，把請求轉發到90和91端口。

2: 後端我仍是是用nginx進行測試，看下nginx的配置以下。可在/var/www/html/建個index.html進行測試

server {
            listen       90;
            listen       91;
            location /{
                    root /var/www/html;
            }
    }抓包一樣會發生90和91的包都有過來。

3: 抓包查看nginx反向代理負載均衡的健康檢測機制

抓包你會發現nginx在沒有請求的時候，90和91端口上沒有任務的請求。也就是在沒有請求的時候，是不會對後端的代理服務器進行檢測的。

4: 模擬線上故障，nginx掛掉91端口

把listen 91這個nginx的配置去除，而後reload一下，發現前端的訪問沒有任務影響。抓包以下，請求有打包91，但因爲91沒請求到數據。nginx的均衡還會再次去90上取數據。也就是說，nginx若是後端掛掉91端口的話，對前端的請求沒有任務影響，只要併發支撐得住的話。

綜合一下：

haproxy對於後端的服務器就算請求沒過來也有一直在健康檢測，發現有故障的時候在請求沒到來的時候會切掉，但若是在檢測期間請求到達的話，會有異常。haproxy只會把請求轉到後端的一臺服務器。

nginx對於後端的服務器沒有一直在健康檢測，請求過來的時候，分發仍是進行分發，只是請求不到數據的時候，會再向好的機器進行請求，直到請求正常爲止。nginx請求轉到後端一臺不成功的話，還會轉向另一臺服務器。同時我也測試了下squid，發現squid跟nginx的反向代理負載均衡很類似。

因此若是有用haproxy作爲前端負載均衡的話 ，若是後端服務器要維護，在高併發的狀況，確定是會影響用戶的。但若是是nginx作爲前端負載均衡的話，只要併發撐得住，後端切掉幾臺不會影響到用戶。至於二者的性能，得再繼續研究。

本文地址：https://www.linuxprobe.com/haproxy-nginx.html