本文主要來自：http://www.zsythink.net/archives/1182
摘錄防丟失

一致性哈希算法定義

一致性哈希算法在1997年由麻省理工學院提出的一種分布式哈希（DHT）實現算法，設計目標是為了解決因特網中的熱點(Hot spot)問題，初衷和CARP（Common Access Redundancy Protocol，共用地址冗余協議）十分類似。一致性哈希修正了CARP使用的簡 單哈希算法帶來的問題，使得分布式哈希（DHT，Distributed Hash Table）可以在P2P環境中真正得到應用。

一致性hash算法提出了在動態變化的Cache環境中，判定哈希算法好壞的四個定義：

平衡性(Balance)：平衡性是指哈希的結果能夠盡可能分布到所有的緩沖中去，這樣可以使得所有的緩沖空間都得到利用。很多哈希算法都能夠滿足這一條件。

單調性(Monotonicity)：單調性是指如果已經有一些內容通過哈希分派到了相應的緩沖中，又有新的緩沖加入到系統中。哈希的結果應能夠保證原有已分配的內容可以被映射到原有的或者新的緩沖中去，而不會被映射到舊的緩沖集合中的其他緩沖區。

分散性(Spread)：在分布式環境中，終端有可能看不到所有的緩沖，而是只能看到其中的一部分。當終端希望通過哈希過程將內容映射到緩沖上時，由于不同終端所見的緩沖范圍有可能不同，從而導致哈希的結果不一致，最終的結果是相同的內容被不同的終端映射到不同的緩沖區中。這種情況顯然是應該避免的，因為它導致相同內容被存儲到不同緩沖中去，降低了系統存儲的效率。分散性的定義就是上述情況發生的嚴重程度。好的哈希算法應能夠盡量避免不一致的情況發生，也就是盡量降低分散性。

負載(Load)：負載問題實際上是從另一個角度看待分散性問題。既然不同的終端可能將相同的內容映射到不同的緩沖區中，那么對于一個特定的緩沖區而言，也可能被不同的用戶映射為不同 的內容。與分散性一樣，這種情況也是應當避免的，因此好的哈希算法應能夠盡量降低緩沖的負荷。

在分布式集群中，對機器的添加刪除，或者機器故障后自動脫離集群這些操作是分布式集群管理最基本的功能。如果采用常用的hash(object)%N算法，那么在有機器添加或者刪除后，很多原有的數據就無法找到了，這樣嚴重的違反了單調性原則。

在了解一致性哈希算法之前，最好先了解一下緩存中的一個應用場景，了解了這個應用場景之后，再來理解一致性哈希算法，就容易多了，也更能體現出一致性哈希算法的優點，那么，我們先來描述一下這個經典的分布式緩存的應用場景。

場景描述

假設，我們有三臺緩存服務器，用于緩存圖片，我們為這三臺緩存服務器編號為0號、1號、2號，現在，有3萬張圖片需要緩存，我們希望這些圖片被均勻的緩存到這3臺服務器上，以便它們能夠分攤緩存的壓力。也就是說，我們希望每臺服務器能夠緩存1萬張左右的圖片，那么，我們應該怎樣做呢？如果我們沒有任何規律的將3萬張圖片平均的緩存在3臺服務器上，可以滿足我們的要求嗎？可以！但是如果這樣做，當我們需要訪問某個緩存項時，則需要遍歷3臺緩存服務器，從3萬個緩存項中找到我們需要訪問的緩存，遍歷的過程效率太低，時間太長，當我們找到需要訪問的緩存項時，時長可能是不能被接收的，也就失去了緩存的意義，緩存的目的就是提高速度，改善用戶體驗，減輕后端服務器壓力，如果每次訪問一個緩存項都需要遍歷所有緩存服務器的所有緩存項，想想就覺得很累，那么，我們該怎么辦呢？原始的做法是對緩存項的鍵進行哈希，將hash后的結果對緩存服務器的數量進行取模操作，通過取模后的結果，決定緩存項將會緩存在哪一臺服務器上，這樣說可能不太容易理解，我們舉例說明，仍然以剛才描述的場景為例，假設我們使用圖片名稱作為訪問圖片的key，假設圖片名稱是不重復的，那么，我們可以使用如下公式，計算出圖片應該存放在哪臺服務器上。

