轉(zhuǎn)載：淺談web應(yīng)用的負(fù)載均衡、集群、高可用(HA)解決方案

Baruch 2017-09-07

展開全文

聲明：以下僅為個人的一些總結(jié)和隨寫，如有不對之處，還請看到的網(wǎng)友指出，以免誤導(dǎo)。（詳細(xì)的配置方案請google，這里只說解決方案。）

1、熟悉幾個組件

1.1、apache
     —— 它是Apache軟件基金會的一個開放源代碼的跨平臺的網(wǎng)頁服務(wù)器，屬于老牌的web服務(wù)器了，支持基于Ip或者域名的虛擬主機，支持代理服務(wù)器，支持安全Socket層(SSL)等等，目前互聯(lián)網(wǎng)主要使用它做靜態(tài)資源服務(wù)器，也可以做代理服務(wù)器轉(zhuǎn)發(fā)請求(如：圖片鏈等)，結(jié)合tomcat等servlet容器處理jsp。
1.2、ngnix
     —— 俄羅斯人開發(fā)的一個高性能的 HTTP和反向代理服務(wù)器。由于Nginx 超越 Apache 的高性能和穩(wěn)定性，使得國內(nèi)使用 Nginx 作為 Web 服務(wù)器的網(wǎng)站也越來越多，其中包括新浪博客、新浪播客、網(wǎng)易新聞、騰訊網(wǎng)、搜狐博客等門戶網(wǎng)站頻道等，在3w以上的高并發(fā)環(huán)境下，ngnix處理能力相當(dāng)于apache的10倍。
     參考：apache和tomcat的性能分析和對比(http://blog./nginx_php_v6/)
1.3、lvs
     —— Linux Virtual Server的簡寫，意即linux虛擬服務(wù)器，是一個虛擬的服務(wù)器集群系統(tǒng)。由畢業(yè)于國防科技大學(xué)的章文嵩博士于1998年5月創(chuàng)立，可以實現(xiàn)LINUX平臺下的簡單負(fù)載均衡。了解更多，訪問官網(wǎng)：http://zh./。

1.4、HAProxy

—— HAProxy提供高可用性、負(fù)載均衡以及基于TCP和HTTP應(yīng)用的代理，支持虛擬主機，它是免費、快速并且可靠的一種解決方案。HAProxy特別適用于那些負(fù)載特大的web站點，這些站點通常又需要會話保持或七層處理。HAProxy運行在當(dāng)前的硬件上，完全可以支持?jǐn)?shù)以萬計的并發(fā)連接。并且它的運行模式使得它可以很簡單安全的整合進(jìn)您當(dāng)前的架構(gòu)中，同時可以保護(hù)你的web服務(wù)器不被暴露到網(wǎng)絡(luò)上.
1.5、keepalived
     —— 這里說的keepalived不是apache或者tomcat等某個組件上的屬性字段，它也是一個組件，可以實現(xiàn)web服務(wù)器的高可用(HA high availably)。它可以檢測web服務(wù)器的工作狀態(tài)，如果該服務(wù)器出現(xiàn)故障被檢測到，將其剔除服務(wù)器群中，直至正常工作后，keepalive會自動檢測到并加入到服務(wù)器群里面。實現(xiàn)主備服務(wù)器發(fā)生故障時ip瞬時無縫交接。它是LVS集群節(jié)點健康檢測的一個用戶空間守護(hù)進(jìn)程，也是LVS的引導(dǎo)故障轉(zhuǎn)移模塊（director failover）。Keepalived守護(hù)進(jìn)程可以檢查LVS池的狀態(tài)。如果LVS服務(wù)器池當(dāng)中的某一個服務(wù)器宕機了。keepalived會通過一個setsockopt呼叫通知內(nèi)核將這個節(jié)點從LVS拓?fù)鋱D中移除。
