一致性Hash演算法的深入理解
總結：
1、使用一致性Hash演算法，儘管增強了系統的伸縮性，但是也有可能導致負載分佈不均勻，解決辦法就是使用虛擬節點代替真實節點，
2、Hash演算法的選擇上，首先我們考慮簡單的String.HashCode()方法，這個演算法的缺點是，相似的字串如N1(10.0.0.0:91001)，N2(10.0.0.0:91002)，N3(10.0.0.0:91003)，雜湊值也很相近，造成的結果是節點在Hash環上分佈很緊密，導致大部分Key值落到了N0上，節點資源分佈不均。一般我們採用FNV1_32_HASH、KETAMA_HASH等演算法，KETAMA_HASH是MemCache叢集預設的實現方法，這些演算法效果要好得多，會使N0，N1，N2的Hash值更均勻的分佈在環上。
關於一致性Hash演算法，在我之前的博文中已經有多次提到了，MemCache超詳細解讀一文中”一致性Hash演算法”部分，對於為什麼要使用一致性Hash演算法、一致性Hash演算法的演算法原理做了詳細的解讀。
演算法的具體原理這裡再次貼上：
先構造一個長度為232的整數環（這個環被稱為一致性Hash環），根據節點名稱的Hash值（其分佈為[0, 232-1]）將伺服器節點放置在這個Hash環上，然後根據資料的Key值計算得到其Hash值（其分佈也為[0, 232-1]），接著在Hash環上順時針查詢距離這個Key值的Hash值最近的伺服器節點，完成Key到伺服器的對映查詢。
這種演算法解決了普通餘數Hash演算法伸縮性差的問題，可以保證在上線、下線伺服器的情況下儘量有多的請求命中原來路由到的伺服器。
當然，萬事不可能十全十美，一致性Hash演算法比普通的餘數Hash演算法更具有伸縮性，但是同時其演算法實現也更為複雜，本文就來研究一下，如何利用Java程式碼實現一致性Hash演算法。在開始之前，先對一致性Hash演算法中的幾個核心問題進行一些探究。
資料結構的選取
一致性Hash演算法最先要考慮的一個問題是：構造出一個長度為232的整數環，根據節點名稱的Hash值將伺服器節點放置在這個Hash環上。
那麼，整數環應該使用何種資料結構，才能使得執行時的時間複雜度最低？首先說明一點，關於時間複雜度，常見的時間複雜度與時間效率的關係有如下的經驗規則：
O(1) < O(log2N) < O(n) < O(N * log2N) < O(N2) < O(N3) < 2N < 3N < N!
一般來說，前四個效率比較高，中間兩個差強人意，後三個比較差（只要N比較大，這個演算法就動不了了）。OK，繼續前面的話題，應該如何選取資料結構，我認為有以下幾種可行的解決方案。
1、解決方案一：排序+List
我想到的第一種思路是：算出所有待加入資料結構的節點名稱的Hash值放入一個數組中，然後使用某種排序演算法將其從小到大進行排序，最後將排序後的資料放入List中，採用List而不是陣列是為了結點的擴充套件考慮。
之後，待路由的結點，只需要在List中找到第一個Hash值比它大的伺服器節點就可以了，比如伺服器節點的Hash值是[0,2,4,6,8,10]，帶路由的結點是7，只需要找到第一個比7大的整數，也就是8，就是我們最終需要路由過去的伺服器節點。
如果暫時不考慮前面的排序，那麼這種解決方案的時間複雜度：
（1）最好的情況是第一次就找到，時間複雜度為O(1)
（2）最壞的情況是最後一次才找到，時間複雜度為O(N)
平均下來時間複雜度為O(0.5N+0.5)，忽略首項係數和常數，時間複雜度為O(N)。
但是如果考慮到之前的排序，我在網上找了張圖，提供了各種排序演算法的時間複雜度：
看得出來，排序演算法要麼穩定但是時間複雜度高、要麼時間複雜度低但不穩定，看起來最好的歸併排序法的時間複雜度仍然有O(N * logN)，稍微耗費效能了一些。
2、解決方案二：遍歷+List
既然排序操作比較耗效能，那麼能不能不排序？可以的，所以進一步的，有了第二種解決方案。
解決方案使用List不變，不過可以採用遍歷的方式：
（1）伺服器節點不排序，其Hash值全部直接放入一個List中
（2）帶路由的節點，算出其Hash值，由於指明瞭”順時針”，因此遍歷List，比待路由的節點Hash值大的算出差值並記錄，比待路由節點Hash值小的忽略
（3）算出所有的差值之後，最小的那個，就是最終需要路由過去的節點
在這個演算法中，看一下時間複雜度：
1、最好情況是隻有一個伺服器節點的Hash值大於帶路由結點的Hash值，其時間複雜度是O(N)+O(1)=O(N+1)，忽略常數項，即O(N)
2、最壞情況是所有伺服器節點的Hash值都大於帶路由結點的Hash值，其時間複雜度是O(N)+O(N)=O(2N)，忽略首項係數，即O(N)
所以，總的時間複雜度就是O(N)。其實演算法還能更改進一些：給一個位置變數X，如果新的差值比原差值小，X替換為新的位置，否則X不變。這樣遍歷就減少了一輪，不過經過改進後的演算法時間複雜度仍為O(N)。
總而言之，這個解決方案和解決方案一相比，總體來看，似乎更好了一些。
3、解決方案三：二叉查詢樹
拋開List這種資料結構，另一種資料結構則是使用二叉查詢樹。
當然我們不能簡單地使用二叉查詢樹，因為可能出現不平衡的情況。平衡二叉查詢樹有AVL樹、紅黑樹等，這裡使用紅黑樹，選用紅黑樹的原因有兩點：
1、紅黑樹主要的作用是用於儲存有序的資料，這其實和第一種解決方案的思路又不謀而合了，但是它的效率非常高
2、JDK裡面提供了紅黑樹的程式碼實現TreeMap和TreeSet
另外，以TreeMap為例，TreeMap本身提供了一個tailMap(K fromKey)方法，支援從紅黑樹中查詢比fromKey大的值的集合，但並不需要遍歷整個資料結構。
使用紅黑樹，可以使得查詢的時間複雜度降低為O(logN)，比上面兩種解決方案，效率大大提升。
為了驗證這個說法，我做了一次測試，從大量資料中查詢第一個大於其中間值的那個資料，比如10000資料就找第一個大於5000的資料（模擬平均的情況）。看一下O(N)時間複雜度和O(logN)時間複雜度執行效率的對比：
| 50000 | 100000 | 500000 | 1000000 | 4000000 | |
| ArrayList | 1ms | 1ms | 4ms | 4ms | 5ms |
| LinkedList | 4ms | 7ms | 11ms | 13ms | 17ms |
| TreeMap | 0ms | 0ms | 0ms | 0ms | 0ms |
因為再大就記憶體溢位了，所以只測試到4000000資料。可以看到，資料查詢的效率，TreeMap是完勝的，其實再增大資料測試也是一樣的，紅黑樹的資料結構決定了任何一個大於N的最小資料，它都只需要幾次至幾十次查詢就可以查到。
當然，明確一點，有利必有弊，根據我另外一次測試得到的結論是，為了維護紅黑樹，資料插入效率TreeMap在三種資料結構裡面是最差的，且插入要慢上5~10倍。
Hash值重新計算
伺服器節點我們肯定用字串來表示，比如”192.168.1.1″、”192.168.1.2″，根據字串得到其Hash值，那麼另外一個重要的問題就是Hash值要重新計算，這個問題是我在測試String的hashCode()方法的時候發現的，不妨來看一下為什麼要重新計算Hash值：
XHTML
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
/** * String的hashCode()方法運算結果檢視 * @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以這種連續的形式存在是很正常的。看一下執行結果為：
XHTML
| 1 2 3 4 5 |
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,232-1]的區間之中，5個HashCode值卻只分布在這麼小小的一個區間，什麼概念？[0,232-1]中有4294967296個數字，而我們的區間只有122516605，從概率學上講這將導致97%待路由的伺服器都被路由到”192.168.0.1″這個叢集點上，簡直是糟糕透了！
另外還有一個不好的地方：規定的區間是非負數，String的hashCode()方法卻會產生負數（不信用”192.168.1.0:1111″試試看就知道了）。不過這個問題好解決，取絕對值就是一種解決的辦法。
綜上，String重寫的hashCode()方法在一致性Hash演算法中沒有任何實用價值，得找個演算法重新計算HashCode。這種重新計算Hash值的演算法有很多，比如CRC32_HASH、FNV1_32_HASH、KETAMA_HASH等，其中KETAMA_HASH是預設的MemCache推薦的一致性Hash演算法，用別的Hash演算法也可以，比如FNV1_32_HASH演算法的計算效率就會高一些。
一致性Hash演算法實現版本1：不帶虛擬節點
使用一致性Hash演算法，儘管增強了系統的伸縮性，但是也有可能導致負載分佈不均勻，解決辦法就是使用虛擬節點代替真實節點，第一個程式碼版本，先來個簡單的，不帶虛擬節點。
下面來看一下不帶虛擬節點的一致性Hash演算法的Java程式碼實現：
XHTML
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 |
/** * 不帶虛擬節點的一致性Hash演算法 * @author 五月的倉頡http://www.cnblogs.com/xrq730/ * */ public class ConsistentHashingWithoutVirtualNode { /** * 待新增入Hash環的伺服器列表 */ private static String[] servers = {"192.168.0.0:111", "192.168.0.1:111", "192.168.0.2:111", "192.168.0.3:111", "192.168.0.4:111"};
/** * key表示伺服器的hash值，value表示伺服器的名稱 */ private static SortedMap sortedMap = new TreeMap();
/** * 程式初始化，將所有的伺服器放入sortedMap中 */ static { for (int i = 0; i ) { int hash = getHash(servers[i]); System.out.println("[" + servers[i] + "]加入集合中, 其Hash值為" + hash); sortedMap.put(hash, servers[i]); } System.out.println(); }
/** * 使用FNV1_32_HASH演算法計算伺服器的Hash值,這裡不使用重寫hashCode的方法，最終效果沒區別 */ private static int getHash(String str) { final int p = 16777619; int hash = (int)2166136261L; for (int i = 0; i ) hash = (hash ^ str.charAt(i)) * p; hash += hash ; hash ^= hash >> 7; hash += hash ; hash ^= hash >> 17; hash += hash ;
// 如果算出來的值為負數則取其絕對值 if (hash ) hash = Math.abs(hash); return hash; }
/** * 得到應當路由到的結點 */ private static String getServer(String node) { // 得到帶路由的結點的Hash值 int hash = getHash(node); // 得到大於該Hash值的所有Map SortedMap subMap = sortedMap.tailMap(hash); // 第一個Key就是順時針過去離node最近的那個結點 Integer i = subMap.firstKey(); // 返回對應的伺服器名稱 return subMap.get(i); }
public static void main(String[] args) { String[] nodes = {"127.0.0.1:1111", "221.226.0.1:2222", "10.211.0.1:3333"}; for (int i = 0; i ) System.out.println("[" + nodes[i] + "]的hash值為" + getHash(nodes[i]) + ", 被路由到結點[" + getServer(nodes[i]) + "]"); } } |
可以執行一下看一下結果：
XHTML
| 1 2 3 4 5 6 7 |
[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, 被路由到結點[192.168.0.0:111] [221.226.0.1:2222]的hash值為1493545632, 被路由到結點[192.168.0.4:111] [10.211.0.1:3333]的hash值為1393836017, 被路由到結點[192.168.0.4:111] |
看到經過FNV1_32_HASH演算法重新計算過後的Hash值，就比原來String的hashCode()方法好多了。從執行結果來看，也沒有問題，三個點路由到的都是順時針離他們Hash值最近的那臺伺服器上。
使用虛擬節點來改善一致性Hash演算法
上面的一致性Hash演算法實現，可以在很大程度上解決很多分散式環境下不好的路由演算法導致系統伸縮性差的問題，但是會帶來另外一個問題：負載不均。
比如說有Hash環上有A、B、C三個伺服器節點，分別有100個請求會被路由到相應伺服器上。現在在A與B之間增加了一個節點D，這導致了原來會路由到B上的部分節點被路由到了D上，這樣A、C上被路由到的請求明顯多於B、D上的，原來三個伺服器節點上均衡的負載被打破了。某種程度上來說，這失去了負載均衡的意義，因為負載均衡的目的本身就是為了使得目標伺服器均分所有的請求。
解決這個問題的辦法是引入虛擬節點，其工作原理是：將一個物理節點拆分為多個虛擬節點，並且同一個物理節點的虛擬節點儘量均勻分佈在Hash環上。採取這樣的方式，就可以有效地解決增加或減少節點時候的負載不均衡的問題。
至於一個物理節點應該拆分為多少虛擬節點，下面可以先看一張圖：
橫軸表示需要為每臺福利伺服器擴充套件的虛擬節點倍數，縱軸表示的是實際物理伺服器數。可以看出，物理伺服器很少，需要更大的虛擬節點；反之物理伺服器比較多，虛擬節點就可以少一些。比如有10臺物理伺服器，那麼差不多需要為每臺伺服器增加100~200個虛擬節點才可以達到真正的負載均衡。
一致性Hash演算法實現版本2：帶虛擬節點
在理解了使用虛擬節點來改善一致性Hash演算法的理論基礎之後，就可以嘗試開發程式碼了。程式設計方面需要考慮的問題是：
1、一個真實結點如何對應成為多個虛擬節點？
2、虛擬節點找到後如何還原為真實結點？
這兩個問題其實有很多解決辦法，我這裡使用了一種簡單的辦法，給每個真實結點後面根據虛擬節點加上字尾再取Hash值，比如”192.168.0.0:111″就把它變成”192.168.0.0:111&&VN0″到”192.168.0.0:111&&VN4″，VN就是Virtual Node的縮寫，還原的時候只需要從頭擷取字串到”&&”的位置就可以了。
下面來看一下帶虛擬節點的一致性Hash演算法的Java程式碼實現：
XHTML
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 |
/** * 帶虛擬節點的一致性Hash演算法 * @author 五月的倉頡 http://www.cnblogs.com/xrq730/ */ public class ConsistentHashingWithVirtualNode { /** * 待新增入Hash環的伺服器列表 */ private static String[] servers = {"192.168.0.0:111", "192.168.0.1:111", "192.168.0.2:111", "192.168.0.3:111", "192.168.0.4:111"};
/** * 真實結點列表,考慮到伺服器上線、下線的場景，即新增、刪除的場景會比較頻繁，這裡使用LinkedList會更好 */ private static List realNodes = new LinkedList();
/** * 虛擬節點，key表示虛擬節點的hash值，value表示虛擬節點的名稱 */ private static SortedMap virtualNodes = new TreeMap();
/** * 虛擬節點的數目，這裡寫死，為了演示需要，一個真實結點對應5個虛擬節點 */ private static final int VIRTUAL_NODES = 5;
static { // 先把原始的伺服器新增到真實結點列表中 for (int i = 0; i ) realNodes.add(servers[i]);
// 再新增虛擬節點，遍歷LinkedList使用foreach迴圈效率會比較高 for (String str : realNodes) { for (int i = 0; i ) { String virtualNodeName = str + "&VN" + String.valueOf(i); int hash = getHash(virtualNodeName); System.out.println("虛擬節點[" + virtualNodeName + "]被新增, hash值為" + hash); virtualNodes.put(hash, virtualNodeName); } } System.out.println(); }
/** * 使用FNV1_32_HASH演算法計算伺服器的Hash值,這裡不使用重寫hashCode的方法，最終效果沒區別 */ private static int getHash(String str) { final int p = 16777619; int hash = (int)2166136261L; for (int i = 0; i ) hash = (hash ^ str.charAt(i)) * p; hash += hash ; hash ^= hash >> 7; hash += hash ; hash ^= hash >> 17; hash += hash ;
// 如果算出來的值為負數則取其絕對值 if (hash ) hash = Math.abs(hash); return hash; }
/** * 得到應當路由到的結點 */ private static String getServer(String node) { // 得到帶路由的結點的Hash值 int hash = getHash(node); // 得到大於該Hash值的所有Map SortedMap subMap = virtualNodes.tailMap(hash); // 第一個Key就是順時針過去離node最近的那個結點 Integer i = subMap.firstKey(); // 返回對應的虛擬節點名稱，這裡字串稍微擷取一下 String virtualNode = subMap.get(i); return virtualNode.substring(0, virtualNode.indexOf("&")); }
public static void main(String[] args) { String[] nodes = {"127.0.0.1:1111", "221.226.0.1:2222", "10.211.0.1:3333"}; for (int i = 0; i ) System.out.println("[" + nodes[i] + "]的hash值為" + getHash(nodes[i]) + ", 被路由到結點[" + getServer(nodes[i]) + "]"); } } |
關注一下執行結果：
XHTML
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
虛擬節點[192.168.0.0:111&&VN0]被新增, hash值為1686427075 虛擬節點[192.168.0.0:111&&VN1]被新增, hash值為354859081 虛擬節點[192.168.0.0:111&&VN2]被新增, hash值為1306497370 虛擬節點[192.168.0.0:111&&VN3]被新增, hash值為817889914 虛擬節點[192.168.0.0:111&&VN4]被新增, hash值為396663629 虛擬節點[192.168.0.1:111&&VN0]被新增, hash值為1032739288 虛擬節點[192.168.0.1:111&&VN1]被新增, hash值為707592309 虛擬節點[192.168.0.1:111&&VN2]被新增, hash值為302114528 虛擬節點[192.168.0.1:111&&VN3]被新增, hash值為36526861 虛擬節點[192.168.0.1:111&&VN4]被新增, hash值為848442551 虛擬節點[192.168.0.2:111&&VN0]被新增, hash值為1452694222 虛擬節點[192.168.0.2:111&&VN1]被新增, hash值為2023612840 虛擬節點[192.168.0.2:111&&VN2]被新增, hash值為697907480 虛擬節點[192.168.0.2:111&&VN3]被新增, hash值為790847074 虛擬節點[192.168.0.2:111&&VN4]被新增, hash值為2010506136 虛擬節點[192.168.0.3:111&&VN0]被新增, hash值為891084251 虛擬節點[192.168.0.3:111&&VN1]被新增, hash值為1725031739 虛擬節點[192.168.0.3:111&&VN2]被新增, hash值為1127720370 虛擬節點[192.168.0.3:111&&VN3]被新增, hash值為676720500 虛擬節點[192.168.0.3:111&&VN4]被新增, hash值為2050578780 虛擬節點[192.168.0.4:111&&VN0]被新增, hash值為586921010 虛擬節點[192.168.0.4:111&&VN1]被新增, hash值為184078390 虛擬節點[192.168.0.4:111&&VN2]被新增, hash值為1331645117 虛擬節點[192.168.0.4:111&&VN3]被新增, hash值為918790803 虛擬節點[192.168.0.4:111&&VN4]被新增, hash值為1232193678
[127.0.0.1:1111]的hash值為380278925, 被路由到結點[192.168.0.0:111] [221.226.0.1:2222]的hash值為1493545632, 被路由到結點[192.168.0.0:111] [10.211.0.1:3333]的hash值為1393836017, 被路由到結點[192.168.0.2:111] |
從程式碼執行結果看，每個點路由到的伺服器都是Hash值順時針離它最近的那個伺服器節點，沒有任何問題。
通過採取虛擬節點的方法，一個真實結點不再固定在Hash換上的某個點，而是大量地分佈在整個Hash環上，這樣即使上線、下線伺服器，也不會造成整體的負載不均衡。
後記
在寫本文的時候，很多知識我也是邊寫邊學，難免有很多寫得不好、理解得不透徹的地方，而且程式碼整體也比較糙，未有考慮到可能的各種情況。拋磚引玉，一方面，寫得不對的地方，還望網友朋友們指正；另一方面，後續我也將通過自己的工作、學習不斷完善上面的程式碼。
出處：https://blog.csdn.net/u010412301/article/details/52441400