面試必備:什麼是一致性Hash演算法?

最近有小夥伴跑過來問什麼是Hash一致性演算法,說面試的時候被問到了,因為不了解,所以就沒有回答上,問我有沒有相應的學習資料推薦,當時上班,沒時間回復,晚上回去了就忘了這件事,今天突然看到這個,加班為大家整理一下什麼是Hash一致性演算法,希望對大家有幫助!文末送書,長按抽獎助手小程序即可參與,祝君好運!

經常閱讀我文章的小夥伴應該都很熟悉我寫文章的套路,上來就是先要問一句為什麼?也就是為什麼要有Hash一致性演算法?就像以前介紹為什麼要有Spring一樣,首先會以歷史的角度或者項目發展的角度來分析,今天的分享還是一樣的套路,先從歷史的角度來一步步分析,探討一下到底什麼是Hash一致性演算法!

一、Redis集群的使用

我們在使用Redis的時候,為了保證Redis的高可用,提高Redis的讀寫性能,最簡單的方式我們會做主從複製,組成Master-Master或者Master-Slave的形式,或者搭建Redis集群,進行數據的讀寫分離,類似於資料庫的主從複製和讀寫分離。如下所示:

同樣類似於資料庫,當單表數據大於500W的時候需要對其進行分庫分表,當數據量很大的時候(標準可能不一樣,要看Redis伺服器容量)我們同樣可以對Redis進行類似的操作,就是分庫分表。

假設,我們有一個社交網站,需要使用Redis存儲圖片資源,存儲的格式為鍵值對,key值為圖片名稱,value為該圖片所在文件伺服器的路徑,我們需要根據文件名查找該文件所在文件伺服器上的路徑,數據量大概有2000W左右,按照我們約定的規則進行分庫,規則就是隨機分配,我們可以部署8台緩存伺服器,每台伺服器大概含有500W條數據,並且進行主從複製,示意圖如下:

由於規則是隨機的,所有我們的一條數據都有可能存儲在任何一組Redis中,例如上圖我們用戶查找一張名稱為」a.png」的圖片,由於規則是隨機的,我們不確定具體是在哪一個Redis伺服器上的,因此我們需要進行1、2、3、4,4次查詢才能夠查詢到(也就是遍歷了所有的Redis伺服器),這顯然不是我們想要的結果,有了解過的小夥伴可能會想到,隨機的規則不行,可以使用類似於資料庫中的分庫分表規則:按照Hash值、取模、按照類別、按照某一個欄位值等等常見的規則就可以出來了!好,按照我們的主題,我們就使用Hash的方式。

二、為Redis集群使用Hash

可想而知,如果我們使用Hash的方式,每一張圖片在進行分庫的時候都可以定位到特定的伺服器,示意圖如下:

上圖中,假設我們查找的是」a.png」,由於有4台伺服器(排除從庫),因此公式為hash(a.png) % 4 = 2 ,可知定位到了第2號伺服器,這樣的話就不會遍歷所有的伺服器,大大提升了性能!

三、使用Hash的問題

上述的方式雖然提升了性能,我們不再需要對整個Redis伺服器進行遍歷!但是,使用上述Hash演算法進行緩存時,會出現一些缺陷,主要體現在伺服器數量變動的時候,所有緩存的位置都要發生改變!

試想一下,如果4台緩存伺服器已經不能滿足我們的緩存需求,那麼我們應該怎麼做呢?很簡單,多增加幾台緩存伺服器不就行了!假設:我們增加了一台緩存伺服器,那麼緩存伺服器的數量就由4台變成了5台。那麼原本hash(a.png) % 4 = 2 的公式就變成了hash(a.png) % 5 = ? , 可想而知這個結果肯定不是2的,這種情況帶來的結果就是當伺服器數量變動時,所有緩存的位置都要發生改變!換句話說,當伺服器數量發生改變時,所有緩存在一定時間內是失效的,當應用無法從緩存中獲取數據時,則會向後端資料庫請求數據(還記得上一篇的《緩存雪崩》嗎?)!

同樣的,假設4台緩存中突然有一台緩存伺服器出現了故障,無法進行緩存,那麼我們則需要將故障機器移除,但是如果移除了一台緩存伺服器,那麼緩存伺服器數量從4台變為3台,也是會出現上述的問題!

所以,我們應該想辦法不讓這種情況發生,但是由於上述Hash演算法本身的緣故,使用取模法進行緩存時,這種情況是無法避免的,為了解決這些問題,Hash一致性演算法(一致性Hash演算法)誕生了!

