經典的一致哈希算法解決了模塊化哈希算法的問題，其中哈希函數(鍵K的位置)與存儲單元的數量相關，需要在按比例放大和縮小時重新分配所有鍵。

# modular hashinghash = key % N of nodes

另一方面，利用一致哈希，哈希功能與存儲節點的數量無關。這使我們能夠在添加或刪除節點時動態地對數據進行分區，從而逐步擴展。

哈希空間保持巨大且恒定。它通常被稱為 “環”。每個存儲節點都在此散列空間ring中分配了一個隨機位置。

通過哈希數據項的鍵以獲取其在環上的位置，然后順時針旋轉環以找到位置大于該項位置的第一個節點，將每個數據項分配給一個節點。

因此，每個節點都負責它與其前任節點之間的環中區域。因此，添加或刪除節點僅需要重新分配屬于其區域的密鑰，而不需要像模塊化哈希那樣重新分配所有密鑰。

模塊化與一致性哈希

一致性哈希提出了一些挑戰。最明顯的是圍繞環上節點位置的隨機分配，從而導致數據和負載分布不均勻。此外，當添加或刪除節點時，必須通過從單個節點檢索一組鍵來復制一些數據，這通常效率低下且速度慢。

受AWS DynamoDB的啟發，本文討論了經典的一致性哈希所帶來的挑戰，涉及了不同的擴展方面，例如可用性，一致性，性能和持久性。此外，它還討論了數據版本控制和協調，節點成員資格以及故障檢測和處理。它只是參考AWS DynamoDB已發表論文的一般想法和個人注釋的摘要。DynamoDB是Amazon的高可用性鍵值存儲。

將節點映射到T令牌

每個節點T個令牌

為了使用經典的一致性哈希解決非均勻數據和負載分配問題，我們可以將每個節點映射到環中的T個位置(稱為“令牌”)。添加新節點時，會在環上為其分配隨機散布的T位置(令牌)。這具有以下好處：

• 添加節點后，與現有可用節點相比，其負載量大致相等。

• 當某個節點被刪除或由于故障而變得不可用時，該節點處理的負載將以相反的過程分配回來，從而有效地將負載平均分配到其余可用節點上。

可用性

— 復制

跨多個節點復制數據對于實現高可用性至關重要。每個數據項都在N個節點上復制。節點協調寫請求，負責復制環中N-1個順時針后繼位置(令牌)中屬于其范圍內的數據項。第一后繼位置可能是由另一個哈希函數確定的隨機性，也可能是跨不同的數據中心確定的以提高可用性。

一些有用的定義：N是每個數據項的副本數，公共值為3；R是要確認/回復讀請求的副本數；W則是要確認/保留寫請求的副本數；S是系統中的節點數；T是環上物理節點的令牌(位置)數；密鑰范圍是指環上與令牌相關聯的一組密鑰(令牌由節點擁有)。

— 始終可寫

我們都知道，在分布式系統世界中，網絡故障和數據沖突并不少見，因此無法同時實現高一致性和數據可用性。傳統算法會在故障情況下權衡數據的可用性，因此在絕對確定數據正確之前，使數據不可用。

相反，我們可以通過解決答案的正確性的不確定性來提高可用性，允許更改傳播到后臺的副本中，并且允許并發的，斷開的工作。

這種方法的挑戰在于，它可能導致沖突的變化，必須加以檢測和解決。解決沖突的過程引入了兩個問題：何時解決問題以及誰來解決。

一致性

— 解決沖突：何時

在讀取或寫入期間是否應解決沖突。許多傳統的數據存儲解決了寫入期間的沖突，并使讀取的復雜性保持簡單。如果數據存儲無法到達W節點，則會以拒絕寫入為代價，從而有效地降低了系統可用性。將沖突解決方案推送至讀取可確保永不拒絕寫入。檢測到數據版本沖突時，不會拒絕讀取；現在的問題是誰以及如何解決？

— 解決沖突：誰

