如何分析分布式session解決方案與一致性hash

這篇文章將為大家詳細(xì)講解有關(guān)如何分析分布式session解決方案與一致性hash，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。

一、問題的提出

1. 什么是Session？

用戶使用網(wǎng)站的服務(wù)，需要使用瀏覽器與Web服務(wù)器進(jìn)行多次交互。HTTP協(xié)議本身是無狀態(tài)的，需要基于HTTP協(xié)議支持會話狀態(tài)（Session State）的機(jī)制。具體的實(shí)現(xiàn)方式是：在會話開始時(shí)，分配一個(gè)
唯一的會話標(biāo)識（SessionID），并通過Cookie將這個(gè)標(biāo)識告訴瀏覽器，以后每次請求的時(shí)候，瀏覽器都會帶上這個(gè)會話標(biāo)識SessionID來告訴Web服務(wù)器這個(gè)請求是屬于哪個(gè)會話的。在Web服務(wù)器上，各個(gè)會話都有獨(dú)立的存儲，保存不同會話的信息。如果遇到禁用Cookie的情況，一般的做法就是把這個(gè)會話標(biāo)識放到URL的參數(shù)中。

2. 什么是Session一致性問題？

當(dāng)Web服務(wù)器從一臺變?yōu)槎嗯_時(shí)，就會出現(xiàn)Session一致性問題。

如上圖所示，當(dāng)一個(gè)帶有會話標(biāo)識的HTTP請求到了Web服務(wù)器后，需要在HTTP請求的處理過程中找到對應(yīng)的會話數(shù)據(jù)（Session）。但是，現(xiàn)在存在的問題就是：如果我第一次訪問網(wǎng)站時(shí)請求落到了左邊的服務(wù)器，那么我的Session就創(chuàng)建在左邊的服務(wù)器上了，如果我們不做處理，就不能保證接下來的請求每次都落在同一邊的服務(wù)器上了。這就是Session一致性問題。

二、Session一致性解決方案

1. Session Stiky

在單機(jī)的情況下，會話保存在單機(jī)上，請求也是由這個(gè)機(jī)器處理，因此不會有問題。當(dāng)Web服務(wù)器變?yōu)槎嗯_以后，如果保證同一個(gè)會話的請求都在同一個(gè)Web服務(wù)器上處理，則對該會話來說，與之前單機(jī)的情況是一樣的。

如果要做到這樣，就需要負(fù)載均衡器能夠根據(jù)每次請求的會話標(biāo)識SessionID來進(jìn)行請求轉(zhuǎn)發(fā)，如下圖所示。這種方式稱之為Session Stiky方式。

該方案本身非常簡單，對于Web服務(wù)器來說，該方案和單機(jī)的情況是一樣的，只是我們在負(fù)載均衡器上做了手腳。這個(gè)方案可以讓同樣Session的請求每次都發(fā)送到同一個(gè)Web服務(wù)器來處理，非常利于針對Session進(jìn)行服務(wù)端本地的緩存。

其所存在的問題包括：

• 如果有一臺Web服務(wù)器宕機(jī)或者重啟，則該機(jī)器上的會話數(shù)據(jù)就會丟失。如果會話中有登錄狀態(tài)數(shù)據(jù)，則用戶需要重新登陸。

• 會話標(biāo)識是應(yīng)用層的信息，則負(fù)載均衡器要將同一個(gè)會話的請求都保存到同一個(gè)Web服務(wù)器上的話，就需要進(jìn)行應(yīng)用層（七層）的解析，這個(gè)開銷比第四層的交換要大。

• 負(fù)載均衡器變?yōu)榱艘粋€(gè)有狀態(tài)的節(jié)點(diǎn)，要將會話保存到具體Web服務(wù)器的映射，因此內(nèi)存消耗會更大，容災(zāi)會更麻煩。

打個(gè)比方來說，對于Session Stiky，如果說Web服務(wù)器是我們每次吃飯的飯店，會話數(shù)據(jù)就是我們吃飯用的碗筷。要保證每次吃飯都用自己的碗筷，我就把餐具存在某一家，并且每次都去這家店吃，這是個(gè)不錯(cuò)的主意。

2. Session Replication

如果我們繼續(xù)以去飯店吃飯類比，那么除了前面的方式之外，如果我在每個(gè)店都存放一套自己的餐具，就可以更加自由地選擇飯店。Session Replication就是這樣一種方式，如下圖所示。

