如何分析分布式session解決方案與一致性hash-創(chuàng)新互聯(lián)

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

成都創(chuàng)新互聯(lián)長期為上千客戶提供的網(wǎng)站建設(shè)服務(wù)，團隊從業(yè)經(jīng)驗10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為文峰企業(yè)提供專業(yè)的網(wǎng)站建設(shè)、網(wǎng)站設(shè)計，文峰網(wǎng)站改版等技術(shù)服務(wù)。擁有10多年豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。

一、問題的提出

1. 什么是Session？

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

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

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

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

二、Session一致性解決方案

1. Session Stiky

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

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

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

其所存在的問題包括：

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

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

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

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

2. Session Replication

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

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

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

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

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

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

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

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

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

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

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

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

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

4. Cookie Based

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

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

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

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

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

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

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

三、總結(jié)

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

一、前言

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

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

二、一致性Hash概述

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

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

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

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

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

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

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

下面考慮當新增機器的時候會出現(xiàn)什么情況？

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

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

三、一致性hash的特性

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

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

五、虛擬節(jié)點

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

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

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

六、均勻一致性hash

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

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

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

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

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

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

標題名稱：如何分析分布式session解決方案與一致性hash-創(chuàng)新互聯(lián)
網(wǎng)站URL：http://www.bm7419.com/article44/dcdcee.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供動態(tài)網(wǎng)站、定制開發(fā)、搜索引擎優(yōu)化、網(wǎng)站營銷、軟件開發(fā)、網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)