這可以通過數據存儲本身或應用程序客戶端來完成。

應用程序客戶端知道數據模式和業務邏輯，因此可以決定沖突的解決方案。以購物車示例為例，當客戶要將商品添加到購物車(或從購物車中刪除)而最新版本不可用時，則將商品添加到舊版本(或從舊版本中刪除)，并且將不同版本以后和解。這種變化仍然有意義，應該保留。讀取時，當檢測到沖突版本時，應用程序客戶端可以選擇“合并”沖突版本并返回單個統一購物車。

另一方面，如果數據存儲區正在處理沖突，則其選擇相當有限，并且只能使用簡單的策略，例如基于時間戳的“最后寫入獲勝”對帳邏輯(即，選擇具有最新時間戳值的項目)作為正確的版本)。維護客戶會話信息的服務就是該用例的一個很好的例子。

— 解決沖突：如何

版本沖突對帳

數據版本控制使我們能夠檢測，解決沖突的版本，從而確保數據的一致性。節點執行的每次更新都被視為數據的新的和不變的版本。一個版本由(節點，計數器)對組成，即[(N，c)，…]，其中N是協調寫請求的節點。

在大多數情況下，新版本包含以前的版本，并且數據存儲本身可以確定權威版本。

但是，在出現故障并發更新的情況下，可能會發生版本(并行)分支，從而導致項目的版本沖突。在這種情況下，數據的多個分支折疊為一個。前面解釋的一個典型示例是應用程序客戶端“合并”客戶購物車的不同版本。

為了說明讀寫工作流程：

讀

協調讀取請求的節點將從所有N個節點中獲取給定項的鍵來請求該項的現有版本。

然后它將等待N個節點中的R個節點進行回復。

返回結果。如果檢測到版本沖突，特別是數據存儲無法協調的并行分支，它將把沖突的項目及其版本上下文信息返回給客戶端。客戶端通過將分支折疊成一個版本來協調不同版本后，執行更新。

寫

協調寫請求的節點將在本地存儲它，生成一個新版本，并在N-1個位置(令牌)之間復制它。客戶端必須指定要更新的版本。通過傳遞從較早的讀取操作獲得的上下文來完成此操作。

一旦N個節點中的W個節點作出響應，就認為寫入請求成功。

性能

為讀和寫操作提供一致的高性能非常困難，因為性能受到R或W副本中最慢的限制。

一些應用需要高水平的性能，并且可以權衡耐用性與性能(即R = 1，W = 1)。為此，每個存儲節點在其主內存中維護一個對象緩沖區。每個寫操作都存儲在緩沖區中，并定期寫入持久性存儲中。每個讀取操作首先檢查緩沖區中是否存在請求的密鑰。如果是這樣，則從緩沖區而不是存儲引擎中讀取對象。

這將導致延遲降低很多，但要兼顧耐久性。服務器崩潰可能導致丟失在緩沖區中排隊的寫操作。

持久性

為了降低持久性風險，處理寫請求的協調器節點從N-1個副本中選擇一個，將數據寫到其持久性存儲中。并且由于協調器節點僅等待W響應，因此寫操作的性能不會受到影響。

通常，增加成功寫入操作時需要確認的節點數量可以提高持久性，但同時也要犧牲可用性。如果沒有足夠多的活動節點可以答復，則寫入請求可能會被拒絕。

跨數據中心復制數據項以承受因斷電，網絡故障和自然災害導致的故障很重要。

節點成員資格

節點之間基于gossip的協議傳播成員身份更改(節點加入或離開環)并維護成員身份的最終一致性。

每個節點每秒都與隨機選擇的一個對等方聯系，并且兩個節點有效地協調了其持久的成員資格更改歷史記錄。

因此，每個存儲節點都知道其對等節點處理的令牌。這允許每個節點直接將密鑰的讀/寫操作轉發到正確的節點集。

這消除了維護故障狀態的集中全局一致視圖的需要。

故障檢測與處理

