session一致性架構設計實踐

原創： 58沈劍 架構師之路 2017-05-18

一、緣起

什麼是session？

伺服器為每個使用者建立一個會話，儲存使用者的相關資訊，以便多次請求能夠定位到同一個上下文。

Web開發中，web-server可以自動為同一個瀏覽器的訪問使用者自動建立session，提供資料儲存功能。最常見的，會把使用者的登入資訊、使用者資訊儲存在session中，以保持登入狀態。

什麼是session一致性問題？

只要使用者不重啟瀏覽器，每次http短連線請求，理論上服務端都能定位到session，保持會話。

當只有一臺web-server提供服務時，每次http短連線請求，都能夠正確路由到儲存session的對應web-server（廢話，因為只有一臺）。

此時的web-server是無法保證高可用的，採用“冗餘+故障轉移”的多臺web-server來保證高可用時，每次http短連線請求就不一定能路由到正確的session了。

如上圖，假設使用者包含登入資訊的session都記錄在第一臺web-server上，反向代理如果將請求路由到另一臺web-server上，可能就找不到相關資訊，而導致使用者需要重新登入。

在web-server高可用時，如何保證session路由的一致性，是今天將要討論的問題。

二、session同步法

思路：多個web-server之間相互同步session，這樣每個web-server之間都包含全部的session

優點：web-server支援的功能，應用程式不需要修改程式碼

不足：

• session的同步需要資料傳輸，佔內網頻寬，有時延

• 所有web-server都包含所有session資料，資料量受記憶體限制，無法水平擴充套件

• 有更多web-server時要歇菜

三、客戶端儲存法

思路：服務端儲存所有使用者的session，記憶體佔用較大，可以將session儲存到瀏覽器cookie中，每個端只要儲存一個使用者的資料了

優點：服務端不需要儲存

缺點：

• 每次http請求都攜帶session，佔外網頻寬

• 資料儲存在端上，並在網路傳輸，存在洩漏、篡改、竊取等安全隱患

• session儲存的資料大小受cookie限制

“端儲存”的方案雖然不常用，但確實是一種思路。

三、反向代理hash一致性

思路：web-server為了保證高可用，有多臺冗餘，反向代理層能不能做一些事情，讓同一個使用者的請求保證落在一臺web-server上呢？

方案一：四層代理hash

反向代理層使用使用者ip來做hash，以保證同一個ip的請求落在同一個web-server上

方案二：七層代理hash

反向代理使用http協議中的某些業務屬性來做hash，例如sid，city_id，user_id等，能夠更加靈活的實施hash策略，以保證同一個瀏覽器使用者的請求落在同一個web-server上

優點：

• 只需要改nginx配置，不需要修改應用程式碼

• 負載均衡，只要hash屬性是均勻的，多臺web-server的負載是均衡的

• 可以支持web-server水平擴充套件（session同步法是不行的，受記憶體限制）

不足：

• 如果web-server重啟，一部分session會丟失，產生業務影響，例如部分使用者重新登入

• 如果web-server水平擴充套件，rehash後session重新分佈，也會有一部分使用者路由不到正確的session

session一般是有有效期的，所有不足中的兩點，可以認為等同於部分session失效，一般問題不大。

對於四層hash還是七層hash，個人推薦前者：讓專業的軟體做專業的事情，反向代理就負責轉發，儘量不要引入應用層業務屬性，除非不得不這麼做（例如，有時候多機房多活需要按照業務屬性路由到不同機房的web-server）。

四、後端統一儲存

思路：將session儲存在web-server後端的儲存層，資料庫或者快取

優點：

• 沒有安全隱患

• 可以水平擴充套件，資料庫/快取水平切分即可

• web-server重啟或者擴容都不會有session丟失

不足：增加了一次網路呼叫，並且需要修改應用程式碼

對於db儲存還是cache，個人推薦後者：session讀取的頻率會很高，資料庫壓力會比較大。如果有session高可用需求，cache可以做高可用，但大部分情況下session可以丟失，一般也不需要考慮高可用。

五、總結

保證session一致性的架構設計常見方法：

• session同步法：多臺web-server相互同步資料

• 客戶端儲存法：一個使用者只儲存自己的資料

• 反向代理hash一致性：四層hash和七層hash都可以做，保證一個使用者的請求落在一臺web-server上

• 後端統一儲存：web-server重啟和擴容，session也不會丟失

對於方案3和方案4，個人建議推薦後者：

• web層、service層無狀態是大規模分散式系統設計原則之一，session屬於狀態，不宜放在web層

• 讓專業的軟體做專業的事情，web-server存session？還是讓cache去做這樣的事情吧

希望大夥有收穫，思路比結果重要，幫轉喲。

深入淺出一致性Hash原理

深入淺出一致性Hash原理

深入淺出一致性hash原理

一、前言

在解決分散式系統中負載均衡的問題時候可以使用Hash演算法讓固定的一部分請求落到同一臺伺服器上，這樣每臺伺服器固定處理一部分請求（並維護這些請求的資訊），起到負載均衡的作用。

但是普通的餘數hash（hash(比如使用者id)%伺服器機器數）演算法伸縮性很差，當新增或者下線伺服器機器時候，使用者id與伺服器的對映關係會大量失效。一致性hash則利用hash環對其進行了改進。

