一致性Hash算法

關(guān)于一致性Hash算法，在我之前的博文中已經(jīng)有多次提到了，MemCache超詳細(xì)解讀一文中"一致性Hash算法"部分，對于為什么要使用一致性Hash算法、一致性Hash算法的算法原理做了詳細(xì)的解讀。

算法的具體原理這里再次貼上：

先構(gòu)造一個長度為2³²的整數(shù)環(huán)（這個環(huán)被稱為一致性Hash環(huán)），根據(jù)節(jié)點名稱的Hash值（其分布為[0, 2³²-1]）將服務(wù)器節(jié)點放置在這個Hash環(huán)上，然后根據(jù)數(shù)據(jù)的Key值計算得到其Hash值（其分布也為[0, 2³²-1]），接著在Hash環(huán)上順時針查找距離這個Key值的Hash值最近的服務(wù)器節(jié)點，完成Key到服務(wù)器的映射查找。

這種算法解決了普通余數(shù)Hash算法伸縮性差的問題，可以保證在上線、下線服務(wù)器的情況下盡量有多的請求命中原來路由到的服務(wù)器。

當(dāng)然，萬事不可能十全十美，一致性Hash算法比普通的余數(shù)Hash算法更具有伸縮性，但是同時其算法實現(xiàn)也更為復(fù)雜，本文就來研究一下，如何利用Java代碼實現(xiàn)一致性Hash算法。在開始之前，先對一致性Hash算法中的幾個核心問題進(jìn)行一些探究。

?

數(shù)據(jù)結(jié)構(gòu)的選取

一致性Hash算法最先要考慮的一個問題是：構(gòu)造出一個長度為2³²的整數(shù)環(huán)，根據(jù)節(jié)點名稱的Hash值將服務(wù)器節(jié)點放置在這個Hash環(huán)上。

那么，整數(shù)環(huán)應(yīng)該使用何種數(shù)據(jù)結(jié)構(gòu)，才能使得運(yùn)行時的時間復(fù)雜度最低？首先說明一點，關(guān)于時間復(fù)雜度，常見的時間復(fù)雜度與時間效率的關(guān)系有如下的經(jīng)驗規(guī)則：

O(1) < O(log₂N) < O(n) < O(N * log₂N) < O(N²) < O(N³) < 2N < 3N < N!

一般來說，前四個效率比較高，中間兩個差強(qiáng)人意，后三個比較差（只要N比較大，這個算法就動不了了）。OK，繼續(xù)前面的話題，應(yīng)該如何選取數(shù)據(jù)結(jié)構(gòu)，我認(rèn)為有以下幾種可行的解決方案。

1、解決方案一：排序+List

我想到的第一種思路是：算出所有待加入數(shù)據(jù)結(jié)構(gòu)的節(jié)點名稱的Hash值放入一個數(shù)組中，然后使用某種排序算法將其從小到大進(jìn)行排序，最后將排序后的數(shù)據(jù)放入List中，采用List而不是數(shù)組是為了結(jié)點的擴(kuò)展考慮。

之后，待路由的結(jié)點，只需要在List中找到第一個Hash值比它大的服務(wù)器節(jié)點就可以了，比如服務(wù)器節(jié)點的Hash值是[0,2,4,6,8,10]，帶路由的結(jié)點是7，只需要找到第一個比7大的整數(shù)，也就是8，就是我們最終需要路由過去的服務(wù)器節(jié)點。

如果暫時不考慮前面的排序，那么這種解決方案的時間復(fù)雜度：

（1）最好的情況是第一次就找到，時間復(fù)雜度為O(1)

（2）最壞的情況是最后一次才找到，時間復(fù)雜度為O(N)

平均下來時間復(fù)雜度為O(0.5N+0.5)，忽略首項系數(shù)和常數(shù)，時間復(fù)雜度為O(N)。

但是如果考慮到之前的排序，我在網(wǎng)上找了張圖，提供了各種排序算法的時間復(fù)雜度：

看得出來，排序算法要么穩(wěn)定但是時間復(fù)雜度高、要么時間復(fù)雜度低但不穩(wěn)定，看起來最好的歸并排序法的時間復(fù)雜度仍然有O(N * logN)，稍微耗費(fèi)性能了一些。

2、解決方案二：遍歷+List

既然排序操作比較耗性能，那么能不能不排序？可以的，所以進(jìn)一步的，有了第二種解決方案。