1.6、memcached
     —— 它是一個高性能分布式內(nèi)存對象緩存系統(tǒng)。當(dāng)初是Danga Interactive為了LiveJournal快速發(fā)展開發(fā)的系統(tǒng)，用于對業(yè)務(wù)查詢數(shù)據(jù)緩存，減輕數(shù)據(jù)庫的負(fù)載。其守護(hù)進(jìn)程(daemon)是用C寫的，但是客戶端支持幾乎所有語言(客戶端基本上有3種版本[memcache client for Java;spymemcached;xMecache])，服務(wù)端和客戶端通過簡單的協(xié)議通信；在memcached里面緩存的數(shù)據(jù)必須序列化。
1.7、terracotta
     —— 是一款由美國Terracotta公司開發(fā)的著名開源Java集群平臺。它在JVM與Java應(yīng)用之間實現(xiàn)了一個專門處理集群功能的抽象層，允許用戶在不改變系統(tǒng)代碼的情況下實現(xiàn)java應(yīng)用的集群。支持?jǐn)?shù)據(jù)的持久化、session的復(fù)制以及高可用(HA)。詳細(xì)參考：http://topmanopensource./blog/1911679

2、關(guān)鍵術(shù)語
2.1、負(fù)載均衡（load balance）

在互聯(lián)網(wǎng)高速發(fā)展的時代，大數(shù)據(jù)量、高并發(fā)等是互聯(lián)網(wǎng)網(wǎng)站提及最多的。如何處理高并發(fā)帶來的系統(tǒng)性能問題，最終大家都會使用負(fù)載均衡機制。它是根據(jù)某種負(fù)載策略把請求分發(fā)到集群中的每一臺服務(wù)器上，讓整個服務(wù)器群來處理網(wǎng)站的請求。
公司比較有錢的，可以購買專門負(fù)責(zé)負(fù)載均衡的硬件（如：F5）,效果肯定會很好。對于大部分公司，會選擇廉價有效的方法擴展整個系統(tǒng)的架構(gòu)，來增加服務(wù)器的吞吐量和處理能力，以及承載能力。

2.2、集群（Cluster）

用N臺服務(wù)器構(gòu)成一個松耦合的多處理器系統(tǒng)(對外來說，他們就是一個服務(wù)器)，它們之間通過網(wǎng)絡(luò)實現(xiàn)通信。讓N臺服務(wù)器之間相互協(xié)作，共同承載一個網(wǎng)站的請求壓力。

2.3、高可用（HA）

在集群服務(wù)器架構(gòu)中，當(dāng)主服務(wù)器故障時，備份服務(wù)器能夠自動接管主服務(wù)器的工作，并及時切換過去，以實現(xiàn)對用戶的不間斷服務(wù)。ps：這里我感覺它跟故障轉(zhuǎn)移(failover)是一個意思，看到的網(wǎng)友給個解釋，謝謝？

2.4、session復(fù)制/共享

在訪問系統(tǒng)的會話過程中，用戶登錄系統(tǒng)后，不管訪問系統(tǒng)的任何資源地址都不需要重復(fù)登錄，這里面servlet容易保存了該用戶的會話(session)。如果兩個tomcat(A、B)提供集群服務(wù)時候，用戶在A-tomcat上登錄，接下來的請求web服務(wù)器根據(jù)策略分發(fā)到B-tomcat，因為B-tomcat沒有保存用戶的會話(session)信息，不知道其登錄，會跳轉(zhuǎn)到登錄界面。
這時候我們需要讓B-tomcat也保存有A-tomcat的會話，我們可以使用tomcat的session復(fù)制實現(xiàn)或者通過其他手段讓session共享。

3、常用web集群