四、一致性Hash演算法的神秘面紗

一致性Hash演算法也是使用取模的方法,只是,剛才描述的取模法是對伺服器的數量進行取模,而一致性Hash演算法是對2^32取模,什麼意思呢?簡單來說,一致性Hash演算法將整個哈希值空間組織成一個虛擬的圓環,如假設某哈希函數H的值空間為0-2^32-1(即哈希值是一個32位無符號整形),整個哈希環如下:

整個空間按順時針方向組織,圓環的正上方的點代表0,0點右側的第一個點代表1,以此類推,2、3、4、5、6……直到2^32-1,也就是說0點左側的第一個點代表2^32-1, 0和2^32-1在零點中方向重合,我們把這個由2^32個點組成的圓環稱為Hash環。

下一步將各個伺服器使用Hash進行一個哈希,具體可以選擇伺服器的IP或主機名作為關鍵字進行哈希,這樣每台機器就能確定其在哈希環上的位置,這裡假設將上文中四台伺服器使用IP地址哈希後在環空間的位置如下:

接下來使用如下演算法定位數據訪問到相應伺服器:將數據key使用相同的函數Hash計算出哈希值,並確定此數據在環上的位置,從此位置沿環順時針「行走」,第一台遇到的伺服器就是其應該定位到的伺服器!

例如我們有Object A、Object B、Object C、Object D四個數據對象,經過哈希計算後,在環空間上的位置如下:

根據一致性Hash演算法,數據A會被定為到Node A上,B被定為到Node B上,C被定為到Node C上,D被定為到Node D上。

五、一致性Hash演算法的容錯性和可擴展性

現假設Node C不幸宕機,可以看到此時對象A、B、D不會受到影響,只有C對象被重定位到Node D。一般的,在一致性Hash演算法中,如果一台伺服器不可用,則受影響的數據僅僅是此伺服器到其環空間中前一台伺服器(即沿著逆時針方向行走遇到的第一台伺服器)之間數據,其它不會受到影響,如下所示:

下面考慮另外一種情況,如果在系統中增加一台伺服器Node X,如下圖所示:

此時對象Object A、B、D不受影響,只有對象C需要重定位到新的Node X !一般的,在一致性Hash演算法中,如果增加一台伺服器,則受影響的數據僅僅是新伺服器到其環空間中前一台伺服器(即沿著逆時針方向行走遇到的第一台伺服器)之間數據,其它數據也不會受到影響。

綜上所述,一致性Hash演算法對於節點的增減都只需重定位環空間中的一小部分數據,具有較好的容錯性和可擴展性。

六、Hash環的數據傾斜問題

一致性Hash演算法在服務節點太少時,容易因為節點分部不均勻而造成數據傾斜(被緩存的對象大部分集中緩存在某一台伺服器上)問題,例如系統中只有兩台伺服器,其環分布如下:

此時必然造成大量數據集中到Node A上,而只有極少量會定位到Node B上。為了解決這種數據傾斜問題,一致性Hash演算法引入了虛擬節點機制,即對每一個服務節點計算多個哈希,每個計算結果位置都放置一個此服務節點,稱為虛擬節點。具體做法可以在伺服器IP或主機名的後面增加編號來實現。

例如上面的情況,可以為每台伺服器計算三個虛擬節點,於是可以分別計算 「Node A#1」、「Node A#2」、「Node A#3」、「Node B#1」、「Node B#2」、「Node B#3」的哈希值,於是形成六個虛擬節點:

同時數據定位演算法不變,只是多了一步虛擬節點到實際節點的映射,例如定位到「Node A#1」、「Node A#2」、「Node A#3」三個虛擬節點的數據均定位到Node A上。這樣就解決了服務節點少時數據傾斜的問題。在實際應用中,通常將虛擬節點數設置為32甚至更大,因此即使很少的服務節點也能做到相對均勻的數據分布。

七、總結

上文中,我們一步步分析了什麼是一致性Hash演算法,主要是考慮到分散式系統每個節點都有可能失效,並且新的節點很可能動態的增加進來的情況,如何保證當系統的節點數目發生變化的時候,我們的系統仍然能夠對外提供良好的服務,這是值得考慮的!


推薦閱讀:

我對Raft的理解 - One
分散式系統中的一致性
The Part-Time Parliament(四):Paxos一致性證明
paxos和一個實際的key-value分散式系統讀寫的距離
論文筆記:[USENIX ATC14] In Search of an Understandable Consensus Algorithm (Raft)

TAG:分散式系統 | Redis | 分散式一致性 |