一.前言
一致性雜湊(Consistent Hashing)，最早由MIT的Karger於1997年提出，主要用於解決易變的分散式Web系統中，由於當機和擴容導致的服務震盪。現在這個演算法思路被大量應用，並且在實踐中得到了很大的發展。
二.演算法設計
1.問題來源
一個由6臺伺服器組成的服務，每臺Server負責儲存1/6的資料，當Server1出現當機之後，服務重新恢復可用時的場景。
如下表格可以很清楚的看到，當Server1當機時，Hash1的服務完全不可用了，所以需要ReHash由剩餘5臺機器提供所有的資料服務，但由於每臺機器負責的資料段大小不相同，那麼需要在不同的伺服器之間大量遷移資料，並且資料遷移完成之前服務會不可用。
2.經典一致性雜湊演算法
針對ReHash的弊端，Karger提出了一種演算法，演算法的核心是”虛擬節點”。
將所有的資料對映成一組大於伺服器數量的虛擬節點，虛擬節點再對映到真實的伺服器。所以當伺服器當機時，由於虛擬節點的數量固定不變，所有不需要ReHash，而只需要將服務不可用的虛擬節點重新遷移，這樣只需要遷移當機節點的資料。
經典的演算法中，當機伺服器的下一個真實節點將提供服務。
三.演算法改進
1.經典一致性雜湊演算法的問題
經典的演算法只是解決了ReHash演算法的缺陷，當本身並不完美。主要存在以下幾個問題：
(1)Server1當機會導致Server2的服務承受一倍的資料服務，且如果Server1就此退役，那麼整個系統的負載完全不均衡了。
(2)如果所有的Server都能承受一倍的資料讀寫，那麼如果在正常情況下所有的資料寫兩份到不同的伺服器，主備或者負載均衡，當機時直接讀備份節點的資料，根本不需要出現經典演算法中的資料遷移。
2.Dynamo改進實踐
Amazon的大資料儲存平臺”Dynamo”使用了一致性雜湊，但它並沒有使用經典演算法，而是使用了故障節點ReHash的思路。
系統將所有的虛擬節點和真實伺服器的對應關係儲存到一個配置系統，當某些虛擬節點的服務不可用時，重新配置這些虛擬節點的服務到其他真實伺服器，這樣既不用大量遷移資料，也保證了所有伺服器的負載相對均衡。
| 虛擬節點 | 0-4/5 | 10-14/6 | 15-19/7 | 20-24/8 | 24-29/9 |
| 恢復 | Server0 | Server2 | Server3 | Server4 | Server5 |
四.演算法擴充套件
一致性雜湊演算法本身是用於解決伺服器當機與擴容的問題，但”虛擬節點”的演算法思想有所發展，一些分散式的系統用於實現系統的負載均衡和最優訪問策略。
在真實的系統情況下，相同部署的兩套系統可能不能提供相同的服務，主要原因：
(1)硬體個體差異導致伺服器效能不同。
(2)機房交換機和網路頻寬導致IDC伺服器之間的網路通訊效率不同。
(3)使用者使用不同的網路運營商導致電信IDC和聯通IDC提供的服務效能不同。
(4)伺服器所在網路或機房遭遇攻擊。
所以完全相同的兩套系統可能也需要提供差異化的服務，通過使用虛擬節點可以靈活的動態調整，達到系統服務的最優化。
對於由2個節點，每個節點3臺伺服器組成的分散式系統，S0-1為分散式系統1的Server0，系統配置管理員可以根據系統真實的服務效率動態的調整虛擬節點與真實伺服器的對映關係，也可以由客戶系統自身根據響應率或響應時間等情況調整自身的訪問策略。
| 虛擬節點 | 0-2 | 3-4 | 5-7 | 8-9 | 10-12 | 13-14 |
| 伺服器 | S0-1 | S0-2 | S1-1 | S1-2 | S2-1 | S2-2 |
五.Reference
(1)一致雜湊(wiki)
(2)Consistent hashing
(3)Dynamo: Amazon’s Highly Available Key-value Store