故障檢測和處理可以避免失敗的讀取或寫入嘗試，即使在最簡單的故障條件下，這樣做也會降低可用性和耐久性。

—臨時故障：提示切換

如果節點B不響應節點A的消息，則節點A可能認為節點B暫時處于關閉狀態。然后，節點A使用備用節點執行請求；節點A定期重試B以檢查后者的恢復情況。

在沒有客戶端請求來驅動兩個節點之間的流量的情況下，兩個節點都不真正需要知道另一個節點是否可訪問且是否響應。

為了處理此問題，通常將原本存在于B上的數據項現在將發送到節點X(B的臨時副本)。發送到副本X的數據項將在其元數據中具有提示，提示哪個節點是副本的預期接收者(在本例中為B)。

接收提示數據項的節點會將它們保存在單獨的本地數據庫中，該數據庫會定期進行掃描。在檢測到B已恢復后，X將嘗試將數據傳遞給B。一旦傳輸成功，X可能會從其本地存儲中刪除該數據項。

使用提示切換，我們確保寫操作不會由于臨時節點或網絡故障而失敗。

—持久故障：副本同步

在某些情況下(例如節點中斷)，節點B可能會長時間不可用，并且提示的數據項甚至可能無法返回。為解決此問題，使用了使用Merkle樹的副本同步協議來使副本保持同步并檢測不一致之處。

Merkle樹遍歷

Merkle樹是一種哈希樹，其中的葉子是各個鍵的值的哈希值。樹中較高的父節點是其各自子節點的哈希。Merkle樹的主要優點是，樹的每個分支都可以獨立且并行地進行檢查。此外，Merkle樹有助于減少需要傳輸的數據量并減少執行的磁盤讀取次數。兩個節點可以遍歷其Merkle樹，以共同擁有的關鍵范圍來確定它們是否存在差異。

每個節點為其承載的每個密鑰范圍(與令牌關聯的密鑰集)維護一個單獨的Merkle樹。這允許節點比較密鑰范圍內的密鑰是否為最新。

回顧

因此，總結一下添加和刪除節點以及讀取和寫入的工作流程：

添加節點

• 當節點X加入時，它會在環上選擇其隨機令牌集。

• 對于分配給節點X的每個密鑰范圍，當前可能有許多節點負責處理屬于其令牌范圍內的密鑰。由于將密鑰范圍分配給X，因此現有節點不再需要存儲這些密鑰，這些節點會將這些密鑰轉移到 X。

• 通過上面討論的基于八卦的協議，協調成員資格更改歷史并維護成員資格的最終一致性視圖。

刪除節點

• 當節點被刪除或由于故障而變得不可用時，這表示永久離開，因此，成員資格更改會傳播，以通知其他節點有關節點刪除的信息。

• 對于由已刪除節點處理的密鑰范圍，它們被隨機分配到其余節點，因此，將負載平均分配到其余可用節點上。

讀

客戶端請求由負載均衡器統一分配給環中的節點。任何節點都可以充當讀取請求的協調器。

協調讀取請求的節點會將請求發送到密鑰K的所有N個節點，并等待N個節點中的R個。

收集數據，確定是否需要對帳(如前所述)。此過程稱為“讀取修復”，因為它會修復錯過了最近更新的副本，并使副本同步協議不必執行此操作。

寫

與讀取不同，寫請求由帶有密鑰K的數據項的節點副本之一協調。如果接收到請求的節點不是該數據項的密鑰的節點副本，它將把請求轉發到N個副本之一此限制是由于這些首選節點還具有創建新版本標記的責任。如果版本控制方案基于物理時間戳，則任何節點都可以協調寫請求。

等待N個節點之外的W個節點作出響應。

應用程序客戶端庫可以是可感知分區的客戶端庫，可將請求直接路由到適當的協調器節點。在這種情況下，我們可以實現較低的延遲，因為如果負載均衡器將請求分配給隨機節點，它會跳過額外的網絡躍點。

挑戰性

