大白話聊聊分散式系統中如何使用一致性雜湊演算法？
公眾號後臺回覆“ 資料 ”
獲取作者獨家祕製學習資料
本文將會從實際應用場景出發，介紹 一致性雜湊演算法 （Consistent Hashing）及其在分散式系統中的應用。
首先本文會描述一個在日常開發中經常會遇到的問題場景，藉此介紹一致性雜湊演算法以及這個演算法如何解決此問題。
接下來會對這個演算法進行相對詳細的描述，並討論一些如虛擬節點等與此演算法應用相關的話題。
分散式快取
假設我們有一個網站，最近發現隨著流量增加，伺服器壓力越來越大，之前直接讀寫資料庫的方式不太給力了，於是我們想引入Memcached作為快取機制。
現在我們一共有三臺機器可以作為Memcached伺服器， 如下圖所示：
很顯然，最簡單的策略是將每一次Memcached請求隨機發送到一臺Memcached伺服器，但是這種策略可能會帶來兩個如下問題：
-
同一份資料可能被存在不同的機器上而造成資料冗餘；
-
有可能某資料已經被快取但是訪問卻沒有命中，因為無法保證對相同key的所有訪問都被髮送到相同的伺服器。
因此，隨機策略無論是時間效率還是空間效率都非常不好。
要解決上述問題只需做到如下一點：保證對相同key的訪問會被髮送到相同的伺服器。
很多方法可以實現這一點，最常用的方法是 計算雜湊 。假設對於上圖，對於每次訪問，可以按如下演算法計算其雜湊值： h = Hash(key) % 3
其中Hash是一個從字串到正整數的雜湊對映函式。這樣，如果我們將Memcached Server分別編號為0、1、2，那麼就可以根據上式和key計算出伺服器編號h，然後去訪問。
這個方法 雖然解決了上面提到的兩個問題，但是 存在一些其它的問題， 如果將上述方法抽象，可以認為通過： h = Hash(key) % N 。
這個算式計算每個key的請求應該被髮送到哪臺伺服器，其中N為伺服器的臺數，並且伺服器按照0 – (N-1)編號。
這個演算法的問題在於 容錯性和擴充套件性不好 。
所謂容錯性是指當系統中某一個或幾個伺服器變得不可用時，整個系統是否可以正確高效執行；而擴充套件性是指當加入新的伺服器後，整個系統是否可以正確高效執行。
現假設有一臺伺服器宕機了 ，那麼為了填補空缺，要將宕機的伺服器從編號列表中移除，後面的伺服器按順序前移一位並將其編號值減一，此時每個key就要按h = Hash(key) % (N-1)重新計算。
同樣，如果新增了一臺伺服器 ，雖然原有伺服器編號不用改變，但是要按h = Hash(key) % (N+1)重新計算雜湊值。
因此係統中一旦有伺服器變更，大量的key會被重定位到不同的伺服器從而造成大量的快取不命中。而這種情況在分散式系統中是非常糟糕的。
一個設計良好的分散式雜湊方案應該具有 良好的單調性 ，即服務節點的增減不會造成大量雜湊重定位。一致性雜湊演算法就是這樣一種雜湊方案。
一致性雜湊演算法
簡單來說，一致性雜湊將整個雜湊值空間組織成一個虛擬的圓環，如假設某雜湊函式H的值空間為0 - 232-1（即雜湊值是一個32位無符號整形）。
整個雜湊空間環如下：
整個空間按順時針方向組織。 0和232-1在零點中方向重合 。
下一步 將各個伺服器使用H進行一個雜湊，具體可以選擇伺服器的ip或主機名作為關鍵字進行雜湊 ，這樣每臺機器就能確定其在雜湊環上的位置
這裡假設將上文中三臺伺服器使用ip地址雜湊後在環空間的位置如下：
接下來使用如下演算法定位資料訪問到相應伺服器： 將資料key使用相同的函式H計算出雜湊值h，通根據h確定此資料在環上的位置，從此位置沿環順時針“行走”， 第一臺遇到的伺服器就是其應該定位到的伺服器。
例如我們有A、B、C、D四個資料物件，經過雜湊計算後，在環空間上的位置如下：
根據一致性雜湊演算法，資料A會被定為到Server 1上，D被定為到Server 3上，而B、C分別被定為到Server 2上。
容錯性和擴充套件性分析
下面分析一致性雜湊演算法的容錯性和可擴充套件性。現 假設Server 3宕 機了：
可以看到此時A、C、B不會受到影響， 只有D節點被重定位到Server 2 。
一般的，在一致性雜湊演算法中，如果一臺伺服器不可用，則受影響的資料僅僅是此伺服器到其環空間中前一臺伺服器（即順著逆時針方向行走遇到的第一臺伺服器）之間資料，其它不會受到影響。
下面考慮另外一種情況，如果我們 在系統中增加一臺伺服器Memcached Server 4：
此時A、D、C不受影響， 只有B需要重定位到新的Server 4 。
一般的，在一致性雜湊演算法中，如果增加一臺伺服器，則受影響的資料僅僅是新伺服器到其環空間中前一臺伺服器（即順著逆時針方向行走遇到的第一臺伺服器）之間資料，其它不會受到影響。
綜上所述，一致性雜湊演算法對於節點的增減都只需重定位環空間中的一小部分資料，具有較好的容錯性和可擴充套件性。
虛擬節點
一致性雜湊演算法在服務節點太少時，容易因為節點分部不均勻而造成 資料傾斜問題 。
例如我們的系統中有兩臺伺服器，其環分佈如下：
此時必然造成大量資料集中到Server 1上，而只有極少量會定位到Server 2上。
為了解決這種資料傾斜問題，一致性雜湊演算法 引入了 虛擬節點機制 ，即對每一個服務節點計算多個雜湊，每個計算結果位置都放置一個此服務節點，稱為虛擬節點。
具體做法 可以在伺服器ip或主機名的後面增加編號來實現， 例如上面的情況，我們決定為每臺伺服器計算三個虛擬節點。
我們可以分別計算下面節點的雜湊值：
-
“Memcached Server 1#1”
-
“Memcached Server 1#2”
-
“Memcached Server 1#3”
-
“Memcached Server 2#1”
-
“Memcached Server 2#2”
-
“Memcached Server 2#3”
於是形成六個虛擬節點：
同時資料定位演算法不變，只是多了一步虛擬節點到實際節點的對映，例如定位到下面三個虛擬節點的資料均定位到Server 1上。
-
“Memcached Server 1#1”
-
“Memcached Server 1#2”
-
“Memcached Server 1#3”
這樣就解決了服務節點少時資料傾斜的問題。在實際應用中，通常將虛擬節點數設定為32甚至更大，因此即使很少的服務節點也能做到相對均勻的資料分佈。
總結
目前一致性雜湊基本成為了分散式系統元件的標準配置，例如Memcached的各種客戶端都提供內建的一致性雜湊支援。
本文只是簡要介紹了這個演算法，更深入的內容可以參看論文《 Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web 》。
出自：
http://blog.codinglabs.org/articles/consistent-hashing.html
END
歡迎長按下圖關注公眾號 石杉的架構筆記 ，後臺回覆“ 資料 ”，獲取作者獨家祕製學習資料！
BAT架構經驗傾囊相授
