分析redis集群中數(shù)據(jù)分布算法

這篇文章主要介紹“分析redis集群中數(shù)據(jù)分布算法”，在日常操作中，相信很多人在分析redis集群中數(shù)據(jù)分布算法問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”分析redis集群中數(shù)據(jù)分布算法”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

哈希算法

哈希算法在分布式架構中應用廣泛，不僅僅是數(shù)據(jù)存儲，還有負載均衡等應用上有用的比較多，哈希算法的思想非常簡單，也許你知道 HashMap  的哈希函數(shù)，哈希算法跟 HashMap  一樣，也是通過一個哈希函數(shù)得到某一個數(shù)字，然后根據(jù)數(shù)字找到相應的服務器。哈希算法的哈希函數(shù)比較簡單，一般是根據(jù)某個key的值或者key 的哈希值與當前可用的  master節(jié)點數(shù)取模，根據(jù)取模的值獲取具體的服務器。哈希算法服務結構模型圖如下圖所示：

哈希算法結構模型圖

用我們前面假設的數(shù)據(jù)，利用哈希算法來實驗一把，加深我們對哈希算法在分布式中的應用的理。我們假設哈希算法中的哈希函數(shù)為“id % master  節(jié)點數(shù)”，結果為 0 的數(shù)據(jù)存放到 server1 服務器上，結果為 1 的數(shù)據(jù)存放到 server2 服務器上，結果為 2 的數(shù)據(jù)存放到 server3  服務器上。

所以經(jīng)過哈希算法之后，id=3、id=6 的數(shù)據(jù)與 master 節(jié)點數(shù)取模為 0 (3%3=0,6%3=0)，所以這兩個數(shù)據(jù)會存放到 server1  服務器 ，以此類推，id=1、id=4 的數(shù)據(jù)將存放到 server2 服務器中，id=2、id=5 的數(shù)據(jù)將存放到 server3  上，這時候服務器存儲數(shù)據(jù)如下圖所示：

服務器存儲數(shù)據(jù)

這就是哈希算法在分布式中的作用，比較簡單，可以看出只要你哈希函數(shù)設計的好，數(shù)據(jù)在各個服務器上是比較均勻分布的，但是哈希算法有一個致命的缺點：擴展性特別的差，比如我們的集群中，服務器server3  宕機了，這時候集群中可用的機器只有兩臺了，這樣哈希函數(shù)就變成了id %  2了，這就會導致一個問題，所有的數(shù)據(jù)需要重新計算，找到新的存儲節(jié)點，每次有服務器宕機或者添加機器時，都需要進行大量的數(shù)據(jù)遷移，這會使得系統(tǒng)的可用性、穩(wěn)定性變差。

一致性哈希算法

一致性哈希算法可以說是哈希算法的升級版，解決了哈希算法擴展性差的問題，一致性哈希算法跟哈希算法不一樣，一致性哈希算法會將服務器和數(shù)據(jù)都通過哈希函數(shù)映射到一個首尾相連的哈希環(huán)上，存儲節(jié)點映射可以根據(jù)  ip  地址來進行哈希取值，數(shù)據(jù)映射到哈希環(huán)上后按照順時針的方向查找存儲節(jié)點，即從數(shù)據(jù)映射在環(huán)上的位置開始，順時針方向找到的第一個存儲節(jié)點，那么他就存儲在這個節(jié)點上。

我們使用一致性哈希算法來存儲我們的數(shù)據(jù)，我畫了一張圖來模擬一致性哈希算法可能出現(xiàn)的結果：

一致性算法模擬存儲圖

我們先來解讀一下這張圖，按照一致性哈希算法的規(guī)則，數(shù)據(jù)沿著順時針的方向查找數(shù)據(jù)，那么 id=4 的數(shù)據(jù)存放在 server1 服務器，id=2  的數(shù)據(jù)存放在服務器 server2 上，id=3、id=1、id=5、id=6 的數(shù)據(jù)都存放在服務器 server3  上，如果你比較敏感的話，也許你就會發(fā)現(xiàn)一致性哈希算法的不足之處， 從圖中可以看出，我們六條數(shù)據(jù)分布不均勻，并不是每臺服務器存儲 2  條數(shù)據(jù)，而且差距好像還有點大，這里我們就要來說一說一致性哈希算法的缺點：一致性哈希算法會會造成數(shù)據(jù)分布不均勻的問題或者叫做數(shù)據(jù)傾斜問題，就像我們圖中那樣，數(shù)據(jù)分布不均勻可能會造成某一個節(jié)點的負載過大，從而宕機。造成數(shù)據(jù)分布不均勻有以下兩種情況：

• 第一：哈希函數(shù)的原因，經(jīng)過哈希函數(shù)之后服務器在哈希環(huán)上的分布不均勻，服務器之間的間距不相等，這樣就會導致數(shù)據(jù)不均勻。

• 第二：某服務器宕機了，后繼節(jié)點就需要承受原本屬于宕機機器的數(shù)據(jù)，這樣也會造成數(shù)據(jù)不均勻。

前面我們提到過一致性哈希算法解決了哈希算法中擴展性差的問題，這個怎么理解呢?我們來看看，在一致性哈希算法中當有存儲節(jié)點加入或者退出時，只會影響應該該節(jié)點的后繼節(jié)點，舉個例子說明一下，例如我們要在服務器server3  和服務 server2 之間加入了一個服務器存儲節(jié)點 server4，只會對服務器server3 造成影響，原本存儲到服務器server3  上的數(shù)據(jù)有一部分會落入到服務器 server4 上，對服務器 server1 和 server2  并沒有任何影響，這樣就不會進行大量的數(shù)據(jù)遷移，擴展性就變強了。

帶有限負載的一致性哈希算法