hash（圖片名稱）% N

因為圖片的名稱是不重復的，所以，當我們對同一個圖片名稱做相同的哈希計算時，得出的結果應該是不變的，如果我們有3臺服務器，使用哈希后的結果對3求余，那么余數一定是0、1或者2，沒錯，正好與我們之前的服務器編號相同，如果求余的結果為0， 我們就把當前圖片名稱對應的圖片緩存在0號服務器上，如果余數為1，就把當前圖片名對應的圖片緩存在1號服務器上，如果余數為2，同理，那么，當我們訪問任意一個圖片的時候，只要再次對圖片名稱進行上述運算，即可得出對應的圖片應該存放在哪一臺緩存服務器上，我們只要在這一臺服務器上查找圖片即可，如果圖片在對應的服務器上不存在，則證明對應的圖片沒有被緩存，也不用再去遍歷其他緩存服務器了，通過這樣的方法，即可將3萬張圖片隨機的分布到3臺緩存服務器上了，而且下次訪問某張圖片時，直接能夠判斷出該圖片應該存在于哪臺緩存服務器上，這樣就能滿足我們的需求了，我們暫時稱上述算法為HASH算法或者取模算法，取模算法的過程可以用下圖表示。

但是，使用上述HASH算法進行緩存時，會出現一些缺陷，試想一下，如果3臺緩存服務器已經不能滿足我們的緩存需求，那么我們應該怎么做呢？沒錯，很簡單，多增加兩臺緩存服務器不就行了，假設，我們增加了一臺緩存服務器，那么緩存服務器的數量就由3臺變成了4臺，此時，如果仍然使用上述方法對同一張圖片進行緩存，那么這張圖片所在的服務器編號必定與原來3臺服務器時所在的服務器編號不同，因為除數由3變為了4，被除數不變的情況下，余數肯定不同，這種情況帶來的結果就是當服務器數量變動時，所有緩存的位置都要發生改變，換句話說，當服務器數量發生改變時，所有緩存在一定時間內是失效的，當應用無法從緩存中獲取數據時，則會向后端服務器請求數據，同理，假設3臺緩存中突然有一臺緩存服務器出現了故障，無法進行緩存，那么我們則需要將故障機器移除，但是如果移除了一臺緩存服務器，那么緩存服務器數量從3臺變為2臺，如果想要訪問一張圖片，這張圖片的緩存位置必定會發生改變，以前緩存的圖片也會失去緩存的作用與意義，由于大量緩存在同一時間失效，造成了緩存的雪崩，此時前端緩存已經無法起到承擔部分壓力的作用，后端服務器將會承受巨大的壓力，整個系統很有可能被壓垮，所以，我們應該想辦法不讓這種情況發生，但是由于上述HASH算法本身的緣故，使用取模法進行緩存時，這種情況是無法避免的，為了解決這些問題，一致性哈希算法誕生了。

我們來回顧一下使用上述算法會出現的問題。
問題1：當緩存服務器數量發生變化時，會引起緩存的雪崩，可能會引起整體系統壓力過大而崩潰（大量緩存同一時間失效）。
問題2：當緩存服務器數量發生變化時，幾乎所有緩存的位置都會發生改變，怎樣才能盡量減少受影響的緩存呢？

其實，上面兩個問題是一個問題，那么，一致性哈希算法能夠解決上述問題嗎？
我們現在就來了解一下一致性哈希算法。

一致性哈希算法的基本概念

其實，一致性哈希算法也是使用取模的方法，只是，剛才描述的取模法是對服務器的數量進行取模，而一致性哈希算法是對2^32取模，什么意思呢？我們慢慢聊。