3.1、tomcat集群方案
apache+tomcat；ngnix+tomcat；lvs+ngnix+tomcat；大家比較熟悉的是前兩種。(lvs負(fù)責(zé)集群調(diào)度，nginx負(fù)責(zé)靜態(tài)文件處理，tomcat負(fù)責(zé)動態(tài)文件處理[最優(yōu)選擇])。以apache+tomcat集群為例，簡單說一下：
1、他們之間的通信有三種方式：ajp_proxy、mod_jk鏈接器、http_proxy。具體參考：http://www.ibm.com/developerworks/cn/opensource/os-lo-apache-tomcat/
2、apache的分發(fā)策略有4種。權(quán)重(默認(rèn))、流量(bytraffic)、請求次數(shù)(byRequests)、繁忙程度(byBusyness根據(jù)活躍請求數(shù)的多少)
3、apache支持stickysession(粘性session)，即為：訪問用戶訪問了A-tomcat，那么他的所有請求都會轉(zhuǎn)發(fā)到A-tomcat，而不會到B-tomcat。[這樣的負(fù)載均衡效果不好，適用于小型網(wǎng)站，下面說非粘性session]
4、它們之間的架構(gòu)如圖1：

問題1：只有一個web服務(wù)器，明顯的單點故障。如果該apache出現(xiàn)問題，整個網(wǎng)站就會癱瘓。

3.2、session復(fù)制

如果不采用stickysession(粘性session)，那么我們可以采用tomcat的session復(fù)制使所有節(jié)點tomcat的會話相同，tomcat使用組播技術(shù)，只要集群中一個tomcat節(jié)點的session發(fā)生改變，會廣播通知所有tomcat節(jié)點發(fā)生改變。

問題2：據(jù)網(wǎng)友測試，當(dāng)tomcat節(jié)點數(shù)達(dá)到4個以上時候，集群性能呈線性下滑；另外當(dāng)用戶訪問量大到一定程度，會話內(nèi)容隨之增多，tomcat節(jié)點相互之間通信產(chǎn)生大量的網(wǎng)絡(luò)消耗，產(chǎn)生網(wǎng)絡(luò)阻塞，整個集群的吞吐量不能再上升。

4、高可用(HA)和session共享(解決上面提到的兩個問題)

4.1、使用lvs+keepalive實現(xiàn)集群高可用，達(dá)到更健壯的LB
我們可以做前端使用lvs來做負(fù)載均衡，根據(jù)lvs的8種調(diào)度算法(可設(shè)置)，分發(fā)請求到對應(yīng)的web服務(wù)器集群上。lvs做雙機熱備，通過keepalived模塊能夠達(dá)到故障自動轉(zhuǎn)移到備份服務(wù)器，不間斷提供服務(wù)，結(jié)構(gòu)如圖2：

說明：據(jù)查詢了解，一般在WEB端使用的負(fù)載均衡比較多的是HAProxy+keepalived+nginx；數(shù)據(jù)庫MySQL集群使用Lvs+keepalived+mysql實現(xiàn)。因為HAProxy和nginx一樣是工作在網(wǎng)絡(luò)7層之上，并且前者彌補了nginx的一些缺點如session的保持，cookie的引導(dǎo)等，且它本身是個負(fù)責(zé)均衡軟件，處理負(fù)載均衡上面必然優(yōu)于nginx；lvs比較笨重，對于比較龐大的網(wǎng)絡(luò)應(yīng)用實施比較復(fù)雜，雖然它運行在網(wǎng)絡(luò)4層之上，僅做分發(fā)沒有流量產(chǎn)生，但是它不能做正則處理也不能也不能做動靜分離，所以一般用lvs+keepalived或heatbeat做數(shù)據(jù)庫層的負(fù)載均衡。

LVS、HAProxy、Nginx做負(fù)載均衡的比較
4.2、使用terracotta或者memcached使session共享

4.2.1、terracotta是jvm級別的session共享

它基本原理是對于集群間共享的數(shù)據(jù)，當(dāng)在一個節(jié)點發(fā)生變化的時候，Terracotta只把變化的部分發(fā)送給Terracotta服務(wù)器，然后由服務(wù)器把它轉(zhuǎn)發(fā)給真正需要這個數(shù)據(jù)的節(jié)點，并且共享的數(shù)據(jù)對象不需要序列化。

4.2.2、通過memcached實現(xiàn)內(nèi)存級session共享

通過memcached-session-manager（msm）插件，通過tomcat上一定的配置，即可實現(xiàn)把session存儲到memcached服務(wù)器上。注意：tomcat支持tomcat6+，并且memcached可以支持分布式內(nèi)存，msm同時支持黏性session（sticky sessions）或者非黏性session（non-sticky sessions）兩種模式，在memcached內(nèi)存中共享的對象需要序列化。結(jié)構(gòu)如圖3：

