資料結構與演算法一致性雜湊演算法

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

首先，我們把全量的快取空間當做乙個環形儲存結構。環形空間總共分成2^32個快取區，在redis中則是把快取key分配到16384個slot。

每乙個快取key都可以通過hash演算法轉化為乙個32位的二進位制數，也就對應著環形空間的某乙個快取區。我們把所有的快取key對映到環形空間的不同位置。

我們的每乙個快取節點（shard）也遵循同樣的hash演算法，比如利用ip做hash，對映到環形空間當中。

如何讓key和節點對應起來呢？很簡單，每乙個key的順時針方向最近節點，就是key所歸屬的儲存節點。所以圖中key1儲存於node1，key2，key3儲存於node2，key4儲存於node3。

當增加或刪除節點時

增加節點

當快取集群的節點有所增加的時候，整個環形空間的對映仍然會保持一致性雜湊的順時針規則，所以有一小部分key的歸屬會受到影響。

有哪些key會受到影響呢？圖中加入了新節點node4，處於node1和node2之間，按照順時針規則，從node1到node4之間的快取不再歸屬於node2，而是歸屬於新節點node4。因此受影響的key只有key2。

最終把key2的快取資料從node2遷移到node4，就形成了新的符合一致性雜湊規則的快取結構。

刪除節點

當快取集群的節點需要刪除的時候（比如節點掛掉），整個環形空間的對映同樣會保持一致性雜湊的順時針規則，同樣有一小部分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與虛擬節點的對映關係也變得相對均衡了。

由於分布式快取系統的節點部署變化更頻繁，而傳統關係型資料庫的分布分表相對穩定，不過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 次方

資料結構與演算法 一致性雜湊演算法