可以看到，在Session Replication方案中，不再要求負(fù)載均衡器來保證同一個(gè)會話地多次請求必須到同一個(gè)Web服務(wù)器上了。而我們的Web服務(wù)器之間則增加了會話數(shù)據(jù)的同步。通過同步就保證了不同Web服務(wù)器之間的Session數(shù)據(jù)的一致。

但是，Session Replication方案也存在一些問題，包括：

• 同步Session數(shù)據(jù)造成了網(wǎng)絡(luò)帶寬的開銷。只要Session數(shù)據(jù)有變化，就需要將數(shù)據(jù)同步到其他所有機(jī)器上，機(jī)器數(shù)越多，同步帶來的網(wǎng)絡(luò)帶寬開銷就越大。

• 每臺Web服務(wù)器都要保存所有的Session數(shù)據(jù)，如果整個(gè)集群的Session數(shù)很多的話，每臺機(jī)器用于保存Session數(shù)據(jù)的內(nèi)容占用會很嚴(yán)重。

這就是Session Replication方案。這個(gè)方案是靠應(yīng)用容器來完成Session的復(fù)制從而使得應(yīng)用解決Session問題的，應(yīng)用本身并不關(guān)心這個(gè)事情。不過，這個(gè)方案并不適合集群機(jī)器數(shù)多的場景。如果只有幾臺機(jī)器，用該方案是可以的。

3. Session數(shù)據(jù)集中存儲

同樣是希望同一個(gè)會話的請求可以發(fā)到不同的Web服務(wù)器上，前面的Session Replication是一種方案，還有一種方案就是把Session數(shù)據(jù)集中存儲起來，然后不同Web服務(wù)器從同樣的地方來獲取Session。其大概的結(jié)構(gòu)如下圖所示：

可以看到，與Session Replication方案一樣的部分是，會話請求經(jīng)過負(fù)載均衡器后，不會被固定在同樣的Web服務(wù)器上。不同的地方是，Web服務(wù)器之間沒有Session數(shù)據(jù)復(fù)制，并且Session數(shù)據(jù)也不是保存在本機(jī)了，而是放在了另一個(gè)集中存儲的地方。這樣，無論是哪臺Web服務(wù)器，也無論修改的是哪個(gè)Session的數(shù)據(jù)，最終的修改都發(fā)生在這個(gè)集中存儲的地方，而Web服務(wù)器使用Session數(shù)據(jù)時(shí)，也是從這個(gè)集中存儲Session數(shù)據(jù)的地方來讀取。對于Session數(shù)據(jù)存儲的具體方式，可以使用數(shù)據(jù)庫，也可以使用其他分布式存儲系統(tǒng)。這個(gè)方案解決了Session Replication方案中內(nèi)存的問題，而對于網(wǎng)絡(luò)帶寬，該方案也比Session Replication要好。

不過，該方案仍存在一些問題，包括：

• 讀寫Session數(shù)據(jù)引入了網(wǎng)絡(luò)操作，這相對于本機(jī)的數(shù)據(jù)讀取來說，問題就在于存在時(shí)延和不穩(wěn)定性，不過由于通信基本發(fā)生在內(nèi)網(wǎng)，問題不大。

• 如果集中存儲Session的機(jī)器或者集群存在問題，這就會影響我們的應(yīng)用。

相對于Session Replication，當(dāng)Web服務(wù)器數(shù)量比較大時(shí)、Session數(shù)比較多的時(shí)候，集中存儲方案的優(yōu)勢是非常明顯的。

4. Cookie Based

對于Cookie Based方案，它對同一個(gè)會話的不同請求也是不限制具體處理機(jī)器的。與Session Replication和Session數(shù)據(jù)集中管理的方案不同，這個(gè)方案是通過Cookie來傳遞Session數(shù)據(jù)的。具體如下圖所示。

可以看出，我們的Session數(shù)據(jù)存放在Cookie中，然后在Web服務(wù)器上從Cookie中生成對應(yīng)的Session數(shù)據(jù)。這就好比我每次都把自己的碗筷帶在身上，這樣我去哪家飯店吃飯就可以隨意選擇了。相對于前面的集中存儲，這個(gè)方案不會依賴外部的一個(gè)存儲系統(tǒng)，也就不存在從外部系統(tǒng)獲取、寫入Session數(shù)據(jù)的網(wǎng)絡(luò)時(shí)延和不穩(wěn)定性了。

不過，該方案依然存在不足，包括：

• Cookie長度限制。由于Cookie是有長度限制的，這也會限制Session數(shù)據(jù)的長度。

