寫在前面 最近在讀一本來自淘寶技術團隊大牛的書，名字叫《大型網站系統與Java中間件實踐》。開篇的章節詳細地介紹了一個網站架構由小變大不斷演進的過程，其中從單機架構升級到集群架構的過程中著重介紹了關於session同步問題， 這也是很多人在聊到分散式時繞不過去的話題。下麵就整理下書中的內容，也算是做 ...
寫在前面
最近在讀一本來自淘寶技術團隊大牛的書，名字叫《大型網站系統與Java中間件實踐》。開篇的章節詳細地介紹了一個網站架構由小變大不斷演進的過程，其中從單機架構升級到集群架構的過程中著重介紹了關於session同步問題， 這也是很多人在聊到分散式時繞不過去的話題。下麵就整理下書中的內容，也算是做個讀書筆記，方便以後參考。
問題從哪來
做web開發的同學應該對session再熟悉不過，它是伺服器分配給客戶端的會話標識，瀏覽器每次請求會帶上這個標識來告訴伺服器我是誰，伺服器會在記憶體中存儲這些不同的會話信息，由此來分辨請求來自哪個會話。在單機部署的環境總，因為web伺服器和session都是在同一臺機器上，所以必然能找到對應的會話數據。但如果有2台web伺服器（A和B）提供服務，假如第一次請求落到A上並創建了session，那麼如何保證下次落到B的請求能讀到session數據？
解決方案
有以下4中常見的解決方案。
1、Session Sticky
這是最簡單粗暴的 方法，核心思路就是讓同一會話的請求都落地到同一臺伺服器上，這樣處理起來就和單機一樣了，我們可以在負載均衡上做一些身份識別並控制轉發來達到這個目的。這樣做的優勢是能像單機一樣簡化對session處理，也方便做本地緩存，但缺點也是很明顯的：
-
如果這台伺服器宕機或重啟了，那麼所以的會話數據都會丟失，失去了分散式集群帶來的高可用特性。
-
增加了負載均衡器的負擔，使它變得有狀態了，而且資源消耗會更大，容易成為性能瓶頸。
2、Session Replication
顧名思義，這是一種session複製的方案，核心思路就是通過在伺服器之間增加session同步機制來保證數據一致。
看起來比第一種簡單了很多，也沒有第一種帶來的缺陷，但在某些應用場景下還是會有比較嚴重的問題：
-
伺服器之間的數據同步帶來了額外的網路消耗，隨著機器數量和數據量的上升，網路帶寬將會有很大的壓力，也必然會帶來延時問題。
-
每台伺服器上都要存儲所有的會話數據，如果會話數量很大會占用伺服器大部分記憶體空間。
目前很多應用容器都支持這種同步方式，所以在集群規模和數據量比較小的時候還是一種很好的解決方案。
3、Session集中存儲
這種方式的思路就是把所有的會話數據統一存儲和管理，所有應用伺服器需要對session進行讀寫都要通過session伺服器來操作：
這種方案的好處是獨立了session的管理，職責單一化，session伺服器採用什麼方式存儲（記憶體、資料庫、文檔、NoSql等等），什麼方式對外提供服務都是透明的。不會給應用系統和負載均衡帶來額外的開銷，不需要進行數據同步就能保證一致性，看起來應該是非常完美了，不過也有自己的一些小缺陷：
-
對session讀寫需要網路操作，相比較session直接存儲在web伺服器的時候增加了時延和不穩定性，好在session伺服器和web伺服器一般是部署在區域網中，可以最大化減少這個問題。
-
session伺服器出現問題將影響所有web服務，如果採用多機部署同時也會帶來數據一致性問題。
每種方案帶有它獨特的優勢，同時也會帶來相應的新問題，正所謂沒有十全十美，只有適合才是最好的。總體來說，這種方案在應用伺服器和會話數據量都很大的時候還是非常有優勢的。
4、Cookie Base
這種方案是基於cookie的傳輸來實現的，核心思想很簡單，就是把完整的會話數據經過處理後寫入到客戶端cookie，以後客戶端每次請求都帶上這個cookie，然後服務端通過解析cookie數據來獲取會話信息，如下圖所示：
這種方案簡單明瞭，也沒有前面幾種方案帶來的問題，但劣勢也非常明顯：
-
首先通過cookie來傳遞關鍵數據肯定是不安全的，即便是採用了特殊的加密手段。
-
如果客戶端禁用了cookie，將直接導致服務不可用。
-
cookie的數據是有大小限制的，如果傳遞的數據超出限制大小，將會導致數據異常。
-
在http請求中攜帶大量的數據進行傳輸會增加網路負擔，同樣，服務端響應大量數據會導致請求變慢，併發量大的時候會非常可怕。
總結
以上4種方案都是可行的方案，正如前面所說，每種方案各有優劣，不會十全十美，實際應用中要根據需求做權衡和取捨。這些都是屬於比較通用的方案，我相信在真正的實踐和落地過程中還會有其他問題出現，有經驗的過來人或許會有一些另闢蹊徑的“套路”，歡迎討論交流。
