介紹一致性hash演算法之前,先簡單回顧一下分布式以及hash演算法,便於理解為什麼要有一致性hash演算法。
當我們也無需求很複雜時,單台機器io以及頻寬等都會成為瓶頸,所以對業務進行拆分,部署在不同的機器上,當有請求訪問時,根據某些特點將這些請求分散到各個伺服器上,這所有的伺服器組成的網路,我們稱之為集群,這能提高伺服器的效能以及利用率。
如果有乙個請求過來存資料,排程器將資料存在了a伺服器上,下次客戶端再來請求這份資料,該如何迅速判斷資料存在哪台伺服器呢?這時候引出了雜湊的概念。
對於乙個函式:
\[y = f(x)
\]如果兩個雜湊值是不相同的，那麼這兩個雜湊值的原始輸入也是不相同的。這個特性是雜湊函式具有確定性的結果，具有這種性質的雜湊函式稱為單向雜湊函式。
但另一方面，雜湊函式的輸入和輸出不是唯一對應關係的，如果兩個雜湊值相同，兩個輸入值很可能是相同的，但也可能不同，如果值相同稱為「雜湊碰撞（collision）」，這通常是兩個不同長度的輸入值，刻意計算出相同的輸出值。輸入一些資料計算出雜湊值，然後部分改變輸入值，乙個具有強混淆特性的雜湊函式會產生乙個完全不同的雜湊值。雜湊函式是不可逆的,也就是沒法根據雜湊值來反推輸入值。
那麼對於集群而言,每乙個請求都有乙個標識id,如果構造標識到伺服器的雜湊函式,就可以讓同一請求固定的達到伺服器,因為id是不變的:
\[server_ = hash (request_,n)
\]為了均勻分布在不同的伺服器上,這是乙個跟伺服器數量n有關的雜湊函式,常見的有取模運算,即:
\[server_ = hash (request_)\%n
\]但是這時候有個問題,由於是集群,那麼伺服器數量可能會有變化,例如今天請求量非常大要增加伺服器數量,n變大之後,原有的hash值就失效了,需要重新對儲存的請求值做雜湊,由於請求值是乙個龐大的資料集.這樣造成了巨大的不便,需要改進我們的hash演算法。這時候引出了一致性hash的思路。
一致性雜湊的思路是,將雜湊函式與伺服器數量解綁,如果我們用16個二進位制標識雜湊值,那麼雜湊值有乙個範圍區間\([0,65536]\),我們將這個區間65536平均分成n份,n是伺服器數量:
假設伺服器數量是4,那麼對於所有請求,當請求雜湊值介於\([0,16384]\)之間時,將請求分配到server 1,如果請求雜湊值介於\((16384,32768]\)之間時,將請求分配到server 2,後面同理,這樣做有乙個什麼好處呢,如果這時候需要新增加乙個伺服器,假設是server 5:
那麼需要重新計算hash值的僅僅為\([0,8192]\)這部分請求,將其分配到server 5上。
我們已經知道，新增和刪除節點都會影響快取資料的分布。儘管hash演算法具有分布均勻的特性，但是當集群中server數量很少時，他們可能在環中的分布並不是特別均勻，進而導致快取資料不能均勻分布到所有的server上,例如都分配在某乙個或幾個雜湊區間,那麼有很多伺服器可能就沒在這個分布式系統中提供作用。
為解決這個問題，需要使用虛擬節點, 虛擬節點的思想：為每個物理節點（server）在環上分配100～200個點，這樣環上的節點較多，就能抑制分布不均勻。當為cache定位目標server時，如果定位到虛擬節點上，就表示cache真正的儲存位置是在該虛擬節點代表的實際物理server上。另外，如果每個實際server節點的負載能力不同，可以賦予不同的權重，根據權重分配不同數量的虛擬節點。
redis分布式一致性hash演算法
當我們在部署redis節點時，使用者鏈結redis儲存資料會通過hash演算法來定位具體鏈結那個redis節點，在redis節點數量沒有改變的前提下，之前的使用者通過hash演算法會固定的鏈結某一台redis節點，但是若此時我們增加了redis節點，使用者再次hash時，能會hash到別的redis...
一致性Hash演算法 分布式雜湊
一致性雜湊演算法在1997年由麻省理工學院提出的一種分布式雜湊 dht 實現演算法，設計目標是為了解決網際網路中的熱點 hot spot 問題，初衷和carp十分類似。一致性雜湊修正了carp使用的簡單雜湊演算法帶來的問題，使得分布式雜湊 dht 可以在p2p環境中真正得到應用。一致性hash演算法...
分布式一致性演算法
補習了一下分布式相關知識，嗯，還是有很些不懂地方，閱讀不少不錯資源，記錄一下有時間回頭再讀。分布式儲存的強一致性實現方式 1.quorum w r n 2.同步複製 如 pacifica 3.複製狀態機 分布式一致性協議paxos raft zab等 學習分布式系統需要怎樣的知識？cse 552 f...