【數據結構與算法】一致性哈希算法

來源

https://www.sohu.com/a/158141377_479559

一致性哈希算法

簡稱DHT，主要應用於分佈式緩存中，可以有效地解決分佈式存儲結構下動態增加和刪除節點所帶來的問題。

例子

1. 首先，我們把全量的緩存空間當做一個環形存儲結構。環形空間總共分成2^32個緩存區，在Redis中則是把緩存key分配到16384個slot。
   
2. 每一個緩存key都可以通過Hash算法轉化爲一個32位的二進制數，也就對應着環形空間的某一個緩存區。我們把所有的緩存key映射到環形空間的不同位置。
   
3. 我們的每一個緩存節點（Shard）也遵循同樣的Hash算法，比如利用IP做Hash，映射到環形空間當中。
   
4. 如何讓key和節點對應起來呢？很簡單，每一個key的順時針方向最近節點，就是key所歸屬的存儲節點。所以圖中key1存儲於node1，key2，key3存儲於node2，key4存儲於node3。
   

優點

當增加或刪除節點時

1. 增加節點
   當緩存集羣的節點有所增加的時候，整個環形空間的映射仍然會保持一致性哈希的順時針規則，所以有一小部分key的歸屬會受到影響。
   
   有哪些key會受到影響呢？圖中加入了新節點node4，處於node1和node2之間，按照順時針規則，從node1到node4之間的緩存不再歸屬於node2，而是歸屬於新節點node4。因此受影響的key只有key2。
   最終把key2的緩存數據從node2遷移到node4，就形成了新的符合一致性哈希規則的緩存結構。
   
2. 刪除節點
   當緩存集羣的節點需要刪除的時候（比如節點掛掉），整個環形空間的映射同樣會保持一致性哈希的順時針規則，同樣有一小部分key的歸屬會受到影響。
   
   有哪些key會受到影響呢？圖中刪除了原節點node3，按照順時針規則，原本node3所擁有的緩存數據就需要“託付”給node3的順時針後繼節點node1。因此受影響的key只有key4。
   

最終把key4的緩存數據從node3遷移到node1，就形成了新的符合一致性哈希規則的緩存結構。

問題

緩存節點都是按IP來Hash到環形空間，可能會出現分佈不均勻的情況，比如所有的key都歸屬於同一個節點。

解決（虛擬節點）

基於原來的物理節點映射出N個子節點，最後把所有的子節點映射到環形空間上。

如上圖所示，假如node1的ip是192.168.1.109，那麼原node1節點在環形空間的位置就是hash（“192.168.1.109”）。

我們基於node1構建兩個虛擬節點，node1-1 和 node1-2，虛擬節點在環形空間的位置可以利用（IP+後綴）計算，例如：

hash（“192.168.1.109#1”），hash（“192.168.1.109#2”）

此時，環形空間中不再有物理節點node1，node2，只有虛擬節點node1-1，node1-2，node2-1，node2-2。由於虛擬節點數量較多，緩存key與虛擬節點的映射關係也變得相對均衡了。

爲什麼一致性哈希算法更多的應用於像Redis這樣的緩存數據庫

由於分佈式緩存系統的節點部署變化更頻繁，而傳統關係型數據庫的分佈分表相對穩定，不過mysql，仍然可以用一致性哈希表的思想，雖然處理邏輯會複雜一些，卻可以避免動態水平擴展時候的尷尬。

再舉例

一致性哈希算法，舉個栗子：
我們鐘錶有 60 分鐘，從 0 開始到 59，共 60 個點。
現在我們將機器往這 60 個點分配，規則如下：
hash(ip) % 60。

假設有 3 臺機器 A，B 和 C，分別被分配到了 14，37 和 46 這三個點上。

圖片的分配規則類似：
hash(image_id) % 60。
現有 3 張圖片 x， y， z，分別被分配到 5，30，50 這三個點。

很明示，圖片都沒被分配到機器的節點上，怎麼辦呢?在鐘錶上順時鐘往前尋找，第一臺遇到的機器，就是它的歸屬。

— 我是分割線 —

現在很不湊巧，A B C 三臺機器分別分配到 5，10，15 這三個點。這樣對 A 是很不公平的吖，要負責存儲絕大多數的圖片，那這怎麼辦呢?我們社會主義核心價值觀基本內容：和諧、平等、公正。爲建設和諧社會努力奮鬥！！

爲了避免不必要的爭端，我們引入“虛擬節點”，每臺機器都可以拔一根汗毛，變成若干臺，把虛擬節點分散到 60 個點上，歸屬“虛擬節點”的圖片，均保存到它的真身。這樣就能解決分配不均勻的問題。

---

應用時，將 60 替換下即可，如替換爲 2的 32 次方