簡單的路由演算法可以使用餘數 hash：用伺服器資料除快取資料 key 的 hash 值，餘數為伺服器列表下標編碼。這種演算法可以滿足大多數的快取路由需求。但是，當分布式快取集群需要擴容的時候，事情就變得棘手了。舉個例子：很容易可以計算出，3臺快取伺服器擴容至4臺伺服器，大約有 75%（3/4）被快取了的資料不能正確命中，隨著伺服器集群規模的增大，這個比例線性上公升。當100臺伺服器的集群中加入一台新伺服器，不能命中的概率是 99%（n/n+1）。這種結果顯然是不能接受的。
一種解決辦法是在**訪問量最少的時候擴容快取伺服器集群，這時候資料庫的負載衝擊最小。然後通過模擬請求的方法逐漸預熱快取，使快取伺服器中的資料重新分布。但這種方案對業務場景有要求，還需要技術團隊通宵加班。當然還有比流行的方案：一致性hash 演算法。
具體演算法過程為：先構造乙個長度為
整數環（這個環被稱作一致性 hash環）根據節點名稱的 hash 值（其分布範圍為[0，
-1]）將快取伺服器節點放置在這個 hash 環上。然後根據需要快取的資料的 key 值計算得到其 hash 值（其分布範圍也同樣為[0，
-1]），然後在 hash 環上順時針查詢距離這個 key 的 hash 值最近的快取伺服器節點，完成 key 到伺服器的 hash 對映查詢。
具體應用中，這個長度為
的一致性 hash 環通常使用二叉查詢樹實現，hash 查詢過程實際上是在二叉查詢樹中查詢不小於查詢樹的最小數值。當然這個二叉樹的最右邊葉子節點和最左邊的葉子節點相連線，構成環。
新加入的節點 node5 只影響了原有節點 node4，也就是說一部分原來需要訪問 node4 的快取資料現在訪問 node5（概率上是50%）。但是原來的其它節點不受影響，這就意味著其它節點快取資料量和負載壓力是 node4 和 node5 的兩倍。如果所有節點的硬體和效能一樣，那麼這個結果顯然不是我們需要的。
雖然每個物理節點對應的虛擬節點越多，各個物理節點之間的負載越均衡，新加入物理伺服器對原有的物理伺服器的影響越保持一致（這就是一致性 hash 這個名稱的由來）。在實踐中，一台物理伺服器虛擬為多少個虛擬伺服器節點比較合適呢？太多會影響效能，太少會導致負載不均衡，一般來說，經驗值是150，當然根據集群規模和負載均衡的精度需求，這個值應該根據具體情況具體對待。
----
分布式快取的一致性Hash演算法
具體過程 1 先構造乙個長度為0 2 32的整數環，根據節點名稱的hash值，將快取伺服器節點放置在這個hash環上。2 根據需要快取的資料的key值計算得到其hash值，然後在hash環上順時針查詢距離這個key值的hash值最近的快取伺服器節點，完成key到伺服器的hash對映查詢。補充 這個一...
分布式一致性Hash演算法
介紹一致性hash演算法之前,先簡單回顧一下分布式以及hash演算法,便於理解為什麼要有一致性hash演算法。當我們也無需求很複雜時,單台機器io以及頻寬等都會成為瓶頸,所以對業務進行拆分,部署在不同的機器上,當有請求訪問時,根據某些特點將這些請求分散到各個伺服器上,這所有的伺服器組成的網路,我們稱...
redis分布式一致性hash演算法
當我們在部署redis節點時，使用者鏈結redis儲存資料會通過hash演算法來定位具體鏈結那個redis節點，在redis節點數量沒有改變的前提下，之前的使用者通過hash演算法會固定的鏈結某一台redis節點，但是若此時我們增加了redis節點，使用者再次hash時，能會hash到別的redis...