解決方案使用List不變，不過可以采用遍歷的方式：

（1）服務(wù)器節(jié)點不排序，其Hash值全部直接放入一個List中

（2）帶路由的節(jié)點，算出其Hash值，由于指明了"順時針"，因此遍歷List，比待路由的節(jié)點Hash值大的算出差值并記錄，比待路由節(jié)點Hash值小的忽略

（3）算出所有的差值之后，最小的那個，就是最終需要路由過去的節(jié)點

在這個算法中，看一下時間復(fù)雜度：

1、最好情況是只有一個服務(wù)器節(jié)點的Hash值大于帶路由結(jié)點的Hash值，其時間復(fù)雜度是O(N)+O(1)=O(N+1)，忽略常數(shù)項，即O(N)

2、最壞情況是所有服務(wù)器節(jié)點的Hash值都大于帶路由結(jié)點的Hash值，其時間復(fù)雜度是O(N)+O(N)=O(2N)，忽略首項系數(shù)，即O(N)

所以，總的時間復(fù)雜度就是O(N)。其實算法還能更改進(jìn)一些：給一個位置變量X，如果新的差值比原差值小，X替換為新的位置，否則X不變。這樣遍歷就減少了一輪，不過經(jīng)過改進(jìn)后的算法時間復(fù)雜度仍為O(N)。

總而言之，這個解決方案和解決方案一相比，總體來看，似乎更好了一些。

3、解決方案三：二叉查找樹

拋開List這種數(shù)據(jù)結(jié)構(gòu)，另一種數(shù)據(jù)結(jié)構(gòu)則是使用二叉查找樹。對于樹不是很清楚的朋友可以簡單看一下這篇文章樹形結(jié)構(gòu)。

當(dāng)然我們不能簡單地使用二叉查找樹，因為可能出現(xiàn)不平衡的情況。平衡二叉查找樹有AVL樹、紅黑樹等，這里使用紅黑樹，選用紅黑樹的原因有兩點：

1、紅黑樹主要的作用是用于存儲有序的數(shù)據(jù)，這其實和第一種解決方案的思路又不謀而合了，但是它的效率非常高

2、JDK里面提供了紅黑樹的代碼實現(xiàn)TreeMap和TreeSet

另外，以TreeMap為例，TreeMap本身提供了一個tailMap(K fromKey)方法，支持從紅黑樹中查找比fromKey大的值的集合，但并不需要遍歷整個數(shù)據(jù)結(jié)構(gòu)。

使用紅黑樹，可以使得查找的時間復(fù)雜度降低為O(logN)，比上面兩種解決方案，效率大大提升。

為了驗證這個說法，我做了一次測試，從大量數(shù)據(jù)中查找第一個大于其中間值的那個數(shù)據(jù)，比如10000數(shù)據(jù)就找第一個大于5000的數(shù)據(jù)（模擬平均的情況）。看一下O(N)時間復(fù)雜度和O(logN)時間復(fù)雜度運(yùn)行效率的對比：

?	50000	100000	500000	1000000	4000000
ArrayList	1ms	1ms	4ms	4ms	5ms
LinkedList	4ms	7ms	11ms	13ms	17ms
TreeMap	0ms	0ms	0ms	0ms	0ms

因為再大就內(nèi)存溢出了，所以只測試到4000000數(shù)據(jù)。可以看到，數(shù)據(jù)查找的效率，TreeMap是完勝的，其實再增大數(shù)據(jù)測試也是一樣的，紅黑樹的數(shù)據(jù)結(jié)構(gòu)決定了任何一個大于N的最小數(shù)據(jù)，它都只需要幾次至幾十次查找就可以查到。

當(dāng)然，明確一點，有利必有弊，根據(jù)我另外一次測試得到的結(jié)論是，為了維護(hù)紅黑樹，數(shù)據(jù)插入效率TreeMap在三種數(shù)據(jù)結(jié)構(gòu)里面是最差的，且插入要慢上5~10倍。

?

Hash值重新計算

服務(wù)器節(jié)點我們肯定用字符串來表示，比如"192.168.1.1"、"192.168.1.2"，根據(jù)字符串得到其Hash值，那么另外一個重要的問題就是Hash值要重新計算，這個問題是我在測試String的hashCode()方法的時候發(fā)現(xiàn)的，不妨來看一下為什么要重新計算Hash值：

