Haproxy和Nginx負載均衡測試效果對比記錄

 

爲了對比Hproxy和Nginx負載均衡的效果，分別在測試機上（如下實驗都是在單機上測試的，即負載機器和後端機器都在一臺機器上）作了這兩個負載均衡環境，並各自抓包分析。
下面說下這兩種負載均衡環境下抓包分析後的結果：

1）Haproxy負載均衡環境下的實驗記錄。後端有一臺機器掛掉後，若是還沒達到探測的時間點時，請求還會往掛掉的這臺機器轉發，請求會丟失。
Haproxy負載均衡的實驗記錄以下：
1--先看下Haproxy的配置。
  配置inter 20000爲20s檢測一次，這個是爲了更明顯的抓下HAProxy的負載均衡探測機制。
  [root@wangshibo ~]# cat /usr/local/haproxy/conf/haproxy.cfg

........
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的配置
[root@wangshibo ~]# cat /usr/local/nginx/conf/vhost/test.conf

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

先在/var/www/html裏建立一個首頁index.html文件
[root@wangshibo ~]# echo "this is test" > /var/www/html/index.html
而後測試訪問，並在機器上開兩個窗口看下抓包是否均衡正常，兩個窗口運行的命令分別以下：
[root@wangshibo ~]# curl 127.0.0.1:9090
[root@wangshibo ~]# tcpdump -i lo -nn 'port 90'      
[root@wangshibo ~]# tcpdump -i lo -nn 'port 91'

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

3--抓包查看HAProxy的健康檢測機制
由於前面haproxy裏配置了inter 20000，也就是告訴HAProxy 20s檢測一次，抓包查看也是20s檢查一下。
注意：這個檢測是在客戶端無任務請求的時候進行探測的，也就是處理請求跟探測是分開的。

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

2）Nginx負載均衡環境下的實驗記錄

1--Nginx的反向代理負載均衡配置，以下：
[root@wangshibo ~]# cat /usr/local/nginx/conf/vhost/LB.conf

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;        
    }

server {
     listen 9090;
     location / {
     proxy_pass http://backend;
     }        
    }

前端仍是使用9090來監聽，把請求轉發到90和91端口。
2--後端Nginx配置以下。可在/var/www/html/建個index.html進行測試
[root@wangshibo ~]# cat /usr/local/nginx/conf/vhost/test.conf

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

在/var/www/html裏建立一個首頁index.html文件
[root@wangshibo ~]# echo "this is test2" > /var/www/html/index.html

3--抓包查看Nginx反向代理負載均衡的健康檢測機制。抓包一樣會發生90和91的包都有過來。
抓包會發現Nginx在沒有請求的時候，90和91端口上沒有任務的請求。也就是在沒有請求的時候，是不會對後端的代理服務器進行檢測的。

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

由上面的實驗可知：1）HAProxy對於後端服務器一直在作健康檢測（就算請求沒過來的時候也會作健康檢查）：後端機器故障發生在請求還沒到來的時候，haproxy會將這臺故障機切掉，但若是後端機器故障發生在請求到達期間，那麼前端訪問會有異常。也就是說HAProxy會把請求轉到後端的這臺故障機上，並通過屢次探測後纔會把這臺機器切掉，並把請求發給其餘正常的後端機，這勢必會形成一小段時間內前端訪問失敗。2）Nginx對於後端的服務器沒有一直在作健康檢測：  後端機器發生故障，在請求過來的時候，分發仍是會正常進行分發，只是請求不到數據的時候，它會再轉向好的後端機器進行請求，直到請求正常爲止。也就是說Nginx請求轉到後端一臺不成功的機器的話，還會再轉向另一臺服務器，這對前端訪問沒有什麼影響。3）所以，若是有用HAProxy作爲前端負載均衡的話 ，若是後端服務器要維護，在高併發的狀況，確定是會影響用戶的。但若是是Nginx作爲前端負載均衡的話，只要併發撐得住，後端切掉幾臺不會影響到用戶。