大型網站系統架構實踐(四)http層負載均衡之haproxy實踐篇(一)


方案

上篇文章講到了負載均衡的相關理論知識,這篇文章我打算講講實踐方法以及實踐中遇到的問題

方案:haproxy http層負載均衡

安裝一個haproxy服務,兩個web服務

haproxy:192.168.1.227:80

web1 http://192.168.1.226:8081/login

web2 http://192.168.1.246:8888/login

web服務自行准備,文章中就不說了

負載均衡算法為輪詢調度

會話保持實現方式為cookie識別,插入cookie

優點:

1 配置簡單

2 提供會話保持功能

3 性能不錯

安裝與配置

安裝

tar -zxvf haproxy-1.49.tar.gz   
cd haproxy-1.4.9  
make TARGET=linux26 PREFIX=/haproxy  
make install PREFIX=/haproxy

創建日志目錄
mkdir /home/haproxy/logs/
創建配置文件目錄
mkdir /etc/haproxy/

PREFIX=/haproxy : 安裝目錄前綴

啟動程序將安裝在 /haproxy/sbin/haproxy

配置

global  
       log 127.0.0.1   local3  
       #log 127.0.0.1  local1 notice  
       #log loghost    local0 info  
       maxconn 4096
       #chroot /usr/local/haproxy
       #chroot /home/haproxy  
       uid 502 
       gid 502
       daemon  
       nbproc 1  
       pidfile /home/haproxy/logs/haproxy.pid  
       #debug  
       #quiet  
    defaults  
       log     global 
       mode    http  
       option  httplog  
       option  dontlognull  
       option  forwardfor  
       option  redispatch 
       log     127.0.0.1 local3
       retries 3  
       maxconn 32000  
       balance roundrobin  
       stats   uri     /haproxy-stats  
       contimeout      5000  
       clitimeout      50000  
       srvtimeout      50000  
    
  listen web_proxy *:80
       appsession JSESSIONID len 52 timeout 3h
       #插入cookie的方式
       cookie SRV insert indirect nocache
       #模式有http tcp health
       mode http
       stats enable
       stats hide-version
       #查看狀態
        stats uri /haproxy-stats
       stats refresh 10s
       monitor-uri /haproxy_test
       #負載均衡方案:輪調
        balance roundrobin
       option httpclose
       #后端可以獲取客戶端的真實ip
       option forwardfor
       #健康檢查
        option httpchk HEAD /login HTTP/1.0
       #option  httpchk GET /ping.jsp 
       #后端真實服務
        server  webA 192.168.1.226:8081 cookie A check  
       server  webB 192.168.1.246:8888 cookie B check

這里注意配置檢查地址

option httpchk HEAD /login HTTP/1.0

啟動

/haproxy/sbin/haproxy -f /etc/haproxy/haproxy.cfg

查看進程

ps -ef|grep haproxy

關閉進程

kill –9 pid

查看監控頁面

http://192.168.1.227/haproxy-stats

如下圖:注意狀態一欄顯示200,如果不是則表示web服務器未啟動,或者健康檢查鏈接不可訪問

image

測試

然后打開不同的瀏覽器,模擬用戶訪問

http://192.168.1.227/login/

會看到

image

 

image

證明請求被分發到不同的web服務器了

查看cookie

image

cookie被加入了SRV=A

會話保持的流程

1.客戶端首次請求,經過haproxy到web服務端時,web服務端set-cookie並響應到haproxy

2.haproxy在cookie后插入SRV=A,並響應客戶端

3.客戶端第二次請求,經過haproxy時,haproxy將srv后綴去掉,然后請求服務端

總結

該方案解決的問題

1.負載均衡,並解決web服務的單點故障

2.會話保持

存在的缺點

1.web服務器的session保存存在單點故障,即其中一台web服務器宕機之后,存儲在上面的session也會丟失

2.負載均衡服務器存在單點故障

下一篇文章將討論如何解決以上2個缺點

 

上篇文章 大型網站系統架構的演進(三)如何提高網站的高可用和高性能

目錄 大型網站系統架構的演進目錄

下篇文章 大型網站系統架構的演進(五)深入探討web應用高可用方案


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM