mem pro 操作 資源 white 也有 分布式 ntc popu

隨著站點的功能越來越多，用戶量越來越龐大，單節點模式已經嚴重不能支撐整個系統的正常運作，輕則用戶頁面訪問時間越來越慢。重則就會導致整個系統癱瘓。這時候

就須要優化或調整眼下的架構，大部分人就會採用各種負載均衡軟件比如nginx、hproxy、LVS等，也有的採用分布式的方式把系統依據功能拆分成非常多系統，也有的依據地域

和網絡不同來實現訪問不同節點部署的系統。也有的大型高流量、高負載的系統把負載均衡、分布式及依據地域、網絡等這些方式都整合在一起來實現系統的正常執行。

採用負載均衡軟件是眼下大家採取的比較多的方式。可是在採用負載均衡軟件時將會面臨session同步的問題。

下面是解決這個問題的幾種方式。

1. clientcookie加密的方式

把session數據存放在cookie中，當請求過來時。從cookie中獲取session數據。這樣的方式不須要不論什麽的存儲系統。也不會出現讀寫session數據帶來的網絡操作延時和不穩定性。

可是有下面缺點：

* Cookie有長度限制，這會影響session數據的長度。

* 安全性。

session數據本來存儲在服務端的，而這個方法是讓session數據轉到外部網絡或client中。所以會有安全性問題。只是能夠對寫入Cookie的session 數據做加密。

* 帶寬消耗。因為加了session數據。帶寬當然也會添加一點。

* 性能消耗。每次Http請求和響應都帶有Session數據。對於Webserver來說，在相同的處理情況下，響應的結果輸出越少，支持的並發請求越。

2. web server的session復制方式

大部分應用server都提供了session復制的功能來實現集群。tomcat、jboss、was都提供了這種功能。session復制就是每臺應用服務。都保存會話session數據。

長處：

靠應用容器來完畢session共享，並不依賴應用。假設應用服務數量並非非常多，能夠考慮。

缺點：

* 同步session數據帶來都網絡開銷。

僅僅要session數據變化，就須要同步到全部機器上，機器越多，網絡開銷越大。

* 因為每臺server都保存session數據，假設集群的session數據非常多。比方90萬人在訪問站點。每臺機器用於保存session數據的內容占用非常嚴重。

3. 使用關系數據庫保存session

用mysql、sqlserver等數據庫保存session,就算服務器宕機了也沒事，session照樣在。

缺點：

*程序須要定制。
*每次請求都進行數據庫讀寫開銷不小(使用內存數據庫能夠提高性能，宕機就會丟失數據。

可供選擇的內存數據庫有BerkeleyDB,Mysql的內存表);

4.使用nosql數據庫保存session

採用redis、mongodb、memcached等非關系數據庫來實現session的共享。這些非關系數據庫響應數據非常的快，並且支持的訪問量也比較大。系統資源消耗也比較少。這也是非常多系統所採用的方式。

可是也有缺點：

* 讀寫session引入了網絡操作。相對於本機讀寫session，帶來了延時和不穩定性。

* 如Session集中服務有問題，會影響應用。

5.採用Session Stick

在單機情況。session保存在單機上，請求也是到這臺單機上，不會有問題。變成多臺後，假設能保障每次請求都到同一臺服務。那就和單機一樣了。 這須要在負載均衡設備上改動。這就是Session Stick。這樣的方式也會有問題：

* 假設某一臺server宕機或重新啟動。那麽這臺server上的session數據就丟失了。假設session數據中還有登錄狀態信息。那麽用戶須要重現登錄。

* 負載均衡要處理詳細的session到server的映射。

6.使用terracotta來保存session

跟memcached類似，可是數據不須要序列化。並且是Find-Grained Changes。性能更好。

配置對原來的應用全然透明，原有程序差點兒不用做不論什麽改動。並且terracotta本身支持HA。

綜上所述。我個人推薦使用第4、6種方式來解決session共享的問題。

web集群中經常使用的session同步解決方式及對照