通過一定的配置，可以實現(xiàn)故障轉(zhuǎn)移(只支持對非粘性session)。如：

Xml代碼  

<Context>    

      ...    

      <Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"    

        memcachedNodes="n1:host1.yourdomain.com:11211,n2:host2.yourdomain.com:11211"    

        failoverNodes="n1"    

        requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$"    

        transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"    

        />    

</Context>

說明：failoverNodes：故障轉(zhuǎn)移節(jié)點，對非粘性session不可用。屬性failoverNodes="n1"的作用是告訴msm最好是把session保存在memcached "n2"節(jié)點上，只有在n2節(jié)點不可用的情況下才把session保存在n1節(jié)點。這樣即使host2上的tomcat宕機，仍然可以通過host1上的tomcat訪問存放在memcached "n1" 節(jié)點中的session。

4.2.3、其他方案
通過cookie保存用戶信息(一般是登錄信息)，每一個請求到達(dá)web應(yīng)用的時候，web應(yīng)用從cookie中取出數(shù)據(jù)進(jìn)行處理（這里盡量對cookie做加密處理）；
另外一種是把用戶信息的關(guān)鍵屬性保存到數(shù)據(jù)庫，這樣就不需要session了。請求過來從數(shù)據(jù)庫查詢關(guān)鍵屬性數(shù)據(jù)，做相應(yīng)處理。缺點：加大了數(shù)據(jù)庫的負(fù)載，使數(shù)據(jù)庫成為集群的瓶頸。

原理

在第三，四篇文章中講到了會話保持的問題，而且還遺留了一個問題，就是會話保持存在單點故障，

當(dāng)時的方案是cookie插入后綴，即haproxy指負(fù)責(zé)分發(fā)請求，應(yīng)用服務(wù)自行保持用戶會話，如果應(yīng)

用服務(wù)器宕機，則session會丟失。

現(xiàn)在來溫習(xí)下解決方案

方案1：session復(fù)制

原理	就是將1臺服務(wù)器的session復(fù)制到其它所有的服務(wù)器上，這樣無論訪問哪臺服務(wù)器，都會得到用戶的session
優(yōu)點	不存在單點故障問題
缺點	當(dāng)服務(wù)器的數(shù)量比較大時，session同步將會變得相當(dāng)耗時

方案2：session粘滯

原理	就是用戶請求一個服務(wù)器之后，同一個會話的其它請求，都會被分配到這臺服務(wù)器，session粘滯的功能由負(fù)載均衡中間件完成
優(yōu)點	解決了session復(fù)制的性能問題
缺點	由于用戶的會話被保存到單一的服務(wù)器，就容易出現(xiàn)單點故障

方案3：session服務(wù)器

原理	部署一個專門的服務(wù)，保存用戶session，同時在web服務(wù)器本地也保存一份，當(dāng)本地沒有或者失效時，去訪問session服務(wù)器，當(dāng)然session服務(wù)器就成了單點，當(dāng)用戶量大的時候也容易宕機，這時可以做一個session服務(wù)器集群，做主備同步備份，這樣就達(dá)到了較好的效果，具體實現(xiàn)可以用redies，memcached 等緩存中間件。
優(yōu)點	解決了單點故障和性能問題
缺點	實現(xiàn)復(fù)雜

Redis保存session方案

上篇文章講到的就是session粘滯的方案，既然前2種方案都有各自的缺點，那么就采用第三中方案

可以用redis做session緩存，保存用戶session，做成主備模式，采用同步備份或者異步備份。

同步備份：在主機宕機時，備機接管之后session數(shù)據(jù)不丟失。

異步備份：在主機宕機時，備機接管主機，但是如果有一部分session還沒來得及同步到備機，session將丟失。

可以根據(jù)實際情況來決定采用同步備份還是異步備份。

系統(tǒng)架構(gòu)圖如下：

