負載均衡下，WEB集羣session管理

    一般情況下，在部署項目時，咱們會考慮訪問量太高帶來的一系列問題，解決這個問題的一種作法是，使用WEB集羣來分佈式部署項目，即負載均衡。負載均衡能夠經過軟件，硬件等多種方式去實現。下面說說這個方法的區別。

      軟件實現的負載均衡：這一類的軟件經常使用的有nginx，這裏也能夠將nginx看作成一個網關，一般一個nginx最多能夠配置6個tomcat。nginx實現原理就是在中間層做爲一個網關，而後地址轉發到不一樣的tomcat(注：每一個tomcat都擁有一個惟一的端口號)。優勢是性價比高，並且能夠根據系統與應用的情況來分配負載。

     硬件實現的負載均衡：硬件實現的負載均衡，一般須要一個服務器集羣，加上一個負載的服務器。冗餘較高。從而帶來成本的上升，並且對於負載的服務器來講，一旦出現問題，整個應用就會癱瘓掉，硬件負載只會關注網絡層情況，而不會像軟件負載同樣能夠根據系統與應用的情況去靈活分配負載。

   簡單的介紹了負載均衡的簡單概念後，在實際應用的時候，咱們一般會遇到session保持的問題，舉個簡單的例子，以tomcat爲例，咱們都知道session存在於服務器端，對於不是分佈式部署，整個系統的session都會是這惟一的服務器來管理。這點沒問題。可是對於分佈式部署來講，假設有tomcatA與tomcatB，但用戶user訪問系統時，經過負載均衡，此user訪問了位於tomcatA上的應用。系統給此用戶分配了一個session來標識用戶身份，並返回sessionID給瀏覽器。這時user又向服務器發送個請求。假設這時候負載均衡到了tomcatB，可是此時tomcatB上並無存有user相應的session信息。根據通常應用的設置，會提示user從新登陸，試想下user就這樣一直登陸，一直被提示未登陸，這樣確定行不通。

    在實際應用中，有不少解決這種問題的方法，下面來介紹幾種解決方法及其優勢與弊端。

------------------------------------------------------------------------------------------------------------------------------------

  一、 session複製：看到標題，顧名思義就是複製session的意思，繼續引用上面的例子來講明，當user訪問應用時，第一次被負載均衡到了tomcatA，tomcatA給用戶分爲一個session的同時，會向tomcatB同時複製一份，這樣當user下次訪問應用時，即便被負載均衡到了tomcatB，tomcatB上也會有相對應的session信息。但缺點也顯而易見，試想一下，當咱們採用不少tomcat進行負載時，每次一個user訪問時，產生的session都會複製到其餘tomcat上面。很容易形成大量的網絡通訊，這樣的效率會低不少。

------------------------------------------------------------------------------------------------------------------------------------

二、terracotta : 是由terracotta公司生產的用於集羣間共享數據的工具，能夠應用於session同步。即tomcatA與tomcatB各節點中的session 信息所有交由terracotta統一管理。且支持容災處理。

------------------------------------------------------------------------------------------------------------------------------------

三、粘性session ： 仍是用上面的例子，當user訪問應用的時候，被轉發到了tomcatA上，這時候使用粘性session，當user下次在訪問應用時，會被負載均衡到同一節點上，即tomcatA。這樣就很簡單的實現了session保持的問題。可是session粘性不具有容災處理，因此當某個tomcat掛掉後，這臺tomcat上管理的全部session信息都會失效。

-------------------------------------------------------------------------------------------------------------------------------------

四、nginx中的ip_hash:

         在官網上能夠看到這樣的解釋：

This directive causes requests to  be distributed between upstreams based on the IP-address of the client.
The key for the hash is the class-C network address or the entire IPv6-address of the client. IPv6 is supported for ip_hash since 1.3.2 or 1.2.2. This method guarantees that the client request will always be transferred to the same server. But if this server is considered inoperative, then the request of this client will be transferred to another server. This gives a high probability clients will always connect to the same

         大體意思爲：將客戶IP化轉化爲c類網絡地址，而後將這網絡地址做爲hash關鍵字，來保證這個客戶的請求老是被轉發到一臺服務器上。

         該類方法實現的前提是使用nginx來作負載均衡，當咱們配置ip_hash時，user去訪問應用，假設會被nginx轉發到tomcatA上，當下次去訪問應用時，nginx會根據ip轉化爲的網絡地址做爲  hash 關鍵字來識別是不是同一用戶。這樣user又會被轉發到tomcatA上。

上面提到的四種解決辦法，你們能夠根據實際狀況來選取對應的方法。歡迎你們補充。。。