負載均衡集群中的session解決方案
前言
在我們給Web站點使用負載均衡之後，必須面臨的一個重要問題就是Session的處理辦法，無論是PHP、Python、Ruby還是Java，只要使用服務器保存Session，在做負載均衡時都需要考慮Session的問題。
分享目錄：
問題在哪裏？如何處理？
會話保持（案例：Nginx、Haproxy）
會話復制（案例：Tomcat）
會話共享（案例：Memcached、Redis）
問題在哪裏？
從用戶端來解釋，就是當一個用戶第一次訪問被負載均衡代理到後端服務器A並登錄後，服務器A上保留了用戶的登錄信息；當用戶再次發送請求時，根據負載均衡策略可能被代理到後端不同的服務器，例如服務器B，由於這臺服務器B沒有用戶的登錄信息，所以導致用戶需要重新登錄。這對用戶來說是不可忍受的。所以，在實施負載均衡的時候，我們必須考慮
在負載均衡中，針對Session的處理，我們一般有以下幾種方法：
Session 保持
Session 復制
Session 共享
會話保持
Session保持（會話保持）是我們見到最多的名詞之一，通過會話保持，負載均衡進行請求分發的時候保證每個客戶端固定的訪問到後端的同一臺應用服務器。會話保持方案在所有的負載均衡都有對應的實現。而且這是在負載均衡這一層就可以解決Session問題。
Nginx 做負載均衡的Session保持
對於Nginx可以選用Session保持的方法實行負載均衡，nginx的upstream目前支持5種方式的分配方式，其中有兩種比較通用的Session解決方法，
ip_hash
每個請求按訪問ip的hash結果分配，這樣每個訪客固定訪問一個後端服務器，達到了Session保持的方法。
例：
upstream bakend {
ip_hash;
server192.168.0.11:80;
server192.168.0.12:80;
}Haproxy做負載均衡的Session保持
Haproxy作為一個優秀的反向代理和負載均衡軟件，也提供了多種Session保持的方法，下面列舉了兩種最常用的：
源地址 Hash
haroxy 將用戶IP經過hash計算後指定到固定的真實服務器上（類似於
配置指令:balancesource
使用cookie 進行識別
也就是Haproxy在用戶第一次訪問的後在用戶瀏覽器插入了一個Cookie，用戶下一次訪問的時候瀏覽器就會帶上這個Cookie給Haproxy，Haproxy進行識別。
配置指令:cookie SESSION_COOKIE insert indirect nocache
配置例子如下：
cookie SERVERID insert indirect nocache server web01 192.168.56.11:8080 check cookie web01 server web02 192.168.56.12:8080 check cookie web02
會話保持的缺點：
會話保持看似解決了Session同步的問題，但是卻帶來的一些其它方面的問題：
負載不均衡了：由於使用了Session保持，很顯然就無法保證負載絕對的均衡。
沒有徹底解決問題：如果後端有服務器宕機，那麽這臺服務器的Session丟失，被分配到這臺服務請求的用戶還是需要重新登錄。
會話復制
既然，我們的目標是所有服務器上都要保持用戶的Session，那麽將每個應用服務器中的Session信息復制到其它服務器節點上是不是就可以呢？這就是Session的第二中處理辦法：會話復制。
會話復制在Tomcat上得到了支持，它是基於IP組播（multicast）來完成Session的復制，Tomcat的會話復制分為兩種：
全局會話復制：利用Delta Manager復制會話中的變更信息到集群中的所有其他節點。
非全局復制：使用Backup Manager進行復制，它會把Session復制給一個指定的備份節點。
不過，這裏我不準備來解釋會話復制的Tomcat配置，如果有需求可以參考Tomcat官方文檔，主要是因為會話復制不適合大的集群。根據筆者在生產的實踐案例，當時是在集群超過6個節點之後就會出現各種問題，不推薦生產使用。
會話共享
既然會話保持和會話復制都不完美，那麽我們為什麽不把Session放在一個統一的地方呢，這樣集群中的所有節點都在一個地方進行Session的存取就可以解決問題。
Session存放到哪裏？
對於Session來說，肯定是頻繁使用的，雖然你可以把它存放在數據庫中，但是真正生產環境中我更推薦存放在性能更快的分布式KV數據中，例如：Memcached和Redis。
PHP設置Session共享
如果你使用的是PHP那麽恭喜你，配置非常的簡單。PHP通過兩行配置就可以把Session存放在Memcached或者Redis中，當然你要提前配置好他們。修改php.ini：
session.save_handler = memcache session.save_path = "tcp://192.168.56.11:11211"
使用Redis存儲Session
session.save_handler = redis session.save_path ="tcp://localhost:6379"
提醒：別忘了給PHP安裝memcache或者redis插件。
Tomcat設置Session共享
我們可以使用MSM（Memcached Session Manager）來實現同樣把Session存放到Memcache中，GIthub地址如下：https://github.com/magro/memcached-session-manager目前支持Tomcat 6.x7.x和8.x的版本。
如果你想使用Redis，剛好也有開源的可以用，但是遺憾的是暫時不支持Tomcat 8.x的版本：https://github.com/jcoleman/tomcat-redis-session-manager
Django設置Session共享
在Django中Session是通過一個中間件管理的。如果要在應用程序中使用Session，需要在settings.py中的MIDDLEWARE_CLASSES變量中加入’django.contrib.sessions.middleware.SessionMiddleware’ 。Django的Session引擎可以將Session存放在三個地方，分別是：數據庫、緩存、文件。
使用數據庫保存Session
如果你想使用數據庫支持的會話，你需要添加‘django.contrib.sessions‘到你的INSTALLED_APPS設置中。在配置完成之後，請運行manage.py migrate來安裝保存會話數據的一張數據庫表。
使用緩存保持Session
對於簡單的緩存會話：
可以設置SESSION_ENGINE 為"django.contrib.sessions.backends.cache"。此時會話數據將直接存儲在你的緩存中。然而，緩存數據將可能不會持久：如果緩存填滿或者緩存服務器重啟，緩存數據可能會被清理掉。
若要持久的緩存數據：
可以設置SESSION_ENGINE為"django.contrib.sessions.backends.cached_db"。它的寫操作使用緩存，對緩存的每次寫入都將再寫入到數據庫。對於讀取的會話，如果數據不在緩存中，則從數據庫讀取。兩種會話的存儲都非常快，但是簡單的緩存更快，因為它放棄了持久性。大部分情況下，cached_db後端已經足夠快，但是如果你需要榨幹最後一點的性能，並且接受會話數據丟失的風險，那麽你可使用cache而不是cached_db
使用文件保存Session
使用文件保存Session不再我們的討論之類，因為很難進行共享，PHP默認也是將Session存放在/tmp目錄下。
本文出自 “王森” 博客，請務必保留此出處http://zhibeiwang.blog.51cto.com/7555525/1965018
負載均衡集群中的session解決方案