負載均衡下，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就這樣一直登錄，一直被提示未登錄，這樣肯定行不通。

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

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

  1、 session復制：看到標題，顧名思義就是復制session的意思，繼續引用上面的例子來說明，當user訪問應用時，第一次被負載均衡到了 tomcatA，tomcatA給用戶分為一個session的同時，會向tomcatB同時復制一份，這樣當user下次訪問應用時，即使被負載均衡到了tomcatB，tomcatB上也會有相對應的session信息。但缺點也顯而易見，試想一下，當我們采用很多tomcat進行負載時，每次一個 user訪問時，產生的session都會復制到其他tomcat上面。很容易造成大量的網絡通信，這樣的效率會低很多。

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

2、terracotta : 是由terracotta公司生產的用于集群間共享數據的工具，可以應用于session同步。即tomcatA與tomcatB各節點中的session 信息全部交由terracotta統一管理。且支持容災處理。

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

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

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

4、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上。