首先，我們把二的三十二次方想象成一個圓，就像鐘表一樣，鐘表的圓可以理解成由60個點組成的圓，而此處我們把這個圓想象成由2^32個點組成的圓，示意圖如下：

圓環的正上方的點代表0，0點右側的第一個點代表1，以此類推，2、3、4、5、6……直到2^{32-1,也就是說0點左側的第一個點代表2}32-1
我們把這個由2的32次方個點組成的圓環稱為hash環。

那么，一致性哈希算法與上圖中的圓環有什么關系呢？我們繼續聊，仍然以之前描述的場景為例，假設我們有3臺緩存服務器，服務器A、服務器B、服務器C，那么，在生產環境中，這三臺服務器肯定有自己的IP地址，我們使用它們各自的IP地址進行哈希計算，使用哈希后的結果對2^32取模，可以使用如下公式示意。
hash（服務器A的IP地址） % 2^32
通過上述公式算出的結果一定是一個0到2^{32-1之間的一個整數，我們就用算出的這個整數，代表服務器A，既然這個整數肯定處于0到2}32-1之間，那么，上圖中的hash環上必定有一個點與這個整數對應，而我們剛才已經說明，使用這個整數代表服務器A，那么，服務器A就可以映射到這個環上，用下圖示意

同理，服務器B與服務器C也可以通過相同的方法映射到上圖中的hash環中
hash（服務器B的IP地址） % 2^32
hash（服務器C的IP地址） % 2^32
通過上述方法，可以將服務器B與服務器C映射到上圖中的hash環上，示意圖如下

假設3臺服務器映射到hash環上以后如上圖所示（當然，這是理想的情況，我們慢慢聊）。

好了，到目前為止，我們已經把緩存服務器與hash環聯系在了一起，我們通過上述方法，把緩存服務器映射到了hash環上，那么使用同樣的方法，我們也可以將需要緩存的對象映射到hash環上。

假設，我們需要使用緩存服務器緩存圖片，而且我們仍然使用圖片的名稱作為找到圖片的key，那么我們使用如下公式可以將圖片映射到上圖中的hash環上。
hash（圖片名稱） % 2^32
映射后的示意圖如下，下圖中的橘黃色圓形表示圖片

好了，現在服務器與圖片都被映射到了hash環上，那么上圖中的這個圖片到底應該被緩存到哪一臺服務器上呢？上圖中的圖片將會被緩存到服務器A上，為什么呢？因為從圖片的位置開始，沿順時針方向遇到的第一個服務器就是A服務器，所以，上圖中的圖片將會被緩存到服務器A上，如下圖所示。

沒錯，一致性哈希算法就是通過這種方法，判斷一個對象應該被緩存到哪臺服務器上的，將緩存服務器與被緩存對象都映射到hash環上以后，從被緩存對象的位置出發，沿順時針方向遇到的第一個服務器，就是當前對象將要緩存于的服務器，由于被緩存對象與服務器hash后的值是固定的，所以，在服務器不變的情況下，一張圖片必定會被緩存到固定的服務器上，那么，當下次想要訪問這張圖片時，只要再次使用相同的算法進行計算，即可算出這個圖片被緩存在哪個服務器上，直接去對應的服務器查找對應的圖片即可。

剛才的示例只使用了一張圖片進行演示，假設有四張圖片需要緩存，示意圖如下

1號、2號圖片將會被緩存到服務器A上，3號圖片將會被緩存到服務器B上，4號圖片將會被緩存到服務器C上。

一致性哈希算法的優點

經過上述描述，我想兄弟你應該已經明白了一致性哈希算法的原理了，但是話說回來，一致性哈希算法能夠解決之前出現的問題嗎，我們說過，如果簡單的對服務器數量進行取模，那么當服務器數量發生變化時，會產生緩存的雪崩，從而很有可能導致系統崩潰，那么使用一致性哈希算法，能夠避免這個問題嗎？我們來模擬一遍，即可得到答案。