/*** String的hashCode()方法運(yùn)算結(jié)果查看* @author 五月的倉頡 http://www.cnblogs.com/xrq730/**/ public class StringHashCodeTest {public static void main(String[] args){System.out.println("192.168.0.0:111的哈希值：" + "192.168.0.0:1111".hashCode());System.out.println("192.168.0.1:111的哈希值：" + "192.168.0.1:1111".hashCode());System.out.println("192.168.0.2:111的哈希值：" + "192.168.0.2:1111".hashCode());System.out.println("192.168.0.3:111的哈希值：" + "192.168.0.3:1111".hashCode());System.out.println("192.168.0.4:111的哈希值：" + "192.168.0.4:1111".hashCode());} }

我們在做集群的時候，集群點的IP以這種連續(xù)的形式存在是很正常的。看一下運(yùn)行結(jié)果為：

192.168.0.0:111的哈希值：1845870087 192.168.0.1:111的哈希值：1874499238 192.168.0.2:111的哈希值：1903128389 192.168.0.3:111的哈希值：1931757540 192.168.0.4:111的哈希值：1960386691

這個就問題大了，[0,2³²-1]的區(qū)間之中，5個HashCode值卻只分布在這么小小的一個區(qū)間，什么概念？[0,2³²-1]中有4294967296個數(shù)字，而我們的區(qū)間只有114516604，從概率學(xué)上講這將導(dǎo)致97%待路由的服務(wù)器都被路由到"192.168.0.0"這個集群點上，簡直是糟糕透了！

另外還有一個不好的地方：規(guī)定的區(qū)間是非負(fù)數(shù)，String的hashCode()方法卻會產(chǎn)生負(fù)數(shù)（不信用"192.168.1.0:1111"試試看就知道了）。不過這個問題好解決，取絕對值就是一種解決的辦法。

綜上，String重寫的hashCode()方法在一致性Hash算法中沒有任何實用價值，得找個算法重新計算HashCode。這種重新計算Hash值的算法有很多，比如CRC32_HASH、FNV1_32_HASH、KETAMA_HASH等，其中KETAMA_HASH是默認(rèn)的MemCache推薦的一致性Hash算法，用別的Hash算法也可以，比如FNV1_32_HASH算法的計算效率就會高一些。

?

一致性Hash算法實現(xiàn)版本1：不帶虛擬節(jié)點

使用一致性Hash算法，盡管增強(qiáng)了系統(tǒng)的伸縮性，但是也有可能導(dǎo)致負(fù)載分布不均勻，解決辦法就是使用虛擬節(jié)點代替真實節(jié)點，第一個代碼版本，先來個簡單的，不帶虛擬節(jié)點。

下面來看一下不帶虛擬節(jié)點的一致性Hash算法的Java代碼實現(xiàn)：

