業(yè)務(wù)場景

近年來B2C、O2O等商業(yè)概念的提出和移動端的發(fā)展，使得分布式系統(tǒng)流行了起來。分布式系統(tǒng)相對于單系統(tǒng)，解決了流量大、系統(tǒng)高可用和高容錯等問題。功能強(qiáng)大也意味著實(shí)現(xiàn)起來需要更多技術(shù)的支持。例如系統(tǒng)訪問層的負(fù)載均衡，緩存層的多實(shí)例主從復(fù)制備份，數(shù)據(jù)層的分庫分表等。

我們以負(fù)載均衡為例，常見的負(fù)載均衡方法有很多，但是它們的優(yōu)缺點(diǎn)也都很明顯：

• 隨機(jī)訪問策略。系統(tǒng)隨機(jī)訪問，缺點(diǎn)：可能造成服務(wù)器負(fù)載壓力不均衡，俗話講就是撐的撐死，餓的餓死。
• 輪詢策略。請求均勻分配，如果服務(wù)器有性能差異，則無法實(shí)現(xiàn)性能好的服務(wù)器能夠多承擔(dān)一部分。
• 權(quán)重輪詢策略。權(quán)值需要靜態(tài)配置，無法自動調(diào)節(jié)，不適合對長連接和命中率有要求的場景。
• Hash取模策略。不穩(wěn)定，如果列表中某臺服務(wù)器宕機(jī)，則會導(dǎo)致路由算法產(chǎn)生變化，由此導(dǎo)致命中率的急劇下降。
• 一致性哈希策略。

以上幾個策略，排除本篇介紹的一致性哈希，可能使用最多的就是 Hash取模策略了。Hash取模策略的缺點(diǎn)也是很明顯的，這種缺點(diǎn)也許在負(fù)載均衡的時候不是很明顯，但是在涉及數(shù)據(jù)訪問的主從備份和分庫分表中就體現(xiàn)明顯了。

使用Hash取模的問題

1.負(fù)載均衡

負(fù)載均衡時，假設(shè)現(xiàn)有3臺服務(wù)器(編號分別為0、1、2)，使用哈希取模的計算方式則是：對訪問者的IP，通過固定算式hash(IP) % N（N為服務(wù)器的個數(shù)），使得每個IP都可以定位到特定的服務(wù)器。

例如現(xiàn)有IP地址 10.58.34.31，對IP哈希取模策時，計算結(jié)果為2，即訪問編號為2的服務(wù)器：

String ip = "10.58.34.31";
int v1 = hash(ip) % 3;
System.out.println("訪問服務(wù)器：" + v1);// 訪問服務(wù)器：2

如果此時服務(wù)器2宕機(jī)了，則會導(dǎo)致所有計算結(jié)果為2的 IP 對應(yīng)的用戶都訪問異常（包括上例中的IP）?；蛘吣阈略隽艘慌_服務(wù)器3，這時不修改N值的話那么服務(wù)器3永遠(yuǎn)不會被訪問到。

當(dāng)然如果你能動態(tài)獲取到當(dāng)前可用服務(wù)器的個數(shù)，亦即N值是根據(jù)當(dāng)前可用服務(wù)器個數(shù)動態(tài)來變化的，則可解決此問題。但是對于類似要在特定地區(qū)或特定IP來訪問特定服務(wù)器的這種需求就會造成訪問偏差。

2.分庫分表

負(fù)載均衡中有這種問題，那么分庫分表中同樣也有這樣的問題。例如隨著業(yè)務(wù)的飛速增長，我們的注冊用戶也越來越多，單個用戶表數(shù)量已經(jīng)達(dá)到千萬級甚至更大。由于Mysql的單表建議百萬級數(shù)據(jù)存儲，所以這時為了保證系統(tǒng)查詢和運(yùn)行效率，肯定會考慮到分庫分表。

對于分庫分表，數(shù)據(jù)的分配是個重要的問題，你需要保證數(shù)據(jù)分配在這個服務(wù)器，那么在查詢時也需要到該服務(wù)器上來查詢，否則會造成數(shù)據(jù)查詢丟失的問題。

通常是根據(jù)用戶的 ID 哈希取模得到的值然后路由到對應(yīng)的存儲位置，計算公式為：hash(userId) % N，其中N為分庫或分表的個數(shù)。

