Rendezvous hashing算法介紹

Rendezvous hashing

Rendezvous hashing用於解決分佈式系統中的分佈式哈希問題,該問題包括三部分:

  1. Keys:數據或負載的唯一標識
  2. Values:消耗資源的數據或負載
  3. Servers:管理數據或負載的實體
image

例如,在一個分佈式系統中,key可能是一個文件名,value是文件數據,servers是連接網絡的數據服務器,用於保存所有文件。假設給定一組動態服務器,下面需要將keys映射到服務器,並提供如下功能:

  1. Load Balancing: 每個服務器負責(近乎)同等數量的負載
  2. Scalability: 添加或刪除服務器時不會造成大量計算
  3. Lookup Speed: 給定一個key,可以快速確定所需的服務器

動態服務器是指在系統運行的任意時間都可能會添加或刪除服務器。

Rendezvous Hashing算法

Rendezvous Hashing算法的歷史可以參見原文

rendezvous hashing算法的目的是獲得更好的負載均衡性能。我們希望每個服務器都能負責同等數量的key-value。一種合理的方式是和普通的哈希表一樣,讓每個key都隨機均勻地選擇一個服務器。這樣做的原因是,如果只是對服務器ID進行哈希,那麼當修改服務器的數量時,所有的哈希值都會發生變化。當對目標服務器的選擇和服務器的數量沒有直接關係時,就可以避免服務器的增刪帶來的影響。

image

Rendezvous hashing提供了一種聰明的解決方式。相比於選擇一個特定的服務器,它會爲每個key生成一個隨機有序的服務器列表,並選擇列表中的第一個作爲目標服務器。爲了保證查找成功,我們需要保證每個key-value對都由key選擇的第一臺服務器保管。

如果選擇的第一臺服務器下線時,只需要將key轉移到列表中的第二臺服務器即可(作爲新的第一臺服務器)。可以看出,這種情況下只需要轉移下線的服務器上的keys即可,無需變動其他服務器的keys。如下面例子,當刪除S2服務器時,S2中的數據會轉移到新的第一臺服務器:即S1和S3,其他服務器的數據無需變動(S2不是它們的第一臺服務器)。

image

哈希技巧

從上面例子可以看出,使用rendezvous hashing時,需要確保每個key都能有其特定的服務器優先列表,這樣才能保證數據分佈均勻。那如何爲每個key生成隨機排列的服務器列表呢?

可以使用常見的哈希技術來解決該問題。首先,對每個服務器進行哈希來生成一組整數哈希值,然後基於該哈希值對服務器進行排序,這樣就得到了一個隨機排列的服務器列表。爲了保證每個key都能得到唯一的排列,需要在哈希函數中引入key。方式是將key和各個服務器(或服務器ID)作爲哈希種子來生成哈希值。

image

最終的rendezvous hashing算法爲:

  1. 使用隨機哈希函數來計算所有key-server的哈希值
  2. 將key分配給具有最大哈希值的服務器
  3. 當添加和移除服務器時維護"第一臺服務器"

Rendezvous Hashing的優勢

級聯故障轉移:當一臺服務器故障後,很多負載均衡算法會將所有負載轉移到某一臺服務器上,如果該故障轉移的服務器無法處理新的負載,就會導致級聯故障。在Rendezvous Hashing中,由於每個key都有不同的第二選擇服務器,因此Rendezvous hashing可以避免該問題。使用好的哈希函數可以將負載從故障服務器均勻分佈到剩餘的服務器上。

基於權重的服務器:在一些場景下,我們期望基於負載均衡而非均勻隨機key來分配負載。例如,需要給具有較大容量的服務器分配更多的負載。相比基於哈希值的排序,我們可以選擇基於 $$ {w_i \over ln h_i(x)} $$進行排序,其中x爲key, \(w_i\)爲服務器i的權重, \(h_i(x)\)爲哈希值(通常爲[0,1])。更多細節,參見這裏

更少的內存:由於可以本地計算所有的哈希函數值,因此只需要一組服務器ID列表來對應管理key-value的服務器。在實際使用中,一致性哈希之類的算法要求更多的內存(但計算量也更少)。

Rendezvous Hashing的劣勢

添加服務器:在添加服務器時,由於新的服務器可能會成爲系統中已存在的key的第一選擇,因此很難維護"第一選擇"不變性。爲了維護該不變性,我們需要校驗系統中服務器管理的所有keys,這會給分佈式存儲和pub/sub系統帶來嚴重的問題,但着對緩存系統來說並不是一個問題。在緩存系統中,緩存服務器會共享一箇中央數據存儲庫。當用戶請求緩存系統時,如果緩存不存在,則從中央庫中獲取數據並緩存起來,等待下次使用。
當給緩存添加服務器時,系統會最終達成"第一選擇"不變性。如果添加的服務器成爲一個已存在的key的第一選擇,則只會在第一次請求時會導致緩存miss。在新服務器負責該key之後,老的服務器將不會再接收到該key的請求,老數據最終會通過LRU之類的方式清理掉。

請求時間:如果有N臺服務器,由於需要校驗所有的key-server組合,因此查找算法爲O(N)。而一致性哈希爲O(logN),當N足夠大時,其查詢速度也更快。

總結

Rendezvous hashing適於在中小型分佈式緩存中做分佈式負載均衡。如果一個系統無法滿足"第一選擇"不變性,則需要謹慎選擇rendezvous hashing。

參考

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章