一致性雜湊演算法

標籤：style   blog   http   color   使用   資料   

時間：2014.07.17

地點：基地二樓

----------------------------------------------------------------------------------------

一、為什麼我們需要一致性雜湊演算法考慮一個情境：伺服器負載平衡問題。有n台伺服器，比如n台cache，cache編號的選擇和object的
匹配應該採取什麼用的策略才能滿足保證功能的需求。如果我們採取如下簡單的雜湊映射關係：
hash(object) mod n

看起來這樣一個系統工作正常，但考慮周到會有如下幾個問題：
問題1：有一天我們需要增加一台伺服器，這時我們需要改變雜湊映射關係為：
hash(object) mod (n+1)
問題2：有一天我們需要刪除一台伺服器，這時我們需要改變雜湊映射關係為：
hash(object) mod (n-1)

問題3：怎麼樣使得伺服器負載分配均勻

現在我們看到麻煩來了，由於hash關係的變化，幾乎所有的object將會被hash到新的位置，即映射到新的伺服器，這是一種災難，於是我們就需要一致性雜湊來改善這種情況了。

----------------------------------------------------------------------------------------

二、一致性雜湊  一致性雜湊可以保證當任意一台伺服器增加到系統或從系統中刪除時，僅僅只有相關的有限個object需要重新匹配，即一致性雜湊最大程度地防止object與伺服器之前的匹配關係。

----------------------------------------------------------------------------------------

三、雜湊空間(hash space)    一般地，雜湊函數將object映射到一個位的值上，雜湊值取值範圍為[0~2^32-1]，如所示，我們把雜湊值域首尾相接聯合成一個環形，於是也稱呼為環形雜湊空間。

                                                                   

                                                                    雜湊空間

----------------------------------------------------------------------------------------

四、將object映射到雜湊空間假設有4個object，分別為object1~object4，現在我們使用雜湊函數獲得他們各自的key值，並映射到環形雜湊空間中去，如所示：
hash(object1)=key1;
hash(object2)=key2;
hash(object3)=key3;
hash(object4)=key4;

                                      
                                                  

                                                  將object映射到雜湊空間

----------------------------------------------------------------------------------------

五、將cache映射到雜湊空間我們採用同樣的雜湊函數，繼續還將伺服器也映射到該環形雜湊空間中，
假設我們有3台伺服器A,B,C,雜湊之後如下：
hash(cacheA)=keyA;
hash(cacheB)=keyB;
hash(cacheC)=keyC;

                                          

                                           將cache以同樣的方式也映射到雜湊空間

                                                                         

----------------------------------------------------------------------------------------

六、將object與cache匹配  經過之前的步驟，現在object和cache都已經成功映射到環形雜湊空間去了。接下來，我們將決定objects怎麼和cache形成映射：我們採取的策略是，將object按順時針方向走，直到找到第一個cache,若果該cache是可用的，即形成object和cache匹配，否則繼續尋找下一個cache。根據上述原則，在這裡我們得到的匹配結果是：
    object1——>cacheA
    object2——>cacheC
    object3——>cacheC
    object4——>cacheB

----------------------------------------------------------------------------------------

七、增加或刪減cache  現在考慮兩種情境：1.當某一cache崩潰移除系統 ，由於object4是映射在cacheB上的，現在cacheB將被移除了，那麼現在object4得重現更新這個映射，我們只需要簡單的沿順時針方向找到下一個可用的cache,在這裡是cacheC即可，，而不必所以映射關係全盤改動。

                           

                                              cacheB崩潰

當將cacheD加入在object2和object3之間時，B和D之間的object也需重新對應，在這裡object2將綁定到新加入的cacheD上。如：

                                  

                                                     增加cacheD

----------------------------------------------------------------------------------------

八、虛節點    上述情況能夠很好的解決增加刪除伺服器節點時對整個系統大動幹戈的問題。但還存在一個問題，那就是如果環形雜湊空間上的cache較少的話，object的部署不會那麼均勻。於是我們引入虛節點的概念。 ，它能夠比較好的改善這一缺點。 虛節點是環形雜湊空間上哥cache點的副本，每個cache關聯著幾個環形上的虛節點，當我們增加一個節點時，這意味著我們實際上在環形空間上增加了幾個這樣的虛節點，同樣刪除某一cache時，我們也將移除環形空間上
所有和它相關的虛節點。繼續考慮上面的例子，現在系統中有cachA和cacheC，引入虛節點，並假設各存在2份，於是在環形空間上，一起有4個虛節點。cacheA1和cacheA2代表cacheA，還有cacheC1和cacheC2代表C，如：於是，現在從object到虛節點的映射為：
     object1——>cacheA2;
     object2——>cacheA1;
     object3——>cacheC1;
     object4——>cacheC2
這樣分配就會顯得相對均勻。如：

     

九、一致性雜湊演算法的應用  最後來個實際應用的例子。

問題描述： 例如手機朋友網有n個伺服器，為了方便使用者的訪問會在伺服器上快取資料，因此使用者每次訪問的時候最好能保持同一台伺服器。

已有的做法是根據ServerIPIndex[QQNUM%n]得到請求的伺服器，這種方法很方便將使用者分到不同的伺服器上去。但是如果一台伺服器死掉了，那麼n就變為了n-1，那麼ServerIPIndex[QQNUM%n]與ServerIPIndex[QQNUM%（n-1）]基本上都不一樣了，所以大多數使用者的請求都會轉到其他伺服器，這樣會發生大量訪問錯誤。
問： 如何改進或者換一種方法，使得：
（1）一台伺服器死掉後，不會造成大面積的訪問錯誤，
（2）原有的訪問基本還是停留在同一台伺服器上；
（3）盡量考慮負載平衡。
顯然，傳統的辦法題目已經給出，即用模餘方法：做法很簡單，但存在很多問題不滿足需求。於是我們考慮一致性雜湊演算法。正如前面所述。
其它應用情境：
    在做伺服器負載平衡時候可供選擇的負載平衡的演算法有很多，包括：  輪循演算法（Round Robin）、雜湊演算法（HASH）、最少串連演算法（Least Connection）、響應速度演算法（Response Time）、加權法（Weighted ）等。其中雜湊演算法是最為常用的演算法.
    最典型的應用情境就是： 有N台伺服器提供快取服務，需要對伺服器進行負載平衡，將請求平均分發到每台伺服器上，每台機器負責1/N的服務。
    常用的演算法是對hash結果取餘數 (hash() mod N)：對機器編號從0到N-1，按照自訂的hash()演算法，對每個請求的hash()值按N模數，得到餘數i，然後將請求分發到編號為i的機器。但這樣的演算法方法存在致命問題，如果某一台機器宕機，那麼應該落在該機器的請求就無法得到正確的處理，這時需要將當掉的伺服器從演算法從去除，此時候會有(N-1)/N的伺服器的快取資料需要重新進行計算；如果新增一台機器，會有N /(N+1)的伺服器的快取資料需要進行重新計算。對於系統而言，這通常是不可接受的顛簸（因為這意味著大量緩衝的失效或者資料需要轉移）。那麼，如何設計一個負載平衡策略，使得受到影響的請求儘可能的少呢？
    在Memcached、Key-Value Store、Bittorrent DHT、LVS中都採用了Consistent Hashing演算法，可以說Consistent Hashing 是分布式系統負載平衡的首選演算法。