一致性哈希算法原理設計

原文出處： 知致智之   歡迎分享原創到伯樂頭條

一.前言

一致性哈希(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