一. 何爲session
用戶使用網站的服務，基本上需要瀏覽器和web服務器進行多次交互，web服務器如何知道哪些請求是來自哪個會話的？
具體方式爲：在會話開始時，分配一個唯一的會話標識(sessionId)，通過cookie把這個標識告訴瀏覽器，以後每次請求的時候，瀏覽器都會帶上這個會話標識來告訴web服務器請求是屬於哪個會話的。如果遇到禁用cookie的情況，一般的做法就是把這個會話標識放到url的參數中。
二. 問題
因爲會話信息保存在單機上，當我們的應用服務器從一臺變成兩臺後，我們就會遇到session的問題了！
如下圖所示，當我們第一次訪問網站時請求落到了左邊的服務器，那麼我的session就創建在左邊的服務器上了，如果我們不做處理，就不能保證接下來的請求每次都落在同一邊的服務器上了，這就是session問題。
三. 解決辦法
- session sticky
在web服務器變成多臺後，如果我們可以保證同一個會話請求都能在同一個web服務器上處理，那麼對於這個會話個體來說，和單機的情況是一樣的。這就需要負載均衡器能夠根據每次請求的會話標識來進行請求轉發。
有何問題：
① 如果有一臺web服務器宕機或重啓，那麼這臺機器上的會話數據會丟失
② 負載均衡器變成了一個有狀態的結點，要保存會話到具體web服務器的映射，要消耗一定的內存。
2. session replication
web服務器之間增加了會話數據的同步，通過同步就保證了不同web服務器之間的session數據一致，一般的應用容器都支持這種方式。
問題：
① 只要session數據有變化，就需要將數據同步到其他機器上，會帶來一定的網絡帶寬開銷
② 每臺web服務器都要保存所有的session數據，如果整個集羣session數很多的話，對內存資源消耗較大。
該方案不適合集羣機器較多的場景。
3. session數據集中存儲
把session數據集中存儲起來，然後不同的web服務器從相同的地方來獲取session，存儲session數據的方式可以爲數據庫，也可以使用其他分佈式存儲系統。
問題：
① 獲取session存在延時和不穩定性，不過我們的通信基本在內網，問題不大。
② 如果存儲session的機器或集羣發生問題，就會影響到應用。
當集羣規模較大時，session數較多時，該方案可以考慮。
4. cookie based
該方案通過cookie來傳遞session數據，即把session數據存在cookie中
問題：
① cookie有長度限制，這也就會限制session數據的長度
② 安全性，cookie的數據保存在客戶端，這就存在安全性的問題，我們需要對寫入cookie的session數據做加密處理
③ 帶寬消耗， 客戶端每次都要帶着session過來，會消耗一定網絡資源
④ 性能影響，每次http請求和響應都帶有session數據，對web服務器來說，在同樣的處理情況下，響應的結果輸出越少，支持的併發請求就會越多。
綜上方案都是解決session問題的方案，對於大型網站來說，session sticky和session集中管理是比較好的方案。