方案：haproxy http層負載均衡
安裝乙個haproxy服務，兩個web服務
haproxy：192.168.1.227:80
web1
web2
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=/haproxyprefix=/haproxy ： 安裝目錄字首建立日誌目錄
mkdir /home/haproxy/logs/
建立配置檔案目錄
mkdir /etc/haproxy/
啟動程式將安裝在 /haproxy/sbin/haproxy
配置vim /etc/haproxy/haproxy.cfg
#插入cookie的方式
cookie srv insert indirect nocache
#模式有http tcp health
#檢視狀態
stats uri /haproxy-stats
stats refresh 10s
monitor-uri /haproxy_test
#負載均衡方案:輪調
#後端可以獲取客戶端的真實ip
option forwardfor
#健康檢查
#後端真實服務
server weba 192.168.1.226:8081 cookie a check
server webb 192.168.1.246:8888 cookie b check
這裡注意配置檢查位址
啟動/haproxy/sbin/haproxy -f /etc/haproxy/haproxy.cfg
檢視程序
ps -ef|grep haproxy
關閉程序
kill –9 pid
檢視監控頁面
測試
然後開啟不同的瀏覽器，模擬使用者訪問
會看到
證明請求被分發到不同的web伺服器了
檢視cookie
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.負載均衡伺服器存在單點故障
負載均衡之HTTP重定向
由於目前現有網路的各個核心部分隨著業務量的提高，訪問量和資料流量的快速增長，其處理能力和計算強度也相應地增大，使得單一的伺服器裝置根本無法承擔。在此情況下，如果扔掉現有裝置去做大量的硬體公升級，這樣將造成現有資源的浪費，而且如果再面臨下一次業務量的提公升時，這又將導致再一次硬體公升級的高額成本投入，...
負載均衡之HTTP重定向
由於目前現有網路的各個核心部分隨著業務量的提高，訪問量和資料流量的快速增長，其處理能力和計算強度也相應地增大，使得單一的伺服器裝置根本無法承擔。在此情況下，如果扔掉現有裝置去做大量的硬體公升級，這樣將造成現有資源的浪費，而且如果再面臨下一次業務量的提公升時，這又將導致再一次硬體公升級的高額成本投入，...
四層負載均衡和七層負載均衡
第一，技術原理上的區別。所謂四層負載均衡，也就是主要通過報文中的目標位址和埠，再加上負載均衡裝置設定的伺服器選擇方式，決定最終選擇的內部伺服器。以常見的 tcp為例，負載均衡裝置 在接收到第乙個來自客戶端的 syn請求時 即通過上述方式選擇乙個最佳的伺服器，並對報文中目標 ip位址進行修改 改為後端...