例如分庫數(shù)為2時，計算結(jié)果為1，則ID為1010的用戶存儲在編號為1對應(yīng)的庫中：

String userId = "1010";
int v1 = hash(userId) % 2;
System.out.println("存儲：" + v1);// 存儲：1

之后業(yè)務(wù)數(shù)量持續(xù)增長，又新增一臺用戶服務(wù)庫，當(dāng)我們根據(jù)ID=1010去查詢數(shù)據(jù)時，路由計算方式為：

int v2 = hash(userId) % 3;
System.out.println("存儲：" + v2);// 存儲：0

我們得到的路由值是0，最后的結(jié)果就不用說了，存在編號1上的數(shù)據(jù)我們?nèi)ゾ幪枮?的庫上去查詢肯定是得不到查詢結(jié)果的。

為了數(shù)據(jù)可用，你需要做數(shù)據(jù)遷移，按照新的路由規(guī)則對所有用戶重新分配存儲地址。每次的庫或表的數(shù)量改變你都需要做一次全部用戶信息數(shù)據(jù)的遷移。不用想這其中的工作量是有多費(fèi)時費(fèi)力了。

是否有某種方法，有效解決這種分布式存儲結(jié)構(gòu)下動態(tài)增加或刪除節(jié)點(diǎn)所帶來的問題，能保證這種不受實(shí)例數(shù)量變化影響而準(zhǔn)確路由到正確的實(shí)例上的算法或?qū)崿F(xiàn)機(jī)制呢？解決這些問題，一致性哈希算法誕生了。

基本思想原理

一致性哈希算法在1997年由麻省理工學(xué)院的Karger等人在解決分布式Cache中提出的，設(shè)計目標(biāo)是為了解決因特網(wǎng)中的熱點(diǎn)(Hot spot)問題，初衷和CARP十分類似。一致性哈希修正了CARP使用的簡單哈希算法帶來的問題，使得DHT可以在P2P環(huán)境中真正得到應(yīng)用。

上面說的哈希取模方法，它是針對一個點(diǎn)的，業(yè)務(wù)布局嚴(yán)重依賴于這個計算的點(diǎn)值結(jié)果。你結(jié)算的結(jié)果是2，那么就對應(yīng)到編號為2的服務(wù)器上。這樣的映射就造成了業(yè)務(wù)容錯性和可擴(kuò)展性極低。

我們思考下，是否可以將這個計算結(jié)果的點(diǎn)值賦予范圍的意義？我們知道Hash取模之后得到的是一個 int 型的整值。

//Objects 類中默認(rèn)的 hash 方法
 public static int hash(Object... values) {
    return Arrays.hashCode(values);
}

既然 hash的計算結(jié)果是 int 類型，而 java 中 int 的最小值是-2^31，最大值是2^31-1。意味著任何通過哈希取模之后的無符號值都會在 0 ~ 2^31-1范圍之間，共2^32個數(shù)。那我們是否可以不對服務(wù)器的數(shù)量進(jìn)行取模而是直接對2^32取模。這就形成了一致性哈希的基本算法思想，什么意思呢？

這里需要注意一點(diǎn)：

默認(rèn)的 hash 方法結(jié)果是有負(fù)值的情況，因此需要我們重寫hash方法，保證哈希值的非負(fù)性。

簡單來說，一致性Hash算法將整個哈希值空間組織成一個虛擬的圓環(huán)，如假設(shè)某哈希函數(shù) H 的值空間為 0 ~ 2^32-1（即哈希值是一個32位無符號整形），整個哈希環(huán)如下：

整個空間圓按順時針方向布局，圓環(huán)的正上方的點(diǎn)代表0，0點(diǎn)右側(cè)的第一個點(diǎn)代表1。以此類推2、3、4、5、6……直到232-1，也就是說0點(diǎn)左側(cè)的第一個點(diǎn)代表232-1， 0和2^32-1在零點(diǎn)中方向重合，我們把這個由2^32個點(diǎn)組成的圓環(huán)稱為 Hash環(huán)。