因為一致性哈希算法的數(shù)據(jù)分布不均勻的問題，Google 在 2017  年提出了帶有限負載的一致性哈希算法來解決這個問題，帶有限負載的一致性哈希算法思想比較簡單，給每個存儲節(jié)點設置了一個存儲上限值來控制存儲節(jié)點添加或移除造成的數(shù)據(jù)不均勻，當數(shù)據(jù)按照一致性哈希算法找到相應的存儲節(jié)點時，要先判斷該存儲節(jié)點是否達到了存儲上限;如果已經(jīng)達到了上限，則需要繼續(xù)尋找該存儲節(jié)點順時針方向之后的節(jié)點進行存儲。

我們利用帶有限負載的一致性哈希算法來改進上面的數(shù)據(jù)存儲，我們限定每臺服務器節(jié)點存儲的數(shù)據(jù)上限為 2 ，數(shù)據(jù)插入的順序就按照 ID  大小的順序，同樣我也畫了一張模擬圖：

帶有限負載的一致性哈希算法

一起來分析一下這張圖，因為我們的添加順序是按照 id 大小的順序，所以前四個數(shù)據(jù)都沒有問題，這時候的服務器都沒有超過最高負載數(shù)量，id=5  的數(shù)據(jù)落在了服務器server2 和服務器server3 之間，本應該是存儲在服務器server3 上，但是由于此時的服務器server3 上已經(jīng)存儲了  id=1、id=3 的數(shù)據(jù)達到了最高限定，因此 id=5 的數(shù)據(jù)會沿著順時針的方向繼續(xù)往下尋找服務器，下一個服務器就是server1，此時的服務器server1  就存儲了 id=4 的數(shù)據(jù)并沒有達到上限，所以 id=5 的數(shù)據(jù)就會存儲在服務器server1，id=6  的數(shù)據(jù)同樣的道理。這樣就利用帶有限負載的一致性哈希算法解決了一致性哈希算法中數(shù)據(jù)分布不均勻的問題。

帶虛擬節(jié)點的一致性哈希算法

帶有限負載的一致性哈希算法也有一個問題，那就是每臺服務器的性能配置可能存在不一樣，如果規(guī)定數(shù)量過小的話，對于配置高的服務器來說有點浪費，這是因為服務器之間可能存在差異，叫做服務器之間的異構性，為了解決服務器之間的異構性問題，引入了一種叫做帶虛擬節(jié)點的一致性哈希算法，帶虛擬節(jié)點的一致性哈希算法核心思想是：根據(jù)每個節(jié)點的性能為每個節(jié)點劃分不同數(shù)量的虛擬節(jié)點，并將這些虛擬節(jié)點映射到哈希環(huán)中，然后再按照一致性哈希算法進行數(shù)據(jù)映射和存儲。

為了演示帶虛擬節(jié)點的一致性哈希算法，我們先做一個假設服務器server3是配置最差的，所以我們以服務器server3 為基準，服務器server2  是服務器server3 的兩倍，服務器server1 是服務器server3 的三倍，有了這個前提之后，我們就可以來建立虛擬節(jié)點，我們假設服務器server3  的虛擬節(jié)點為服務器server3_1，服務器server2 就有兩個虛擬節(jié)點服務器server2_1、服務器server2_2，服務器server1  有三個虛擬節(jié)點 服務器server1_1、服務器server1_2、服務器server1_3。我還是跟前面一樣畫了一張模擬圖：

落到虛擬節(jié)點上的數(shù)據(jù)都會存到對應的物理服務器上，所以通過帶虛擬節(jié)點的一致性哈希算法后，數(shù)據(jù)存儲結果為：數(shù)據(jù)id=2、id=3、id=5  的數(shù)據(jù)都會存儲到服務器server1 上，id=1 的數(shù)據(jù)將會存儲到服務器server2 上，數(shù)據(jù) id=4、id=6  都會存放到服務器server3上。

虛擬節(jié)點可以讓配置好的服務器存儲更多的數(shù)據(jù)，這樣就解決了系統(tǒng)異構性的問題，同時由于大量的虛擬節(jié)點的存在  在數(shù)據(jù)遷移時數(shù)據(jù)會落到不同的物理機上，這樣就減小了數(shù)據(jù)遷移時某臺服務器的分擔壓力，能夠保證系統(tǒng)的穩(wěn)定性。

虛擬槽分區(qū)

虛擬槽分區(qū)是 redis cluster  中默認的數(shù)據(jù)分布技術，虛擬槽分區(qū)巧妙地使用了哈希空間，使用分散度良好的哈希函數(shù)把所有數(shù)據(jù)映射到一個固定范圍的整數(shù)集合中，這個整數(shù)定義為槽(slot)，而且這個槽的個數(shù)一般遠遠的大于節(jié)點數(shù)。

在 redis cluster 中有16384(0~16383)個槽，會將這些槽平均分配到每個 master 上，在存儲數(shù)據(jù)時利用 CRC16  算法，具體的計算公式為：slot=CRC16(key)/16384 來計算 key 屬于哪個槽。在我們的集群環(huán)境中，一個 key  的存儲或者查找過程，可能如下圖所示：

虛擬槽分區(qū)解耦了數(shù)據(jù)與節(jié)點的關系，通過引入槽，讓槽成為集群內(nèi)數(shù)據(jù)管理和遷移的基本單位，簡化了節(jié)點擴容和收縮難度，你只需要關注數(shù)據(jù)在哪個槽，并不需要關心數(shù)據(jù)在哪個節(jié)點上。所以虛擬槽分區(qū)可以說比較好的兼容了數(shù)據(jù)均勻分布和擴展性的問題。

到此，關于“分析redis集群中數(shù)據(jù)分布算法”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關知識，請繼續(xù)關注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>