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

標籤：ebs   strong   讀寫   限制   負載平衡   網路操作   頁面   會話   響應   

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

就須要最佳化或調整眼下的架構，大部分人就會採用各種負載平衡軟體比如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同步解決方式及對照