二、一致性Hash概述

為了能直觀的理解一致性hash原理，這裡結合一個簡單的例子來講解，假設有4臺伺服器，地址為ip1,ip2,ip3,ip4。

• 一致性hash是首先計算四個ip地址對應的hash值
  hash(ip1),hash(ip2),hash(ip3),hash(ip3)，計算出來的hash值是0~最大正整數直接的一個值，這四個值在一致性hash環上呈現如下圖：
  

• hash環上順時針從整數0開始，一直到最大正整數，我們根據四個ip計算的hash值肯定會落到這個hash環上的某一個點，至此我們把伺服器的四個ip對映到了一致性hash環

• 當用戶在客戶端進行請求時候，首先根據hash(使用者id)計算路由規則（hash值），然後看hash值落到了hash環的那個地方，根據hash值在hash環上的位置順時針找距離最近的ip作為路由ip.
  

如上圖可知user1,user2的請求會落到伺服器ip2進行處理，User3的請求會落到伺服器ip3進行處理，user4的請求會落到伺服器ip4進行處理，user5,user6的請求會落到伺服器ip1進行處理。

下面考慮當ip2的伺服器掛了的時候會出現什麼情況？
當ip2的伺服器掛了的時候，一致性hash環大致如下圖：

根據順時針規則可知user1,user2的請求會被伺服器ip3進行處理，而其它使用者的請求對應的處理伺服器不變，也就是隻有之前被ip2處理的一部分使用者的對映關係被破壞了，並且其負責處理的請求被順時針下一個節點委託處理。

下面考慮當新增機器的時候會出現什麼情況？
當新增一個ip5的伺服器後，一致性hash環大致如下圖：

根據順時針規則可知之前user1的請求應該被ip1伺服器處理，現在被新增的ip5伺服器處理，其他使用者的請求處理伺服器不變，也就是新增的伺服器順時針最近的伺服器的一部分請求會被新增的伺服器所替代。

三、一致性hash的特性

• 單調性(Monotonicity)，單調性是指如果已經有一些請求通過雜湊分派到了相應的伺服器進行處理，又有新的伺服器加入到系統中時候，應保證原有的請求可以被對映到原有的或者新的伺服器中去，而不會被對映到原來的其它伺服器上去。 這個通過上面新增伺服器ip5可以證明，新增ip5後，原來被ip1處理的user6現在還是被ip1處理，原來被ip1處理的user5現在被新增的ip5處理。

• 分散性(Spread)：分散式環境中，客戶端請求時候可能不知道所有伺服器的存在，可能只知道其中一部分伺服器，在客戶端看來他看到的部分伺服器會形成一個完整的hash環。如果多個客戶端都把部分伺服器作為一個完整hash環，那麼可能會導致，同一個使用者的請求被路由到不同的伺服器進行處理。這種情況顯然是應該避免的，因為它不能保證同一個使用者的請求落到同一個伺服器。所謂分散性是指上述情況發生的嚴重程度。好的雜湊演算法應儘量避免儘量降低分散性。 一致性hash具有很低的分散性

• 平衡性(Balance)：平衡性也就是說負載均衡，是指客戶端hash後的請求應該能夠分散到不同的伺服器上去。一致性hash可以做到每個伺服器都進行處理請求，但是不能保證每個伺服器處理的請求的數量大致相同，如下圖
  

伺服器ip1,ip2,ip3經過hash後落到了一致性hash環上，從圖中hash值分佈可知ip1會負責處理大概80%的請求，而ip2和ip3則只會負責處理大概20%的請求，雖然三個機器都在處理請求，但是明顯每個機器的負載不均衡，這樣稱為一致性hash的傾斜，虛擬節點的出現就是為了解決這個問題。

五、虛擬節點

當伺服器節點比較少的時候會出現上節所說的一致性hash傾斜的問題，一個解決方法是多加機器，但是加機器是有成本的，那麼就加虛擬節點，比如上面三個機器，每個機器引入1個虛擬節點後的一致性hash環的圖如下：

其中ip1-1是ip1的虛擬節點，ip2-1是ip2的虛擬節點，ip3-1是ip3的虛擬節點。
可知當物理機器數目為M，虛擬節點為N的時候，實際hash環上節點個數為M*N。比如當客戶端計算的hash值處於ip2和ip3或者處於ip2-1和ip3-1之間時候使用ip3伺服器進行處理。

六、均勻一致性hash

上節我們使用虛擬節點後的圖看起來比較均衡，但是如果生成虛擬節點的演算法不夠好很可能會得到下面的環：
可知每個服務節點引入1個虛擬節點後，情況相比沒有引入前均衡性有所改善，但是並不均衡。

均衡的一致性hash應該是如下圖：

均勻一致性hash的目標是如果伺服器有N臺，客戶端的hash值有M個，那麼每個伺服器應該處理大概M/N個使用者的。也就是每臺伺服器負載儘量均衡

七、總結

在分散式系統中一致性hash起著不可忽略的地位，無論是分散式快取，還是分散式Rpc框架的負載均衡策略都有所使用。