• 安全性。Session數(shù)據(jù)本來都是服務(wù)器端數(shù)據(jù)，而這個(gè)方案是讓這些服務(wù)端數(shù)據(jù)到了外部外部網(wǎng)絡(luò)及客戶端，因此存在安全性的問題。

• 帶寬消耗。這里指的不是內(nèi)部Web服務(wù)器之間的帶寬的消耗，而是我們數(shù)據(jù)中心的整體外部貸款的消耗。

• 性能消耗。每次HTTP請求和響應(yīng)都帶有Session數(shù)據(jù)，對Web服務(wù)器來說，在同樣的處理情況下，響應(yīng)的結(jié)果輸出越少，支持的并發(fā)請求就會越多。

三、總結(jié)

綜合而言，上述所有方案都是解決session問題的方案，對于大型網(wǎng)站來說，Session Sticky和Session集中管理是比較好的方案。

一、前言

在解決分布式系統(tǒng)中負(fù)載均衡的問題時(shí)候可以使用Hash算法讓固定的一部分請求落到同一臺服務(wù)器上，這樣每臺服務(wù)器固定處理一部分請求（并維護(hù)這些請求的信息），起到負(fù)載均衡的作用。

但是普通的余數(shù)hash（hash(比如用戶id)%服務(wù)器機(jī)器數(shù)）算法伸縮性很差，當(dāng)新增或者下線服務(wù)器機(jī)器時(shí)候，用戶id與服務(wù)器的映射關(guān)系會大量失效。一致性hash則利用hash環(huán)對其進(jìn)行了改進(jìn)。

二、一致性Hash概述

為了能直觀的理解一致性hash原理，這里結(jié)合一個(gè)簡單的例子來講解，假設(shè)有4臺服務(wù)器，地址為ip1,ip2,ip3,ip4。

一致性hash是首先計(jì)算四個(gè)ip地址對應(yīng)的hash值hash(ip1),hash(ip2),hash(ip3),hash(ip3)，計(jì)算出來的hash值是0~最大正整數(shù)直接的一個(gè)值，這四個(gè)值在一致性hash環(huán)上呈現(xiàn)如下圖：

hash環(huán)上順時(shí)針從整數(shù)0開始，一直到最大正整數(shù)，我們根據(jù)四個(gè)ip計(jì)算的hash值肯定會落到這個(gè)hash環(huán)上的某一個(gè)點(diǎn)，至此我們把服務(wù)器的四個(gè)ip映射到了一致性hash環(huán)當(dāng)用戶在客戶端進(jìn)行請求時(shí)候，首先根據(jù)hash(用戶id)計(jì)算路由規(guī)則（hash值），然后看hash值落到了hash環(huán)的那個(gè)地方，根據(jù)hash值在hash環(huán)上的位置順時(shí)針找距離最近的ip作為路由ip.

如上圖可知user1,user2的請求會落到服務(wù)器ip2進(jìn)行處理，User3的請求會落到服務(wù)器ip3進(jìn)行處理，user4的請求會落到服務(wù)器ip4進(jìn)行處理，user5,user6的請求會落到服務(wù)器ip1進(jìn)行處理。

下面考慮當(dāng)ip2的服務(wù)器掛了的時(shí)候會出現(xiàn)什么情況？

當(dāng)ip2的服務(wù)器掛了的時(shí)候，一致性hash環(huán)大致如下圖：

根據(jù)順時(shí)針規(guī)則可知user1,user2的請求會被服務(wù)器ip3進(jìn)行處理，而其它用戶的請求對應(yīng)的處理服務(wù)器不變，也就是只有之前被ip2處理的一部分用戶的映射關(guān)系被破壞了，并且其負(fù)責(zé)處理的請求被順時(shí)針下一個(gè)節(jié)點(diǎn)委托處理。

下面考慮當(dāng)新增機(jī)器的時(shí)候會出現(xiàn)什么情況？

當(dāng)新增一個(gè)ip5的服務(wù)器后，一致性hash環(huán)大致如下圖：

根據(jù)順時(shí)針規(guī)則可知之前user1的請求應(yīng)該被ip1服務(wù)器處理，現(xiàn)在被新增的ip5服務(wù)器處理，其他用戶的請求處理服務(wù)器不變，也就是新增的服務(wù)器順時(shí)針最近的服務(wù)器的一部分請求會被新增的服務(wù)器所替代。

三、一致性hash的特性