那么，一致性哈希算法與上圖中的圓環(huán)有什么關(guān)系呢？仍然以之前描述的場景為例，假設(shè)我們有4臺服務(wù)器，服務(wù)器0、服務(wù)器1、服務(wù)器2，服務(wù)器3，那么，在生產(chǎn)環(huán)境中，這4臺服務(wù)器肯定有自己的 IP 地址或主機(jī)名，我們使用它們各自的 IP 地址或主機(jī)名作為關(guān)鍵字進(jìn)行哈希計算，使用哈希后的結(jié)果對2^32取模，可以使用如下公式示意：

hash（服務(wù)器的IP地址） %  2^32

最后會得到一個 [0, 2^32-1]之間的一個無符號整形數(shù)，這個整數(shù)就代表服務(wù)器的編號。同時這個整數(shù)肯定處于[0, 2^32-1]之間，那么，上圖中的 hash 環(huán)上必定有一個點(diǎn)與這個整數(shù)對應(yīng)。那么這個服務(wù)器就可以映射到這個環(huán)上。

多個服務(wù)器都通過這種方式進(jìn)行計算，最后都會各自映射到圓環(huán)上的某個點(diǎn)，這樣每臺機(jī)器就能確定其在哈希環(huán)上的位置，如下圖所示。

如何提高容錯性和擴(kuò)展性的

那么用戶訪問，如何分配訪問的服務(wù)器呢？我們根據(jù)用戶的 IP 使用上面相同的函數(shù) Hash 計算出哈希值，并確定此數(shù)據(jù)在環(huán)上的位置，從此位置沿環(huán) 順時針行走，遇到的第一臺服務(wù)器就是其應(yīng)該定位到的服務(wù)器。

從上圖可以看出 用戶1 順時針遇到的第一臺服務(wù)器是 服務(wù)器3 ，所以該用戶被分配給服務(wù)器3來提供服務(wù)。同理可以看出用戶2被分配給了服務(wù)器2。

1. 新增服務(wù)器節(jié)點(diǎn)

如果這時需要新增一臺服務(wù)器節(jié)點(diǎn)，一致性哈希策略是如何應(yīng)對的呢？如下圖所示，我們新增了一臺服務(wù)器4，通過上述一致性哈希算法計算后得出它在哈希環(huán)的位置。

可以發(fā)現(xiàn)，原來訪問服務(wù)器3的用戶1現(xiàn)在訪問的對象是服務(wù)器4，用戶能正常訪問且服務(wù)不需要停機(jī)就可以自動切換。

2. 刪除服務(wù)器節(jié)點(diǎn)

如果這時某臺服務(wù)器異常宕機(jī)或者運(yùn)維撤銷了一臺服務(wù)器，那么這時會發(fā)生什么情況呢？如下圖所示，假設(shè)我們撤銷了服務(wù)器2。

可以看出，我們服務(wù)仍然能正常提供服務(wù)，只不過這時用戶2會被分配到服務(wù)1上了而已。

通過一致性哈希的方式，我們提高了我們系統(tǒng)的容錯性和可擴(kuò)展性，分布式節(jié)點(diǎn)的變動不會影響整個系統(tǒng)的運(yùn)行且不需要我們做一些人為的調(diào)整策略。

Hash環(huán)的數(shù)據(jù)傾斜問題

一致性哈希雖然為我們提供了穩(wěn)定的切換策略，但是它也有一些小缺陷。因?yàn)?hash取模算法得到的結(jié)果是隨機(jī)的，我們并不能保證各個服務(wù)節(jié)點(diǎn)能均勻的分配到哈希環(huán)上。

例如當(dāng)有4個服務(wù)節(jié)點(diǎn)時，我們把哈希環(huán)認(rèn)為是一個圓盤時鐘，我們并不能保證4個服務(wù)節(jié)點(diǎn)剛好均勻的落在時鐘的 12、3、6、9點(diǎn)上。

分布不均勻就會產(chǎn)生一個問題，用戶的請求訪問就會不均勻，同時4個服務(wù)承受的壓力就會不均勻。這種問題現(xiàn)象我們稱之為，Hash環(huán)的數(shù)據(jù)傾斜問題。

如上圖所示，服務(wù)器0 到 服務(wù)器1 之間的哈希點(diǎn)值占據(jù)比例最大，大量請求會集中到 服務(wù)器1 上，而只有極少量會定位到 服務(wù)器0 或其他幾個節(jié)點(diǎn)上，從而出現(xiàn) hash環(huán)偏斜的情況。