由于令牌是在環上隨機選擇的，因此范圍的大小會有所不同。隨著節點的加入和離開系統，令牌集也會更改，因此范圍也會更改。因此，“將節點映射到T令牌”策略提出了以下挑戰：

• 當新節點加入系統時，在關鍵范圍內處理該數據的節點到新節點必須掃描其本地持久性存儲以檢索適當的數據項集。掃描操作占用大量資源，因此需要在后臺執行，而又不影響客戶性能。此外，以最低優先級運行引導任務會極大地減慢引導過程，并在繁忙時段變得很麻煩。

• 當一個節點加入或離開系統時，其他一些節點處理的關鍵范圍將發生變化，并且需要重新計算新范圍的Merkle樹，這對于在生產系統上執行來說是一項不平凡的操作。

• 最后，由于密鑰范圍的隨機性，沒有簡單的方法可以對整個密鑰空間進行快照，這使歸檔過程變得復雜。在這種情況下，歸檔整個密鑰空間需要分別從每個節點檢索密鑰，這是非常低效的。

這種策略的根本問題是數據分區(按令牌劃分)和數據放置(存儲節點)是相互依賴的。在不影響數據分區的情況下添加或刪除節點是不可能的。

將節點映射到T令牌和相等大小的Q分區

每個節點T個令牌和相等大小的Q分區

在這種策略中，將哈希空間劃分為Q個大小相等的固定分區(或鍵范圍)，并且為每個節點分配T個隨機令牌。這里的令牌不決定分區，因此兩個連續的令牌不定義鍵范圍或分區(它們僅定義環上的節點位置)。

通過這種策略，我們可以獲得以下好處：

• 分區和分區放置的分離。數據項在給定鍵K的情況下映射到Q個分區中的一個，而負責存儲該數據項的節點是通過從包含鍵K的分區的末尾順時針旋轉環來選擇的，從而找到第一個令牌的方式，然后找到它的存儲節點。

• 啟用在運行時更改放置方案的可能性。添加或刪除節點不會更改任何數據項的分區(鍵范圍)。

通常將Q設置為Q > S * T，其中S是系統中的節點數。

但是，分配的T令牌的隨機性以及密鑰范圍仍然是一個難題。傳遞數據的節點會掃描其本地持久性存儲，從而導致引導速度變慢；重新計算Merkle樹；并沒有簡單的快照方法。

將節點映射到Q / S令牌和相等大小的Q分區

每個節點的Q / S令牌和相等大小的Q分區

與策略2相似，此策略將哈希空間劃分為Q個大小相等的分區，并且數據放置與數據分區分離。

此外，為每個節點分配Q / S令牌(即T = Q / S)。令牌數量隨著我們添加或刪除節點而改變。

當節點離開系統時，其令牌將隨機分配到其余節點，以便保留這些屬性。同樣，當節點加入系統時，它會以保留這些屬性的方式從系統中的節點竊取令牌。

此策略具有以下優點：

• 更快的引導和恢復。由于分區鍵范圍是固定的，因此可以將它們存儲在單獨的文件中，因此，只需簡單地傳輸文件，就可以將分區作為一個單元重新放置，從而避免了定位特定項目所需的隨機訪問。

• 易于歸檔：分區文件可以單獨歸檔。相比之下，與以前的策略相比，令牌是隨機選擇的，并且對存儲的數據進行歸檔需要分別從各個節點檢索密鑰，并且通常效率低下且速度慢。

這種策略的缺點是添加或刪除節點需要我們保留其屬性(即T = Q / S)。

參考文獻：

• Dynamo：亞馬遜的高可用鍵值存儲

鏈接：

https://medium.com/omarelgabrys-blog/consistent-hashing-beyond-the-basics-525304a12ba

翻譯：奶酪二哈-BKing

The article is only for learning,?if? infringement, please contact BKing8@88.com to delete.

總結

以上是生活随笔為你收集整理的版本不一致_一致哈希：Beyond the basics的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。