如果用戶量比較大，單服務(wù)器訪問和存儲session將會成為瓶頸，可以考慮用session服務(wù)器集群，架構(gòu)圖如下：

redis集群特點

1）將數(shù)據(jù)分散到集群中的多個節(jié)點，每個節(jié)點存儲的數(shù)據(jù)量就會變少，這樣存儲和訪問

的效率會得到提升。

2）每個節(jié)點都有主備，如果節(jié)點的主存儲掛了，備份存儲會接管主存儲，提高可用性。

Redis+Tomcat實現(xiàn)

session流程

1.客戶端首次請求服務(wù)端

2.服務(wù)端產(chǎn)生session并set cookie響應(yīng)給客戶端

3.客戶端再次請求服務(wù)端，會帶上cookie

4.服務(wù)端根據(jù)cookie找到對應(yīng)的session

實現(xiàn)思路

如果我們要編寫程序?qū)崿F(xiàn)這個方案，需要解決以下問題：

1.session的安全性，即不容易被仿造。

2.session的唯一性，如果用tomcat產(chǎn)生session的策略，多臺tomcat會產(chǎn)生的session會存在重復(fù)的可能。

3.session的有效期維護(hù)，session會有個有效期，用戶在這個時間內(nèi)不訪問系統(tǒng)，session將會失效，如果

用戶一直訪問，則要自動延長session有效期。

4.在集群session服務(wù)器中，要考慮負(fù)載均衡，這也是需要編寫客戶端代碼的，在分布式session緩存中，

需要根據(jù)sessionId哈希分布，那么就和服務(wù)器個數(shù)進(jìn)行了耦合，在添加和移除服務(wù)器的時候，將出現(xiàn)數(shù)

據(jù)不一致的問題。

5.如何實現(xiàn)才能讓應(yīng)用程序改動最小，或者是不改動。

我們可以選擇自己寫程序來實現(xiàn)以上功能，不過在這里我使用一個現(xiàn)成的框架，即tomcat-redis-session-manager

有時間并感興趣的朋友，可以在這個基礎(chǔ)上自行實現(xiàn)一個，這樣更適合自己的項目。

服務(wù)器部署分布：

ha主機 192.168.1.227:80

ha備機 192.168.1.246:80

keepalived 主機 192.168.1.227

keepalived備機 192.168.1.246

web1 http://192.168.1.226:8888/login

web2 http://192.168.1.246:8888/login

redis主 192.168.1.245 6380

redis備

安裝redis

主機和備機都安裝redis

wget http://download./releases/redis-2.8.5.tar.gz

解壓：

tar xzf redis-2.8.5.tar.gz

cd redis-2.8.5

make

啟動

src/redis-server redis.conf --port 6380 &

客戶端登錄

src/redis-cli -p 6380

備機配置復(fù)制：

redis.conf文件中

添加

slaveof 192.168.1.245 6380

Tomcat配置

tomcat版本：7.0.61

相關(guān)jar包：

注意這里的jar包最好是按下面的版本，否則會出現(xiàn)jar包沖突的問題。

tomcat-redis-session-manager-1.1.jar

commons-pool-1.6.jar

jedis-2.1.0.jar

下載tomcat redis session manager

https://github.com/jcoleman/tomcat-redis-session-manager/downloads

下載 apache common pool

http://commons./proper/commons-pool/download_pool.cgi

下載版本：tomcat-redis-session-manager-1.1

redis的jar包可以從maven中央倉庫下載

將以上3個jar包放入tomcat/lib目錄中

在tomcat context.xml中加入如下內(nèi)容

<!-- host: optional: defaults to "localhost" -->
<!-- port: defaults to "6379" -->
<!-- database: optional: defaults to "0" -->
<!-- maxInactiveInterval: optional: defaults to "60" (in seconds) -->
<Valve className="com.radiadesign.catalina.session.RedisSessionHandlerValve" />
<Manager className="com.radiadesign.catalina.session.RedisSessionManager"
    host="192.168.1.245" port="6380" database="0" maxInactiveInterval="60" />