Linux教程網 >> Linux編程 >> Linux編程 >> 對一致性Hash算法，Java代碼實現的深入研究

對一致性Hash算法，Java代碼實現的深入研究

日期：2017/3/1 9:18:06 编辑：Linux編程

一致性Hash算法

關於一致性Hash算法，在我之前的博文中已經有多次提到了，Memcache的詳細講解一文中"一致性Hash算法"部分，對於為什麼要使用一致性Hash算法、一致性Hash算法的算法原理做了詳細的解讀。

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

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

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

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

數據結構的選取

一致性Hash算法最先要考慮的一個問題是：構造出一個長度為2³²的整數環，根據節點名稱的Hash值將服務器節點放置在這個Hash環上。

那麼，整數環應該使用何種數據結構，才能使得運行時的時間復雜度最低？首先說明一點，關於時間復雜度，常見的時間復雜度與時間效率的關系有如下的經驗規則：

O(1) < O(log₂N) < O(n) < O(N * log₂N) < O(N²) < O(N³) < 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值：

/**
 * String的hashCode()方法運算結果查看
 * @author 五月的倉颉 http://www.linuxidc.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以這種連續的形式存在是很正常的。看一下運行結果為：

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]的區間之中，5個HashCode值卻只分布在這麼小小的一個區間，什麼概念？[0,2³²-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代碼實現：

 1 /**
 2  * 不帶虛擬節點的一致性Hash算法
 3  * @author 五月的倉颉http://www.linuxidc.com/xrq730/
 4  *
 5  */
 6 public class ConsistentHashingWithoutVirtualNode
 7 {
 8     /**
 9      * 待添加入Hash環的服務器列表
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表示服務器的hash值，value表示服務器的名稱
16      */
17     private static SortedMap<Integer, String> sortedMap = 
18             new TreeMap<Integer, String>();
19     
20     /**
21      * 程序初始化，將所有的服務器放入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算法計算服務器的Hash值,這裡不使用重寫hashCode的方法，最終效果沒區別 
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         // 如果算出來的值為負數則取其絕對值
50         if (hash < 0)
51             hash = Math.abs(hash);
52         return hash;
53     }
54     
55     /**
56      * 得到應當路由到的結點
57      */
58     private static String getServer(String node)
59     {
60         // 得到帶路由的結點的Hash值
61         int hash = getHash(node);
62         // 得到大於該Hash值的所有Map
63         SortedMap<Integer, String> subMap = 
64                 sortedMap.tailMap(hash);
65         // 第一個Key就是順時針過去離node最近的那個結點
66         Integer i = subMap.firstKey();
67         // 返回對應的服務器名稱
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]) + ", 被路由到結點[" + getServer(nodes[i]) + "]");
77     }
78 }

可以運行一下看一下結果：

[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值最近的那台服務器上。

更多詳情見請繼續閱讀下一頁的精彩內容： http://www.linuxidc.com/Linux/2016-03/129172p2.htm