昨天瞭解到了關於一致性哈希的一些思想，感覺簡直神仙，今天整理一下。
一致性哈希算法的應用
目前，一致性hash算法在分佈式系統中也得到了廣泛應用。他可以把數據遷移的代價變得很低而又負載均衡。是不是很神仙！
經典的服務器抗壓結構
傳統用戶請求的時候是通過一系列算法，最後映射這個請求到服務器集羣的某臺服務器上，實現負載均衡。
但是這種方式會有一個問題，當需要添加服務器或者是減少服務器時，服務器上的數據歸屬發生了變化，例如用戶A的信息本來存在server3上。現在必須要重新計算A的歸屬服務器進行數據遷移。需要將所有服務器上的數據進行重新計算插入，這樣才能得到添加服務器之後的數據。代價無疑是巨大的。
傳統的分佈式系統中，如果添加一個節點所需要的數據遷移的代價是很大的，那麼怎麼辦呢？當然是一致性哈希啦！
一致性哈希
解決數據遷移量大問題—hash成環
我們現在假設請求進行hash之後的範圍是0-n，那麼我們將hash之後的結果，想象成一個環。假設現在有三臺機器，那麼每臺機器放在環上，對每次請求的哈希結果在他管理範圍之內的數據進行管理。那麼管理範圍是多少呢？
按照順時針方向，節點之前的哈希值都是自己管理的範圍。以上圖爲例，A需要管理紅色部分的hash結果，B爲藍色，C爲綠色。如當想要添加用戶A信息的一個請求時，進行hash計算後的值落在紅色部分，那麼這個請求就有A節點來負責。
這樣有什麼好處呢？我們可以隨意的添加節點或者刪除節點，比如AB之間添加一個D節點，那麼只需要將A到D直接的數據從B中遷移到D中，B負責D到B哈希結果的數據就好了！同理，刪除節點同樣代價小。
如下圖：
那麼問題來了 這樣做確實時減少了數據遷移的代價，但是我們看到ABCD的位置不夠均衡，這樣C和A處理的請求明顯要比A和B的多。怎樣才能負載均衡？
解決負載均衡問題----虛擬節點
虛擬節點的想法很簡單也很經典！簡直是神仙想法！
每個虛擬節點負責一定範圍的hash值。其實意思就是我們計算出請求的hash結果後，我們就能在環上知道是哪個虛擬節點負責處理，然後通過查找虛擬節點和機器的對應表，我們就能知道真實節點。
我們假設有ABC三個節點機器，假設hash之後的虛擬節點範圍是0-2999，那麼，我們可以通過一張表，來對應每個節點機器所擁有的虛擬節點。例如我們可以從0-2999中隨便找1000個讓A負責，剩下的2000交給BC負責，那麼我們只要維護好這張表就能保證，在有請求的時候，得到的hash結果我們能找到相應的虛擬節點，通過虛擬節點和機器的映射表。我們可以找到這臺機器處理請求。這麼做有什麼好處呢？
當有新的服務器D接入時，我們可以從ABC中分別取出一定數量的虛擬節點交給機器D來處理，所需做的僅僅是修改一下表格，並且把ABC相應虛擬節點的數據遷移到D中，這樣即做到了負載均衡又做到了數據遷移代價小，