單調(diào)性(Monotonicity)，單調(diào)性是指如果已經(jīng)有一些請求通過哈希分派到了相應(yīng)的服務(wù)器進(jìn)行處理，又有新的服務(wù)器加入到系統(tǒng)中時(shí)候，應(yīng)保證原有的請求可以被映射到原有的或者新的服務(wù)器中去，而不會被映射到原來的其它服務(wù)器上去。 這個(gè)通過上面新增服務(wù)器ip5可以證明，新增ip5后，原來被ip1處理的user6現(xiàn)在還是被ip1處理，原來被ip1處理的user5現(xiàn)在被新增的ip5處理。分散性(Spread)：分布式環(huán)境中，客戶端請求時(shí)候可能不知道所有服務(wù)器的存在，可能只知道其中一部分服務(wù)器，在客戶端看來他看到的部分服務(wù)器會形成一個(gè)完整的hash環(huán)。如果多個(gè)客戶端都把部分服務(wù)器作為一個(gè)完整hash環(huán)，那么可能會導(dǎo)致，同一個(gè)用戶的請求被路由到不同的服務(wù)器進(jìn)行處理。這種情況顯然是應(yīng)該避免的，因?yàn)樗荒鼙ＷC同一個(gè)用戶的請求落到同一個(gè)服務(wù)器。所謂分散性是指上述情況發(fā)生的嚴(yán)重程度。平衡性(Balance)：平衡性也就是說負(fù)載均衡，是指客戶端hash后的請求應(yīng)該能夠分散到不同的服務(wù)器上去。一致性hash可以做到每個(gè)服務(wù)器都進(jìn)行處理請求，但是不能保證每個(gè)服務(wù)器處理的請求的數(shù)量大致相同，如下圖

服務(wù)器ip1,ip2,ip3經(jīng)過hash后落到了一致性hash環(huán)上，從圖中hash值分布可知ip1會負(fù)責(zé)處理大概80%的請求，而ip2和ip3則只會負(fù)責(zé)處理大概20%的請求，雖然三個(gè)機(jī)器都在處理請求，但是明顯每個(gè)機(jī)器的負(fù)載不均衡，這樣稱為一致性hash的傾斜，虛擬節(jié)點(diǎn)的出現(xiàn)就是為了解決這個(gè)問題。

五、虛擬節(jié)點(diǎn)

當(dāng)服務(wù)器節(jié)點(diǎn)比較少的時(shí)候會出現(xiàn)上節(jié)所說的一致性hash傾斜的問題，一個(gè)解決方法是多加機(jī)器，但是加機(jī)器是有成本的，那么就加虛擬節(jié)點(diǎn)，比如上面三個(gè)機(jī)器，每個(gè)機(jī)器引入1個(gè)虛擬節(jié)點(diǎn)后的一致性hash環(huán)的圖如下：

其中ip1-1是ip1的虛擬節(jié)點(diǎn)，ip2-1是ip2的虛擬節(jié)點(diǎn)，ip3-1是ip3的虛擬節(jié)點(diǎn)。

可知當(dāng)物理機(jī)器數(shù)目為M，虛擬節(jié)點(diǎn)為N的時(shí)候，實(shí)際hash環(huán)上節(jié)點(diǎn)個(gè)數(shù)為M*（N+1）。比如當(dāng)客戶端計(jì)算的hash值處于ip2和ip3或者處于ip2-1和ip3-1之間時(shí)候使用ip3服務(wù)器進(jìn)行處理。

六、均勻一致性hash

上節(jié)我們使用虛擬節(jié)點(diǎn)后的圖看起來比較均衡，但是如果生成虛擬節(jié)點(diǎn)的算法不夠好很可能會得到下面的環(huán)：

可知每個(gè)服務(wù)節(jié)點(diǎn)引入1個(gè)虛擬節(jié)點(diǎn)后，情況相比沒有引入前均衡性有所改善，但是并不均衡。

均衡的一致性hash應(yīng)該是如下圖：

均勻一致性hash的目標(biāo)是如果服務(wù)器有N臺，客戶端的hash值有M個(gè)，那么每個(gè)服務(wù)器應(yīng)該處理大概M/N個(gè)用戶的。也就是每臺服務(wù)器負(fù)載盡量均衡。dubbo提供的一致性hash負(fù)載均衡算法就是不均勻的，我們自己實(shí)現(xiàn)了dubbo的spi擴(kuò)展實(shí)現(xiàn)了均勻一致性hash.

在分布式系統(tǒng)中一致性hash起著不可忽略的地位，無論是分布式緩存，還是分布式Rpc框架的負(fù)載均衡策略都有所使用。

關(guān)于如何分析分布式session解決方案與一致性hash就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。