淺談web應用的負載均衡、高可用、羣集

一、熟悉幾個組件

1.一、apache

     —— 它是Apache軟件基金會的一個開放源代碼的跨平臺的網頁服務器，屬於老牌的web服務器了，支持基於Ip或者域名的虛擬主機，支持代理服務器，支持安全Socket層(SSL)等等，目前互聯網主要使用它作靜態資源服務器，也能夠作代理服務器轉發請求(如：圖片鏈等)，結合tomcat等servlet容器處理jsp。

1.二、ngnix

     —— 俄羅斯人開發的一個高性能的 HTTP和反向代理服務器。因爲Nginx 超越 Apache 的高性能和穩定性，使得國內使用 Nginx 做爲 Web 服務器的網站也愈來愈多，其中包括新浪博客、新浪播客、網易新聞、騰訊網、搜狐博客等門戶網站頻道等，在3w以上的高併發環境下，ngnix處理能力至關於apache的10倍。

     參考：apache和tomcat的性能分析和對比(http://blog.s135.com/nginx_php_v6/)

1.三、lvs

     —— Linux Virtual Server的簡寫，意即Linux虛擬服務器，是一個虛擬的服務器集羣系統。由畢業於國防科技大學的章文嵩博士於1998年5月創立，能夠實現LINUX平臺下的簡單負載均衡。瞭解更多，訪問官網：http://zh.linuxvirtualserver.org/。

1.四、HAProxy

     —— HAProxy提供高可用性、負載均衡以及基於TCP和HTTP應用的代理，支持虛擬主機，它是免費、快速而且可靠的一種解決方案。HAProxy特別適用於那些負載特大的web站點， 這些站點一般又須要會話保持或七層處理。HAProxy運行在當前的硬件上，徹底能夠支持數以萬計的併發鏈接。而且它的運行模式使得它能夠很簡單安全的整合進您當前的架構中， 同時能夠保護你的web服務器不被暴露到網絡上.

1.五、keepalived

     —— 這裏說的keepalived不是apache或者tomcat等某個組件上的屬性字段，它也是一個組件，能夠實現web服務器的高可用(HA high availably)。它能夠檢測web服務器的工做狀態，若是該服務器出現故障被檢測到，將其剔除服務器羣中，直至正常工做後，keepalive會自動檢測到並加入到服務器羣裏面。實現主備服務器發生故障時ip瞬時無縫交接。它是LVS集羣節點健康檢測的一個用戶空間守護進程，也是LVS的引導故障轉移模塊（director failover）。Keepalived守護進程能夠檢查LVS池的狀態。若是LVS服務器池當中的某一個服務器宕機了。keepalived會經過一 個setsockopt呼叫通知內核將這個節點從LVS拓撲圖中移除。

1.六、memcached

     —— 它是一個高性能分佈式內存對象緩存系統。當初是Danga Interactive爲了LiveJournal快速發展開發的系統，用於對業務查詢數據緩存，減輕數據庫的負載。其守護進程(daemon)是用C寫的，可是客戶端支持幾乎全部語言(客戶端基本上有3種版本[memcache client for java;spymemcached;xMecache])，服務端和客戶端經過簡單的協議通訊；在memcached裏面緩存的數據必須序列化。

1.七、terracotta

     —— 是一款由美國Terracotta公司開發的著名開源Java集羣平臺。它在JVM與Java應用之間實現了一個專門處理集羣功能的抽象層，容許用戶在不改變系統代碼的狀況下實現java應用的集羣。支持數據的持久化、session的複製以及高可用(HA)。詳細參考：http://topmanopensource.iteye.com/blog/1911679

二、關鍵術語

2.一、負載均衡（load balance）

 

在互聯網高速發展的時代，大數據量、高併發等是互聯網網站說起最多的。如何處理高併發帶來的系統性能問題，最終你們都會使用負載均衡機制。它是根據某種負載策略把請求分發到集羣中的每一臺服務器上，讓整個服務器羣來處理網站的請求。

公司比較有錢的，能夠購買專門負責負載均衡的硬件（如：F5）,效果確定會很好。對於大部分公司，會選擇廉價有效的方法擴展整個系統的架構，來增長服務器的吞吐量和處理能力，以及承載能力。

2.二、集羣（Cluster）

 用N臺服務器構成一個鬆耦合的多處理器系統(對外來講，他們就是一個服務器)，它們之間經過網絡實現通訊。讓N臺服務器之間相互協做，共同承載一個網站的請求壓力。

2.三、高可用（HA）

 在集羣服務器架構中，當主服務器故障時，備份服務器可以自動接管主服務器的工做，並及時切換過去，以實現對用戶的不間斷服務。ps：這裏我感受它跟故障轉移(failover)是一個意思，看到的網友給個解釋，謝謝？

2.四、session複製/共享

 在訪問系統的會話過程當中，用戶登陸系統後，無論訪問系統的任何資源地址都不須要重複登陸，這裏面servlet容易保存了該用戶的會話(session)。若是兩個tomcat(A、B)提供集羣服務時候，用戶在A-tomcat上登陸，接下來的請求web服務器根據策略分發到B-tomcat，由於B-tomcat沒有保存用戶的會話(session)信息，不知道其登陸，會跳轉到登陸界面。

這時候咱們須要讓B-tomcat也保存有A-tomcat的會話，咱們可使用tomcat的session複製實現或者經過其餘手段讓session共享。

三、經常使用web集羣

3.一、tomcat集羣方案
 apache+tomcat；ngnix+tomcat；lvs+ngnix+tomcat；你們比較熟悉的是前兩種。(lvs負責集羣調度，nginx負責靜態文件處理，tomcat負責動態文件處理[最優選擇])。 以apache+tomcat集羣爲例，簡單說一下：
  一、他們之間的通訊有三種方式：ajp_proxy、mod_jk連接器、http_proxy。具體參考：http://www.ibm.com/developerworks/cn/opensource/os-lo-apache-tomcat/
  二、apache的分發策略有4種。權重(默認)、流量(bytraffic)、請求次數(byRequests)、繁忙程度(byBusyness根據活躍請求數的多少)
  三、apache支持stickysession(粘性session)，即爲：訪問用戶訪問了A-tomcat，那麼他的全部請求都會轉發到A-tomcat，而不會到B-tomcat。[這樣的負載均衡效果很差，適用於小型網站，下面說非粘性session]
  四、它們之間的架構如圖1：

問題1：只有一個web服務器，明顯的單點故障。若是該apache出現問題，整個網站就會癱瘓。

 

3.二、session複製

  若是不採用stickysession(粘性session)，那麼咱們能夠採用tomcat的session複製使全部節點tomcat的會話相同，tomcat使用組播技術，只要集羣中一個tomcat節點的session發生改變，會廣播通知全部tomcat節點發生改變。

問題2：據網友測試，當tomcat節點數達到4個以上時候，集羣性能呈線性下滑；另外當用戶訪問量大到必定程度，會話內容隨之增多，tomcat節點相互之間通訊產生大量的網絡消耗，產生網絡阻塞，整個集羣的吞吐量不能再上升。

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

4.一、使用lvs+keepalive實現集羣高可用，達到更健壯的LB
 咱們能夠作前端使用lvs來作負載均衡，根據lvs的8種調度算法(可設置)，分發請求到對應的web服務器集羣上。lvs作雙機熱備，經過keepalived模塊可以達到故障自動轉移到備份服務器，不間斷提供服務，結構如圖2：

 
 說明：據查詢瞭解，通常在WEB端使用的負載均衡比較多的是HAProxy+keepalived+nginx；數據庫mysql集羣使用Lvs+keepalived+mysql實現。由於HAProxy和nginx同樣是工做在網絡7層之上，而且前者彌補了nginx的一些缺點如session的保持，cookie的引導等，且它自己是個負責均衡軟件，處理負載均衡上面必然優於nginx；lvs比較笨重，對於比較龐大的網絡應用實施比較複雜，雖然它運行在網絡4層之上，僅作分發沒有流量產生，可是它不能作正則處理也不能也不能作動靜分離，因此通常用lvs+keepalived或heatbeat作數據庫層的負載均衡。

LVS、HAProxy、Nginx作負載均衡的比較
4.二、使用terracotta或者memcached使session共享
 

 4.2.一、terracotta是jvm級別的session共享

 它基本原理是對於集羣間共享的數據，當在一個節點發生變化的時候，Terracotta只把變化的部分發送給Terracotta服務器，而後由服務器把它轉發給真正須要這個數據的節點，而且共享的數據對象不須要序列化。

 

4.2.二、經過memcached實現內存級session共享

經過memcached-session-manager（msm）插件，經過tomcat上必定的配置，便可實現把session存儲到memcached服務器上。注意：tomcat支持tomcat6+，而且memcached能夠支持分佈式內存，msm同時支持黏性session（sticky sessions）或者非黏性session（non-sticky sessions）兩種模式，在memcached內存中共享的對象須要序列化。結構如圖3：

 

  經過必定的配置，能夠實現故障轉移(只支持對非粘性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：故障轉移節點，對非粘性session不可用。屬性failoverNodes="n1"的做用是告訴msm最好是把session保存在memcached "n2"節點上，只有在n2節點不可用的狀況下才把session保存在n1節點。這樣即便host2上的tomcat宕機，仍然能夠經過host1上的tomcat訪問存放在memcached "n1" 節點中的session。
 
4.2.三、其餘方案
經過cookie保存用戶信息(通常是登陸信息)，每個請求到達web應用的時候，web應用從cookie中取出數據進行處理（這裏儘可能對cookie作加密處理）；
另一種是把用戶信息的關鍵屬性保存到數據庫，這樣就不須要session了。請求過來從數據庫查詢關鍵屬性數據，作相應處理。缺點：加大了數據庫的負載，使數據庫成爲集羣的瓶頸。