三、小結
當我們的應用伺服器從一台變成兩台後，我們就會遇到session問題，當乙個帶有會話標識的http請求到了web伺服器後，需要在http請求的處理過程中找到對應的會話資料（session）。而問題在於資料是需要儲存在單機上的。如下圖所示，如果第一次訪問**是請求落到了左邊的應用伺服器上，那麼我的session就建立在左邊的伺服器上了，如果我們不做處理，就不能保證接下來的請求每次都落在同一邊的伺服器上了，這就是session問題。
這種方案本身非常簡單，對於web伺服器來說，該方案和單機的情況是一樣的，只是我們在負載均衡伺服器上做了「手腳」。這個方案可以讓同樣的session請求每次都傳送到同一伺服器，非常利於session進行伺服器端的快取。簡單來說就是將每個session與具體的應用伺服器「繫結」，乙個session內的請求只發到對應的伺服器上。
這種方式存在的問題：
打個比方來說，web伺服器是我們每次吃飯的飯店，會話資料是我們的碗筷。要保證每次吃飯都用的是自己的碗筷的話，session sticky這種方式就類似於把碗筷放在某一家飯店，並且每次都是去這家吃。
模擬到飯店吃飯，我們可以在每個飯店都放一副碗筷，那我們到哪個飯店吃都可以。這種方式不要求負載均衡伺服器來保證同乙個會話的多次請求必須到同乙個伺服器上，而web服務上多了同步session到其他集群伺服器上的操作。這樣就能保證web伺服器之間的session一致性了。當然這種方式也存在著問題：
這個方案是靠應用伺服器複製session內容來解決session問題，但是不太適用集群機器數較多的場景，如果只有幾台機器，用這個方案是可以的。
這種方案是把session資料集中儲存起來，然後不同的web伺服器從同樣的地方來獲取伺服器。儲存session資料的方式，可以用資料庫，也可以用其他的分布式儲存系統。這個方案解決了session replication方案中的記憶體問題，對網路頻寬比也較好。那這種方案存在的問題是什麼呢？
當web伺服器數量較大，session數量較多的時候，集中儲存session方式的優勢非常明顯。
cookie based方式是最後一種方案，這個方案對於同乙個會話的不同請求也不限制具體的處理伺服器。具體實現是將session資料放在cookie中，然後web伺服器從cookie中生成對應的session資料。這就好比我每次都把自己的碗筷帶在身上，這樣無論我去哪家飯店吃飯都可以了。相比前面幾種方案，這個方案不會依賴外部的儲存系統，也不存在從外部系統獲取、寫入session資料的時延和不穩定行了。當然了，同樣存在不足：
這4種方案都是可用的方案，不過對於大型**來說session sticky和session資料集中儲存是比較好的方案，而這兩個方案又各有優劣，需要在具體的場景中做出選擇和權衡。
解決應用伺服器集群後session問題
一.何為session 使用者使用 的服務，基本上需要瀏覽器和web伺服器進行多次互動，web伺服器如何知道哪些請求是來自哪個會話的？具體方式為 在會話開始時，分配乙個唯一的會話標識 sessionid 通過cookie把這個標識告訴瀏覽器，以後每次請求的時候，瀏覽器都會帶上這個會話標識來告訴web...
應用伺服器集群Session管理
應用伺服器的高可用架構設計主要基於服務無狀態這一特性，但事實上，業務總是有狀態的，在交易類的電子商務 需要有購物車記錄使用者的購買記錄，使用者每次購買請求都是向購物車中增加商品來社交類 中，需要記錄使用者當前登陸狀態 最新發布的訊息及好友狀態等，使用者每次重新整理頁面都需要更新這些資訊。web應用中...
應用伺服器集群的session管理
首先，我們知道，http是無狀態的協議，應用伺服器不儲存業務的上下文資訊，而是進根據每次提交的資料進行相應的業務邏輯處理，因此所有的服務期完全對等，乙個請求由哪個伺服器來處理都是一樣的。因此，為了保證 的高可用，我們可以部署多個web伺服器，通過負載均衡的手段來緩解伺服器壓力 同時乙個伺服器掛掉了，...