假設，服務器B出現了故障，我們現在需要將服務器B移除，那么，我們將上圖中的服務器B從hash環上移除即可，移除服務器B以后示意圖如下。

在服務器B未移除時，圖片3應該被緩存到服務器B中，可是當服務器B移除以后，按照之前描述的一致性哈希算法的規則，圖片3應該被緩存到服務器C中，因為從圖片3的位置出發，沿順時針方向遇到的第一個緩存服務器節點就是服務器C，也就是說，如果服務器B出現故障被移除時，圖片3的緩存位置會發生改變

但是，圖片4仍然會被緩存到服務器C中，圖片1與圖片2仍然會被緩存到服務器A中，這與服務器B移除之前并沒有任何區別，這就是一致性哈希算法的優點，如果使用之前的hash算法，服務器數量發生改變時，所有服務器的所有緩存在同一時間失效了，而使用一致性哈希算法時，服務器的數量如果發生改變，并不是所有緩存都會失效，而是只有部分緩存會失效，前端的緩存仍然能分擔整個系統的壓力，而不至于所有壓力都在同一時間集中到后端服務器上。

這就是一致性哈希算法所體現出的優點。

hash環的偏斜

在介紹一致性哈希的概念時，我們理想化的將3臺服務器均勻的映射到了hash環上，如下圖所示

但是，理想很豐滿，現實很骨感，我們想象的與實際情況往往不一樣。

在實際的映射中，服務器可能會被映射成如下模樣。

聰明如你一定想到了，如果服務器被映射成上圖中的模樣，那么被緩存的對象很有可能大部分集中緩存在某一臺服務器上，如下圖所示。

上圖中，1號、2號、3號、4號、6號圖片均被緩存在了服務器A上，只有5號圖片被緩存在了服務器B上，服務器C上甚至沒有緩存任何圖片，如果出現上圖中的情況，A、B、C三臺服務器并沒有被合理的平均的充分利用，緩存分布的極度不均勻，而且，如果此時服務器A出現故障，那么失效緩存的數量也將達到最大值，在極端情況下，仍然有可能引起系統的崩潰，上圖中的情況則被稱之為hash環的偏斜，那么，我們應該怎樣防止hash環的偏斜呢？一致性hash算法中使用"虛擬節點"解決了這個問題，我們繼續聊。

虛擬節點

話接上文，由于我們只有3臺服務器，當我們把服務器映射到hash環上的時候，很有可能出現hash環偏斜的情況，當hash環偏斜以后，緩存往往會極度不均衡的分布在各服務器上，聰明如你一定已經想到了，如果想要均衡的將緩存分布到3臺服務器上，最好能讓這3臺服務器盡量多的、均勻的出現在hash環上，但是，真實的服務器資源只有3臺，我們怎樣憑空的讓它們多起來呢，沒錯，就是憑空的讓服務器節點多起來，既然沒有多余的真正的物理服務器節點，我們就只能將現有的物理節點通過虛擬的方法復制出來，這些由實際節點虛擬復制而來的節點被稱為"虛擬節點"。加入虛擬節點以后的hash環如下。

“虛擬節點"是"實際節點”（實際的物理服務器）在hash環上的復制品,一個實際節點可以對應多個虛擬節點。
從上圖可以看出，A、B、C三臺服務器分別虛擬出了一個虛擬節點，當然，如果你需要，也可以虛擬出更多的虛擬節點。引入虛擬節點的概念后，緩存的分布就均衡多了，上圖中，1號、3號圖片被緩存在服務器A中，5號、4號圖片被緩存在服務器B中，6號、2號圖片被緩存在服務器C中，如果你還不放心，可以虛擬出更多的虛擬節點，以便減小hash環偏斜所帶來的影響，虛擬節點越多，hash環上的節點就越多，緩存被均勻分布的概率就越大。

總結

以上是生活随笔為你收集整理的分布式缓存——一致性哈希算法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。