一、緣起
什麼是session？
伺服器為每個使用者建立乙個會話，儲存使用者的相關資訊，以便多次請求能夠定位到同乙個上下文。
web開發中，
web-server
可以自動為同乙個瀏覽器的訪問使用者自動建立
session
，提供資料儲存功能。最常見的，會把使用者的登入資訊、使用者資訊儲存在
session
中，以保持登入狀態。
什麼是session
一致性問題？
只要使用者不重啟瀏覽器，每次
短連線請求，理論上服務端都能定位到
session
，保持會話。
當只有一台
web-server
提供服務時，每次
短連線請求，都能夠正確路由到儲存
session
的對應web-server
（廢話，因為只有一台）。
此時的web-server
是無法保證高可用的，採用「冗餘
+故障轉移」的
多台web-server
來保證高可用時，每次
短連線請求就不一定能路由到正確的
session了。
如上圖，假設使用者包含登入資訊的
session
都記錄在第一台
web-server
上，反向**如果將請求路由到另一台
web-server
上，可能就找不到相關資訊，而導致使用者需要重新登入。 在
web-server
高可用時，如何保證
session
路由的一致性，是今天將要討論的問題。 二、
session
同步法
思路：多個
web-server
之間相互同步
session
，這樣每個
web-server
之間都包含全部的
session 優點
：web-server
支援的功能，應用程式不需要修改**
不足：
三、客戶端儲存法
思路：服務端儲存所有使用者的
session
，記憶體占用較大，可以
將session
儲存到瀏覽器
cookie
中，每個端只要儲存乙個使用者的資料了 優點
：服務端不需要儲存 缺點
：
「端儲存」的方案雖然不常用，但確實是一種思路。
三、反向**
hash
一致性 思路：
web-server
為了保證高可用，有多台冗餘，反向**層能不能做一些事情，讓
同乙個使用者的請求保證落在一台
web-server上呢？
方案一：四層**
hash
反向**層使用
使用者ip
來做hash
，以保證同乙個
ip的請求落在同乙個
web-server
上
方案二：七層**
hash
反向**使用
協議中的
某些業務屬性來做
hash
，例如sid
，city_id
，user_id
等，能夠更加靈活的實施
hash
策略，以保證同乙個瀏覽器使用者的請求落在同乙個
web-server上
優點：
不足：
session
一般是有有效期的，所有不足中的兩點，可以認為等同於部分
session
失效，一般問題不大。
對於四層
hash
還是七層
hash
，個人推薦前者
：讓專業的軟體做專業的事情，反向**就負責**，盡量不要引入應用層業務屬性，除非不得不這麼做（例如，有時候多機房多活需要按照業務屬性路由到不同機房的
web-server）。
四、後端統一儲存
將session
儲存在web-server
後端的儲存層
，資料庫或者快取 優點
：
不足：增加了一次網路呼叫，並且需要修改應用** 對於
db儲存還是
cache
，個人推薦後者
：session
讀取的頻率會很高，資料庫壓力會比較大。如果有
session
高可用需求，
cache
可以做高可用，但大部分情況下
session
可以丟失，一般也不需要考慮高可用。
五、總結 保證
session
一致性的架構設計常見方法：
對於方案
3和方案
4，個人建議推薦後者：
架構師之路 3 session一致性架構設計實踐
一 緣起 什麼是session？伺服器為每個使用者建立乙個會話，儲存使用者的相關資訊，以便多次請求能夠定位到同乙個上下文。web開發中，web server 可以自動為同乙個瀏覽器的訪問使用者自動建立 session 提供資料儲存功能。最常見的，會把使用者的登入資訊 使用者資訊儲存在 session...
系統架構師成長之路（一）
背景 系統架構師是近幾年來在國內外迅速成長並發展良好的乙個職業，它對系統開發和資訊化建設的重要性及給it業所帶來的影響是不言而喻的。在我國，雖然系統架構師的職業在工作內容 工作職責以及工作邊界等方面還存在一定的模糊性和不確定性，但它確實是時代發展的需要，並正在實踐中不斷完善和成熟。通常從組織上劃分，...
系統架構師成長之路（一）
背景 系統架構師是近幾年來在國內外迅速成長並發展良好的乙個職業，它對系統開發和資訊化建設的重要性及給it業所帶來的影響是不言而喻的。在我國，雖然系統架構師的職業在工作內容 工作職責以及工作邊界等方面還存在一定的模糊性和不確定性，但它確實是時代發展的需要，並正在實踐中不斷完善和成熟。通常從組織上劃分，...