如果想要均衡的將緩存分布到每臺服務(wù)器上，最好能讓這每臺服務(wù)器盡量多的、均勻的出現(xiàn)在hash環(huán)上，但是如上圖中所示，真實(shí)的服務(wù)器資源只有4臺，我們怎樣憑空的讓它們多起來呢？

既然沒有多余的真正的物理服務(wù)器節(jié)點(diǎn)，我們就只能將現(xiàn)有的物理節(jié)點(diǎn)通過虛擬的方法復(fù)制出來。

這些由實(shí)際節(jié)點(diǎn)虛擬復(fù)制而來的節(jié)點(diǎn)被稱為 "虛擬節(jié)點(diǎn)"，即對每一個服務(wù)節(jié)點(diǎn)計算多個哈希，每個計算結(jié)果位置都放置一個此服務(wù)節(jié)點(diǎn)，稱為虛擬節(jié)點(diǎn)。具體做法可以在服務(wù)器IP或主機(jī)名的后面增加編號來實(shí)現(xiàn)。

如上圖所示，假如 服務(wù)器1 的 IP 是 192.168.32.132，那么原 服務(wù)器1 節(jié)點(diǎn)在環(huán)形空間的位置就是hash("192.168.32.132") % 2^32。

我們基于 服務(wù)器1 構(gòu)建兩個虛擬節(jié)點(diǎn)，Server1-A 和 Server1-B，虛擬節(jié)點(diǎn)在環(huán)形空間的位置可以利用（IP+后綴）計算，例如：

hash("192.168.32.132#A") % 2^32
hash("192.168.32.132#B") % 2^32

此時，環(huán)形空間中不再有物理節(jié)點(diǎn) 服務(wù)器1，服務(wù)器2，……，替代的是只有虛擬節(jié)點(diǎn) Server1-A，Server1-B，Server2-A，Server2-B，……。

同時數(shù)據(jù)定位算法不變，只是多了一步虛擬節(jié)點(diǎn)到實(shí)際節(jié)點(diǎn)的映射，例如定位到 “Server1-A”、“Server1-B” 兩個虛擬節(jié)點(diǎn)的數(shù)據(jù)均定位到 服務(wù)器1上。這樣就解決了服務(wù)節(jié)點(diǎn)少時數(shù)據(jù)傾斜的問題。

在實(shí)際應(yīng)用中，通常將虛擬節(jié)點(diǎn)數(shù)設(shè)置為32甚至更大，因此即使很少的服務(wù)節(jié)點(diǎn)也能做到相對均勻的數(shù)據(jù)分布。由于虛擬節(jié)點(diǎn)數(shù)量較多，與虛擬節(jié)點(diǎn)的映射關(guān)系也變得相對均衡了。

總結(jié)

一致性哈希一般在分布式緩存中使用的也比較多，本篇只介紹了服務(wù)的負(fù)載均衡和分布式存儲，對于分布式緩存其實(shí)原理是類似的，讀者可以自己舉一反三來思考下。

其實(shí)，在分布式存儲和分布式緩存中，當(dāng)服務(wù)節(jié)點(diǎn)發(fā)生變化時（新增或減少），一致性哈希算法并不能杜絕數(shù)據(jù)遷移的問題，但是可以有效避免數(shù)據(jù)的全量遷移，需要遷移的只是更改的節(jié)點(diǎn)和它的上游節(jié)點(diǎn)它們兩個節(jié)點(diǎn)之間的那部分?jǐn)?shù)據(jù)。

另外，我們都知道 hash算法 有一個避免不了的問題，就是哈希沖突。對于用戶請求IP的哈希沖突，其實(shí)只是不同用戶被分配到了同一臺服務(wù)器上，這個沒什么影響。但是如果是服務(wù)節(jié)點(diǎn)有哈希沖突呢？這會導(dǎo)致兩個服務(wù)節(jié)點(diǎn)在哈希環(huán)上對應(yīng)同一個點(diǎn)，其實(shí)我感覺這個問題也不大，因?yàn)橐环矫婀_突的概率比較低，另一方面我們可以通過虛擬節(jié)點(diǎn)也可減少這種情況。

以上就是詳解Java分布式系統(tǒng)中一致性哈希算法的詳細(xì)內(nèi)容，更多關(guān)于Java算法的資料請關(guān)注腳本之家其它相關(guān)文章！