-
(1) 應用服務器間的session複製共享(如tomcat session共享)
- (2) 基於cache DB緩存的session共享
目前,爲了使web能適應大規模的訪問,須要實現應用的集羣部署. 而實現集羣部署首先要解決session的統一,即須要實現session的共享機制。nginx
目前,在集羣系統下實現session統一的有以下幾種方案:web
session複製共享,主要是指集羣環境下,多臺應用服務器之間同步session,使session保持一致,對外透明。 若是其中一臺服務器發生故障,根據負載均衡的原理,web服務器(apache/nginx)會遍歷尋找可用節點,分發請求,因爲session已同步,故能保證用戶的session信息不會丟失。redis
此方案的不足之處:apache
即便用cacheDB存取session信息,應用服務器接受新請求將session信息保存在cache DB中,當應用服務器發生故障時,web服務器(apache/nginx)會遍歷尋找可用節點,分發請求,當應用服務器發現session不在本機內存時,則去cache DB中查找,若是找到則複製到本機,這樣實現session共享和高可用。緩存
目前有開源的msm用於解決tomcat之間的session共享:Memcached_Session_Manager(MSM)tomcat
http://code.google.com/p/memcached-session-manager/
一個高可用的Tomcat session共享解決方案,除了能夠從本機內存快速讀取Session信息(僅針對黏性Session)外,同時可以使用memcached存取Session,以實現高可用。服務器
該方案的不足之處:網絡
爲了解決基於memcache中存在的不足,故提出了下面的一種解決方案:session
結合上面的 MSM 思想,由 redis負責 session 數據的存儲,而咱們本身實現的 session manager 將負責 session 生命週期的管理。數據結構
通常的系統架構:
此架構存在着當redis master故障時, 雖然能夠有一到多個備用slave,可是redis不會主動的進行master切換,這時session服務中斷。
爲了作到redis的高可用,引入了haproxy或者keepalived來解決redis master slave的切換問題。即:
此體系結構中, redis master出現故障時, 經過haproxy設置redis slave爲臨時master, redis master從新恢復後, 再切換回去. 此方案中, redis-master 與redis-slave 是雙向同步的, 解決目前redis單點問題. 這樣保證了session信息在redis中的高可用。
實現此方案:
nginx 1 192.168.1.102
tomcat1 1
tomcat2 1
redis-master 1
redis-slave 1
slave1 1
slave2 1
haproxy vip 1