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

}先用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埠

nginx負載均衡的配置如下：

1: 先看下nginx的反向**負載均衡配置，如下：

upstream backend 還是把配置打向後端的90和91埠，然後後面再模擬故障的發生。

server

}前端還是使用9090來監聽，把請求**到90和91埠。

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

server

}抓包同樣會發生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做為前端負載均衡的話，只要併發撐得住，後端切掉幾台不會影響到使用者。至於兩者的效能，得再繼續研究。