建站
咨詢
售后
建站咨詢
新聞中心
在日常運維工作中，當(dāng)給Web站點使用負(fù)載均衡之后，必須面臨的一個重要問題就是Session的處理辦法，無論是PHP、Python、Ruby還是Java語言環(huán)境，只要使用服務(wù)器保存Session，在做負(fù)載均衡時都需要考慮Session的問題。
創(chuàng)新互聯(lián)-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價比普定網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式普定網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋普定地區(qū)。費用合理售后完善，10年實體公司更值得信賴。
通常面臨的問題
從用戶端來解釋，就是當(dāng)一個用戶第一次訪問被負(fù)載均衡代理到后端服務(wù)器A并登錄后，服務(wù)器A上保留了用戶的登錄信息；當(dāng)用戶再次發(fā)送請求時，
根據(jù)負(fù)載均衡策略可能被代理到后端不同的服務(wù)器，例如服務(wù)器B，由于這臺服務(wù)器B沒有用戶的登錄信息，所以導(dǎo)致用戶需要重新登錄。這對用戶 來說是不可忍受的。所以，在實施負(fù)載均衡的時候，我們必須考慮Session的問題。
在負(fù)載均衡中，針對Session的處理，一般有以下幾種方法：
1）Session會話保持（案例：Nginx、Haproxy）
2）Session會話復(fù)制（案例：Tomcat）
3）Session會話共享（案例：Memcached、Redis）
一、Session會話保持
Session保持（會話保持）是我們見到最多的名詞之一，通過會話保持，負(fù)載均衡進(jìn)行請求分發(fā)的時候保證每個客戶端固定的訪問到后端的同一臺應(yīng)用服務(wù)器。
會話保持方案在所有的負(fù)載均衡都有對應(yīng)的實現(xiàn)。而且這是在負(fù)載均衡這一層就可以解決Session問題。
================Nginx 做負(fù)載均衡的Session保持================
對于Nginx可以選用Session保持的方法實行負(fù)載均衡，nginx的upstream目前支持5種方式的分配方式，其中有兩種比較通用的Session解決方法，ip_hash和url_hash。
注意：后者不是官方模塊，需要額外安裝。
ip_hash
每個請求按訪問ip的hash結(jié)果分配，這樣每個訪客固定訪問一個后端服務(wù)器，達(dá)到了Session保持的方法。
例：
upstream bakend {
ip_hash;
server192.168.0.11:80;
server192.168.0.12:80;
}
================Haproxy做負(fù)載均衡的Session保持================
Haproxy作為一個優(yōu)秀的反向代理和負(fù)載均衡軟件，也提供了多種Session保持的方法，下面列舉了兩種最常用的：
1) 源地址 Hash
haroxy 將用戶IP經(jīng)過hash計算后指定到固定的真實服務(wù)器上（類似于nginx 的ip hash 指令）
配置指令:balancesource
2)使用cookie 進(jìn)行識別
也就是Haproxy在用戶第一次訪問的后在用戶瀏覽器插入了一個Cookie，用戶下一次訪問的時候瀏覽器就會帶上這個Cookie給Haproxy，Haproxy進(jìn)行識別。
配置指令: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
會話保持的缺點：
1) 會話保持看似解決了Session同步的問題，但是卻帶來的一些其它方面的問題：
2）負(fù)載不均衡了：由于使用了Session保持，很顯然就無法保證負(fù)載絕對的均衡。
3）沒有徹底解決問題：如果后端有服務(wù)器宕機，那么這臺服務(wù)器的Session丟失，被分配到這臺服務(wù)請求的用戶還是需要重新登錄。
二、Session會話保持
既然，我們的目標(biāo)是所有服務(wù)器上都要保持用戶的Session，那么將每個應(yīng)用服務(wù)器中的Session信息復(fù)制到其它服務(wù)器節(jié)點上是不是就可以呢？ 這就是Session的第二中處理辦法：會話復(fù)制。
會話復(fù)制在Tomcat上得到了支持，它是基于IP組播（multicast）來完成Session的復(fù)制，Tomcat的會話復(fù)制分為兩種：
1）全局會話復(fù)制：利用Delta Manager復(fù)制會話中的變更信息到集群中的所有其他節(jié)點。
2）非全局復(fù)制：使用Backup Manager進(jìn)行復(fù)制，它會把Session復(fù)制給一個指定的備份節(jié)點。
不過，這里不準(zhǔn)備來解釋會話復(fù)制的Tomcat配置，如果有需求可以參考Tomcat官方文檔，主要是因為會話復(fù)制不適合大的集群。根據(jù)生產(chǎn)的實踐案例， 在集群超過6個節(jié)點之后就會出現(xiàn)各種問題，不推薦生產(chǎn)使用。
三、Session會話共享
既然會話保持和會話復(fù)制都不完美，那么我們?yōu)槭裁床话裇ession放在一個統(tǒng)一的地方呢，這樣集群中的所有節(jié)點都在一個地方進(jìn)行Session的
Session存放到哪里？
對于Session來說，肯定是頻繁使用的，雖然你可以把它存放在數(shù)據(jù)庫中，但是真正生產(chǎn)環(huán)境中我更推薦存放在性能更快的分布式KV數(shù)據(jù)中，
例如：Memcached和Redis。
PHP設(shè)置Session共享
如果使用的是PHP那么恭喜你，配置非常的簡單。PHP通過兩行配置就可以把Session存放在Memcached或者Redis中，當(dāng)然你要提前配置好他們。修改php.ini：
使用Memcache存儲Session
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設(shè)置Session共享
可以使用MSM（Memcached Session Manager）來實現(xiàn)同樣把Session存放到Memcache中。
Django設(shè)置Session共享
在Django中Session是通過一個中間件管理的。如果要在應(yīng)用程序中使用Session，需要在settings.py中的MIDDLEWARE_CLASSES變量中加入
'django.contrib.sessions.middleware.SessionMiddleware' 。Django的Session引擎可以將Session存放在三個地方，分別是：數(shù)據(jù)庫、緩存、文件。
如果你想使用數(shù)據(jù)庫支持的會話，你需要添加’django.contrib.sessions’到你的INSTALLED_APPS設(shè)置中。在配置完成之后，請運行manage.py migrate 來安裝保存會話數(shù)據(jù)的一張數(shù)據(jù)庫表。
使用緩存保持Session
對于簡單的緩存會話：
可以設(shè)置SESSION_ENGINE 為”django.contrib.sessions.backends.cache”。此時會話數(shù)據(jù)將直接存儲在你的緩存中。然而，緩存數(shù)據(jù)將可能不會持久：
如果緩存填滿或者緩存服務(wù)器重啟，緩存數(shù)據(jù)可能會被清理掉。
若要持久的緩存數(shù)據(jù)：
可以設(shè)置SESSION_ENGINE為”django.contrib.sessions.backends.cached_db”。它的寫操作使用緩存，對緩存的每次寫入都將再寫入到數(shù)據(jù)庫。對于
讀取的會話，如果數(shù)據(jù)不在緩存中，則從數(shù)據(jù)庫讀取。兩種會話的存儲都非?？?，但是簡單的緩存更快，因為它放棄了持久性。大部分情況下，cached_db后端已經(jīng)足夠快，但是如果你需要榨干最后一點的性能，并且接受會話數(shù)據(jù)丟失的風(fēng)險，那么你可使用cache而不是cached_db
使用文件保存 使用文件保存Session不再我們的討論之類，因為很難進(jìn)行共享，PHP默認(rèn)也是將Session存放在/tmp目錄下。
簡單總結(jié)：
會話保持的缺點：負(fù)載不均衡;沒有徹底解決問題. 會話復(fù)制的缺點：集群超過6個節(jié)點就會出現(xiàn)一系列的問題. 會話共享：會話數(shù)據(jù)共享在Nosql（Redis）數(shù)據(jù)庫中分享。
當(dāng)前標(biāo)題：負(fù)載均衡集群的session處理方案
轉(zhuǎn)載來源：http://www.5511xx.com/article/cdecosh.html