1 /** 2 * 不帶虛擬節(jié)點的一致性Hash算法 3 * @author 五月的倉頡http://www.cnblogs.com/xrq730/ 4 * 5 */ 6 public class ConsistentHashingWithoutVirtualNode 7 { 8 /** 9 * 待添加入Hash環(huán)的服務(wù)器列表 10 */ 11 private static String[] servers = {"192.168.0.0:111", "192.168.0.1:111", "192.168.0.2:111", 12 "192.168.0.3:111", "192.168.0.4:111"}; 13 14 /** 15 * key表示服務(wù)器的hash值，value表示服務(wù)器的名稱 16 */ 17 private static SortedMap<Integer, String> sortedMap = 18 new TreeMap<Integer, String>(); 19 20 /** 21 * 程序初始化，將所有的服務(wù)器放入sortedMap中 22 */ 23 static 24 { 25 for (int i = 0; i < servers.length; i++) 26 { 27 int hash = getHash(servers[i]); 28 System.out.println("[" + servers[i] + "]加入集合中, 其Hash值為" + hash); 29 sortedMap.put(hash, servers[i]); 30 } 31 System.out.println(); 32 } 33 34 /** 35 * 使用FNV1_32_HASH算法計算服務(wù)器的Hash值,這里不使用重寫hashCode的方法，最終效果沒區(qū)別 36 */ 37 private static int getHash(String str) 38 { 39 final int p = 16777619; 40 int hash = (int)2166136261L; 41 for (int i = 0; i < str.length(); i++) 42 hash = (hash ^ str.charAt(i)) * p; 43 hash += hash << 13; 44 hash ^= hash >> 7; 45 hash += hash << 3; 46 hash ^= hash >> 17; 47 hash += hash << 5; 48 49 // 如果算出來的值為負(fù)數(shù)則取其絕對值 50 if (hash < 0) 51 hash = Math.abs(hash); 52 return hash; 53 } 54 55 /** 56 * 得到應(yīng)當(dāng)路由到的結(jié)點 57 */ 58 private static String getServer(String node) 59 { 60 // 得到帶路由的結(jié)點的Hash值 61 int hash = getHash(node); 62 // 得到大于該Hash值的所有Map 63 SortedMap<Integer, String> subMap = 64 sortedMap.tailMap(hash); 65 // 第一個Key就是順時針過去離node最近的那個結(jié)點 66 Integer i = subMap.firstKey(); 67 // 返回對應(yīng)的服務(wù)器名稱 68 return subMap.get(i); 69 } 70 71 public static void main(String[] args) 72 { 73 String[] nodes = {"127.0.0.1:1111", "221.226.0.1:2222", "10.211.0.1:3333"}; 74 for (int i = 0; i < nodes.length; i++) 75 System.out.println("[" + nodes[i] + "]的hash值為" + 76 getHash(nodes[i]) + ", 被路由到結(jié)點[" + getServer(nodes[i]) + "]"); 77 } 78 }

可以運(yùn)行一下看一下結(jié)果：

[192.168.0.0:111]加入集合中, 其Hash值為575774686 [192.168.0.1:111]加入集合中, 其Hash值為8518713 [192.168.0.2:111]加入集合中, 其Hash值為1361847097 [192.168.0.3:111]加入集合中, 其Hash值為1171828661 [192.168.0.4:111]加入集合中, 其Hash值為1764547046[127.0.0.1:1111]的hash值為380278925, 被路由到結(jié)點[192.168.0.0:111] [221.226.0.1:2222]的hash值為1493545632, 被路由到結(jié)點[192.168.0.4:111] [10.211.0.1:3333]的hash值為1393836017, 被路由到結(jié)點[192.168.0.4:111]

看到經(jīng)過FNV1_32_HASH算法重新計算過后的Hash值，就比原來String的hashCode()方法好多了。從運(yùn)行結(jié)果來看，也沒有問題，三個點路由到的都是順時針離他們Hash值最近的那臺服務(wù)器上。

?

使用虛擬節(jié)點來改善一致性Hash算法

上面的一致性Hash算法實現(xiàn)，可以在很大程度上解決很多分布式環(huán)境下不好的路由算法導(dǎo)致系統(tǒng)伸縮性差的問題，但是會帶來另外一個問題：負(fù)載不均。

比如說有Hash環(huán)上有A、B、C三個服務(wù)器節(jié)點，分別有100個請求會被路由到相應(yīng)服務(wù)器上。現(xiàn)在在A與B之間增加了一個節(jié)點D，這導(dǎo)致了原來會路由到B上的部分節(jié)點被路由到了D上，這樣A、C上被路由到的請求明顯多于B、D上的，原來三個服務(wù)器節(jié)點上均衡的負(fù)載被打破了。某種程度上來說，這失去了負(fù)載均衡的意義，因為負(fù)載均衡的目的本身就是為了使得目標(biāo)服務(wù)器均分所有的請求。

解決這個問題的辦法是引入虛擬節(jié)點，其工作原理是：將一個物理節(jié)點拆分為多個虛擬節(jié)點，并且同一個物理節(jié)點的虛擬節(jié)點盡量均勻分布在Hash環(huán)上。采取這樣的方式，就可以有效地解決增加或減少節(jié)點時候的負(fù)載不均衡的問題。

至于一個物理節(jié)點應(yīng)該拆分為多少虛擬節(jié)點，下面可以先看一張圖：

橫軸表示需要為每臺福利服務(wù)器擴(kuò)展的虛擬節(jié)點倍數(shù)，縱軸表示的是實際物理服務(wù)器數(shù)。可以看出，物理服務(wù)器很少，需要更大的虛擬節(jié)點；反之物理服務(wù)器比較多，虛擬節(jié)點就可以少一些。比如有10臺物理服務(wù)器，那么差不多需要為每臺服務(wù)器增加100~200個虛擬節(jié)點才可以達(dá)到真正的負(fù)載均衡。

?

一致性Hash算法實現(xiàn)版本2：帶虛擬節(jié)點

在理解了使用虛擬節(jié)點來改善一致性Hash算法的理論基礎(chǔ)之后，就可以嘗試開發(fā)代碼了。編程方面需要考慮的問題是：

1、一個真實結(jié)點如何對應(yīng)成為多個虛擬節(jié)點？

2、虛擬節(jié)點找到后如何還原為真實結(jié)點？

這兩個問題其實有很多解決辦法，我這里使用了一種簡單的辦法，給每個真實結(jié)點后面根據(jù)虛擬節(jié)點加上后綴再取Hash值，比如"192.168.0.0:111"就把它變成"192.168.0.0:111&&VN0"到"192.168.0.0:111&&VN4"，VN就是Virtual Node的縮寫，還原的時候只需要從頭截取字符串到"&&"的位置就可以了。

下面來看一下帶虛擬節(jié)點的一致性Hash算法的Java代碼實現(xiàn)：

1 /** 2 * 帶虛擬節(jié)點的一致性Hash算法 3 * @author 五月的倉頡 http://www.cnblogs.com/xrq730/ 4 */ 5 public class ConsistentHashingWithVirtualNode 6 { 7 /** 8 * 待添加入Hash環(huán)的服務(wù)器列表 9 */ 10 private static String[] servers = {"192.168.0.0:111", "192.168.0.1:111", "192.168.0.2:111", 11 "192.168.0.3:111", "192.168.0.4:111"}; 12 13 /** 14 * 真實結(jié)點列表,考慮到服務(wù)器上線、下線的場景，即添加、刪除的場景會比較頻繁，這里使用LinkedList會更好 15 */ 16 private static List<String> realNodes = new LinkedList<String>(); 17 18 /** 19 * 虛擬節(jié)點，key表示虛擬節(jié)點的hash值，value表示虛擬節(jié)點的名稱 20 */ 21 private static SortedMap<Integer, String> virtualNodes = 22 new TreeMap<Integer, String>(); 23 24 /** 25 * 虛擬節(jié)點的數(shù)目，這里寫死，為了演示需要，一個真實結(jié)點對應(yīng)5個虛擬節(jié)點 26 */ 27 private static final int VIRTUAL_NODES = 5; 28 29 static 30 { 31 // 先把原始的服務(wù)器添加到真實結(jié)點列表中 32 for (int i = 0; i < servers.length; i++) 33 realNodes.add(servers[i]); 34 35 // 再添加虛擬節(jié)點，遍歷LinkedList使用foreach循環(huán)效率會比較高 36 for (String str : realNodes) 37 { 38 for (int i = 0; i < VIRTUAL_NODES; i++) 39 { 40 String virtualNodeName = str + "&&VN" + String.valueOf(i); 41 int hash = getHash(virtualNodeName); 42 System.out.println("虛擬節(jié)點[" + virtualNodeName + "]被添加, hash值為" + hash); 43 virtualNodes.put(hash, virtualNodeName); 44 } 45 } 46 System.out.println(); 47 } 48 49 /** 50 * 使用FNV1_32_HASH算法計算服務(wù)器的Hash值,這里不使用重寫hashCode的方法，最終效果沒區(qū)別 51 */ 52 private static int getHash(String str) 53 { 54 final int p = 16777619; 55 int hash = (int)2166136261L; 56 for (int i = 0; i < str.length(); i++) 57 hash = (hash ^ str.charAt(i)) * p; 58 hash += hash << 13; 59 hash ^= hash >> 7; 60 hash += hash << 3; 61 hash ^= hash >> 17; 62 hash += hash << 5; 63 64 // 如果算出來的值為負(fù)數(shù)則取其絕對值 65 if (hash < 0) 66 hash = Math.abs(hash); 67 return hash; 68 } 69 70 /** 71 * 得到應(yīng)當(dāng)路由到的結(jié)點 72 */ 73 private static String getServer(String node) 74 { 75 // 得到帶路由的結(jié)點的Hash值 76 int hash = getHash(node); 77 // 得到大于該Hash值的所有Map 78 SortedMap<Integer, String> subMap = 79 virtualNodes.tailMap(hash); 80 // 第一個Key就是順時針過去離node最近的那個結(jié)點 81 Integer i = subMap.firstKey(); 82 // 返回對應(yīng)的虛擬節(jié)點名稱，這里字符串稍微截取一下 83 String virtualNode = subMap.get(i); 84 return virtualNode.substring(0, virtualNode.indexOf("&&")); 85 } 86 87 public static void main(String[] args) 88 { 89 String[] nodes = {"127.0.0.1:1111", "221.226.0.1:2222", "10.211.0.1:3333"}; 90 for (int i = 0; i < nodes.length; i++) 91 System.out.println("[" + nodes[i] + "]的hash值為" + 92 getHash(nodes[i]) + ", 被路由到結(jié)點[" + getServer(nodes[i]) + "]"); 93 } 94 }

關(guān)注一下運(yùn)行結(jié)果：

虛擬節(jié)點[192.168.0.0:111&&VN0]被添加, hash值為1686427075 虛擬節(jié)點[192.168.0.0:111&&VN1]被添加, hash值為354859081 虛擬節(jié)點[192.168.0.0:111&&VN2]被添加, hash值為1306497370 虛擬節(jié)點[192.168.0.0:111&&VN3]被添加, hash值為817889914 虛擬節(jié)點[192.168.0.0:111&&VN4]被添加, hash值為396663629 虛擬節(jié)點[192.168.0.1:111&&VN0]被添加, hash值為1032739288 虛擬節(jié)點[192.168.0.1:111&&VN1]被添加, hash值為707592309 虛擬節(jié)點[192.168.0.1:111&&VN2]被添加, hash值為302114528 虛擬節(jié)點[192.168.0.1:111&&VN3]被添加, hash值為36526861 虛擬節(jié)點[192.168.0.1:111&&VN4]被添加, hash值為848442551 虛擬節(jié)點[192.168.0.2:111&&VN0]被添加, hash值為1452694222 虛擬節(jié)點[192.168.0.2:111&&VN1]被添加, hash值為2023612840 虛擬節(jié)點[192.168.0.2:111&&VN2]被添加, hash值為697907480 虛擬節(jié)點[192.168.0.2:111&&VN3]被添加, hash值為790847074 虛擬節(jié)點[192.168.0.2:111&&VN4]被添加, hash值為2010506136 虛擬節(jié)點[192.168.0.3:111&&VN0]被添加, hash值為891084251 虛擬節(jié)點[192.168.0.3:111&&VN1]被添加, hash值為1725031739 虛擬節(jié)點[192.168.0.3:111&&VN2]被添加, hash值為1127720370 虛擬節(jié)點[192.168.0.3:111&&VN3]被添加, hash值為676720500 虛擬節(jié)點[192.168.0.3:111&&VN4]被添加, hash值為2050578780 虛擬節(jié)點[192.168.0.4:111&&VN0]被添加, hash值為586921010 虛擬節(jié)點[192.168.0.4:111&&VN1]被添加, hash值為184078390 虛擬節(jié)點[192.168.0.4:111&&VN2]被添加, hash值為1331645117 虛擬節(jié)點[192.168.0.4:111&&VN3]被添加, hash值為918790803 虛擬節(jié)點[192.168.0.4:111&&VN4]被添加, hash值為1232193678[127.0.0.1:1111]的hash值為380278925, 被路由到結(jié)點[192.168.0.0:111] [221.226.0.1:2222]的hash值為1493545632, 被路由到結(jié)點[192.168.0.0:111] [10.211.0.1:3333]的hash值為1393836017, 被路由到結(jié)點[192.168.0.2:111]

從代碼運(yùn)行結(jié)果看，每個點路由到的服務(wù)器都是Hash值順時針離它最近的那個服務(wù)器節(jié)點，沒有任何問題。

通過采取虛擬節(jié)點的方法，一個真實結(jié)點不再固定在Hash換上的某個點，而是大量地分布在整個Hash環(huán)上，這樣即使上線、下線服務(wù)器，也不會造成整體的負(fù)載不均衡。

?

后記

在寫本文的時候，很多知識我也是邊寫邊學(xué)，難免有很多寫得不好、理解得不透徹的地方，而且代碼整體也比較糙，未有考慮到可能的各種情況。拋磚引玉，一方面，寫得不對的地方，還望網(wǎng)友朋友們指正；另一方面，后續(xù)我也將通過自己的工作、學(xué)習(xí)不斷完善上面的代碼。

from:?http://www.cnblogs.com/xrq730/p/5186728.html

總結(jié)

以上是生活随笔為你收集整理的对一致性Hash算法，Java代码实现的深入研究的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。