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

場景描述

假設，我們有三臺緩存服務器，用于緩存圖片，我們為這三臺緩存服務器編號為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環上的節點就越多，緩存被均勻分布的概率就越大。

? ?

好了，一致性哈希算法的原理就總結到這里，如有錯誤，歡迎賜教，如需轉載，請標注原文鏈接。

原文鏈接：白話解析：一致性哈希算法 consistent hashing

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的白话解析：一致性哈希算法 consistent hashing的全部內容，希望文章能夠幫你解決所遇到的問題。

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