??????? 從上篇文章到這篇文章，中間用了一段時間準備，主要是想把東西講透，同時希望大家給與一些批評和建議，這樣我才能有所進步，也希望喜歡我文章的朋友，給個贊，這樣我才能更有激情，呵呵。

由于本篇要寫的內容有點多，我就分為幾篇博客進行了詳細描述。

Haproxy提高web應用的高可用

?????? 上一篇文章講到了haproxy+tomcat的方案，文章地址：大型網站系統架構的演進（四）http層負載均衡之haproxy實踐篇（一）

大家可以先溫習一下，

?????? 文中提到了高可用，該集群方案也可以提高應用系統的高可用，如果tomcat應用出現故障，或者tomcat應用服務器出現故障，haproxy會檢測到（這里指的是定期心跳檢查），并將應用從可用列表中刪除，打開監控頁面http://192.168.1.227/haproxy-stats

可以看到有2個web應用運行，如果將webA停掉，可以看到webA顯示down

這樣客戶端請求就不會分發給webA，下面模擬一下webA宕機的情況

這里對sessionId增加了一個后綴做標記

webA：jvm3

webB：jvm2

1. webA正常的情況，客戶請求被分發到webA

此時產生的sessionId為jvm3

2. 停掉webA，刷新瀏覽器

可以看到請求被轉發到webB

也就是說web應用出現故障，haproxy會做切換，因此可以保證web應用的高可用。

Haproxy本身的高可用

????? 如果haproxy本身出現故障，那么網站將不可用，所以我們接下來要做的事情就是解決haproxy單點故障的問題。

我們可以運用虛擬ip技術，將haproxy部署在2臺服務器上，一臺做為master，正常運營，一臺為backup，

當master出現問題的時候，接管master。

????? 首先有一個虛擬ip暴露給客戶端，虛擬ip對應的mac地址為master服務器，

用戶向虛擬ip發送一個請求，該請求會被分發到master服務器上，當master出現故障時，被backup檢測到，則backup成為master,

且發送消息將arp緩存虛擬ip對應的mac地址backup的mac地址，這樣發送到虛擬ip的報文會被轉發到backup 。

架構圖：

該方案解決了haproxy單點故障的問題，具體用keepalived實現，詳細請參考文章：

Keepalived 實現雙機熱備

Keepalived + haproxy雙機高可用方案

如果想實踐的朋友，請按照上面2篇文章安裝和配置haproxy和keepalived

系統分布如下：

ha主機 192.168.1.227:80

ha備機 192.168.1.246

keepalived 主機 192.168.1.227

keepalived備機 192.168.1.246

web1 http://192.168.1.226:8081/login

web2 http://192.168.1.246:8888/login

虛擬ip 192.168.1.99

安裝好haproxy和keepalived后，啟動haproxy和keepalived

Haproxy訪問地址：

http://192.168.1.99/haproxy-stats

注意pid為9644，這是master上的haproxy

應用訪問地址

http://192.168.1.99/login/

注意sessionId的后綴為jvm3

查看虛擬ip1.99對應的mac地址

接下來，我們停掉master上的haproxy服務

kill -9 9644

查看haproxy http://192.168.1.99/haproxy-stats

發現haproxy的pid變成backup機器上的了

刷新web的訪問頁面http://192.168.1.99/login/

發現sessionId沒有變化

查看虛擬ip1.99對應的mac地址

mac地址已經變為backup機器上的了

如果我們直接關閉主機服務器或者關閉主機的keepalived，發現測試結果也是一樣的

因此該方案實現了haproxy的高可用，解決了haproxy的單點故障問題。

會話保持問題

那么這里我還要提出一個疑問，為什么sessionId也沒有變化呢？

也就是說切換到backup服務器的haproxy之后，

可以保持用戶的會話，那么它是怎么實現的呢？

這里就要回到上篇文章講的負載均衡時保持會話的策略

會話保持的流程

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

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

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

這種保持會話的方法是無狀態的，也就說主要haproxy配置的負載均衡策略相同，不管在哪臺機器上運行

將得到同樣的結果

?

上篇文章 大型網站系統架構的演進（四）http層負載均衡之haproxy實踐篇（一）

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

下篇 大型網站系統架構實踐（六）深入探討web應用集群Session保持

轉載于:https://www.cnblogs.com/tangyanbo/p/4431136.html

總結

以上是生活随笔為你收集整理的大型网站系统架构实践（五）深入探讨web应用高可用方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。