Redis集群：一致性哈希
一、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服務器），這顯然不是我們想要的結果。還有可能是同一份數據可能被存在不同的機器上而造成數據冗余，第二個是有可能某數據已經被緩存但是訪問卻沒有命中，因為無法保證對相同key的所有訪問都被發送到相同的服務器。
有了解過的小伙伴可能會想到，隨機的規則不行，可以使用類似于數據庫中的分庫分表規則：按照Hash值、取模、按照類別、按照某一個字段值等等常見的規則就可以出來了！好，按照我們的主題，我們就使用Hash的方式。
為了解決這個問題，我們可以使用簡單的hash算法，比如
h = Hash(key) % 3
這里的hash作用是將輸入的key，轉換成一個整數，然后對3取余數，所以計算出來的結果只有0，1，2三個數字，并且相同的key每次計算出來的結果肯定是相同的
假設我們有N臺機器，現在我們把上面的公式抽象，就是
h = Hash(key) % N
現在我們解決了隨機存放帶來的兩個問題，看起來似乎不錯，但是大家想一下，如果N臺機器里面，萬一有一臺機器X掛了，會出現什么樣的情況。
首先掛了的這臺機器X無論是存放還是獲取操作，都是會失敗的，所以一般監控系統檢測到有機器掛了，肯定會把這臺機器摘除出去，機器數就從N臺減到了N-1臺，那么X后面的機器就需要序號減1，并且計算公式需要調整成
h = Hash(key) % (N-1)
?
我們再來假設另外一種情況，現在有N臺機器提供服務，但是已經支持不下去了，所以新增了一臺機器，那么計算公式需要調整成
h = Hash(key) % (N+1)
?
大家發現上面有什么問題沒有，就是每次有機器掛了，或者新增機器的時候，都需要調整計算公式，這會導致大量的緩存命中不了，我們把這個叫做容錯性和擴展性不強，怎么解決這個問題？
我們來看看一致性hash是怎么做的
?一致性hash
一個設計良好的分布式哈希方案應該具有良好的單調性，即服務節點的增減不會造成大量哈希重定位。一致性哈希算法就是這樣一種哈希方案。最早是1997年由麻省理工大學提出的。
簡單來說，一致性哈希將整個哈希值空間組織成一個虛擬的圓環，如假設某哈希函數H的值空間為0 - 232-1（即哈希值是一個32位無符號整形），整個哈?？臻g環如下：
?
整個空間按順時針方向組織。0和232-1在零點中方向重合。
下一步將各個服務器使用H進行一個哈希，具體可以選擇服務器的ip或主機名作為關鍵字進行哈希，這樣每臺機器就能確定其在哈希環上的位置，這里假設將上文中三臺服務器使用ip地址哈希后在環空間的位置如下：
?
接下來使用如下算法定位數據訪問到相應服務器：將數據key使用相同的函數H計算出哈希值h，通根據h確定此數據在環上的位置，從此位置沿環順時針“行走”，第一臺遇到的服務器就是其應該定位到的服務器。
例如我們有A、B、C、D四個數據對象，經過哈希計算后，在環空間上的位置如下：
?
根據一致性哈希算法，數據A會被定為到Server 1上，D被定為到Server 3上，而B、C分別被定為到Server 2上。
一致性hash的容錯性與可擴展性
下面分析一致性哈希算法的容錯性和可擴展性。現假設Server 3宕機了：
?
可以看到此時A、C、B不會受到影響，只有D節點被重定位到Server 2。一般的，在一致性哈希算法中，如果一臺服務器不可用，則受影響的數據僅僅是此服務器到其環空間中前一臺服務器（即順著逆時針方向行走遇到的第一臺服務器）之間數據，其它不會受到影響。
下面考慮另外一種情況，如果我們在系統中增加一臺服務器Memcached Server 4：
?
此時A、D、C不受影響，只有B需要重定位到新的Server 4。一般的，在一致性哈希算法中，如果增加一臺服務器，則受影響的數據僅僅是新服務器到其環空間中前一臺服務器（即順著逆時針方向行走遇到的第一臺服務器）之間數據，其它不會受到影響。
綜上所述，一致性哈希算法對于節點的增減都只需重定位環空間中的一小部分數據，具有較好的容錯性和可擴展性。
8. 一致性hash的虛擬節點
一致性哈希算法在服務節點太少時，容易因為節點分部不均勻而造成數據傾斜問題。例如我們的系統中有兩臺服務器，其環分布如下：
?
此時必然造成大量數據集中到Server 1上，而只有極少量會定位到Server 2上。為了解決這種數據傾斜問題，一致性哈希算法引入了虛擬節點機制，即對每一個服務節點計算多個哈希，每個計算結果位置都放置一個此服務節點，稱為虛擬節點。具體做法可以在服務器ip或主機名的后面增加編號來實現。例如上面的情況，我們決定為每臺服務器計算三個虛擬節點，于是可以分別計算“Memcached Server 1#1”、“Memcached Server 1#2”、“Memcached Server 1#3”、“Memcached Server 2#1”、“Memcached Server 2#2”、“Memcached Server 2#3”的哈希值，于是形成六個虛擬節點：
?
同時數據定位算法不變，只是多了一步虛擬節點到實際節點的映射，例如定位到“Memcached Server 1#1”、“Memcached Server 1#2”、“Memcached Server 1#3”三個虛擬節點的數據均定位到Server 1上。這樣就解決了服務節點少時數據傾斜的問題。在實際應用中，通常將虛擬節點數設置為32甚至更大，因此即使很少的服務節點也能做到相對均勻的數據分布。
?
再來一把，這是最通俗的一致性hash解釋！
?
?網站為了支撐更大的用戶訪問量，往往需要對用戶訪問的數據做cache,服務機群和負載均衡來專門處理緩存，負載均衡的算法很多，輪循算法、哈希算法、最少連接算法、響應速度算法等，hash算法是比較常用的一種，它的常用思想是先計算出一個hash值，然后使用 CRC余數算法將hash值和機器數mod后取余數，機器的編號可以是0到N-1(N是機器數)，計算出的結果一一對應即可。
? ? ? ?緩存最關鍵的就是命中率這個因素，如果命中率非常低，那么緩存也就失去了它的意義。如采用一般的CRC取余的hash算法雖然能達到負載均衡的目的，但是它存在一個嚴重的問題，那就是如果其中一臺服務器down掉，那么就需要在計算緩存過程中將這臺服務器去掉，即N臺服務器，目前就只有N-1臺提供緩存服務，此時需要一個rehash過程，而reash得到的結果將導致正常的用戶請求不能找到原來緩存數據的正確機器，其他N-1臺服務器上的緩存數據將大量失效，此時所有的用戶請求全部會集中到數據庫上，嚴重可能導致整個生產環境掛掉.
? ? ? ?舉個例子，有5臺服務器，編號分別是0(A)，1(B)，2(C)，3(D)，4(E) ?，正常情況下,假設用戶數據hash值為12，那么對應的數據應該緩存在12%5=2號服務器上，假設編號為3的服務器此時掛掉，那么將其移除后就得到一個新的0(A)，1(B)，2(C)，3(E)(注：這里的編號3其實就是原來的4號服務器)服務器列表，此時用戶來取數據，同樣hash值為12,rehash后的得到的機器編號12%4=0號服務器，可見，此時用戶到0號服務器去找數據明顯就找不到，出現了cache不命中現象，如果不命中此時應用會從后臺數據庫重新讀取數據再cache到0號服務器上，如果大量用戶出現這種情況，那么后果不堪設想。同樣，增加一臺緩存服務器，也會導致同樣的后果。
? ? ? ?可以有一種設想，要提高命中率就得減少增加或者移除服務器rehash帶來的影響，那么有這樣一種算法么?Consistent hashing算法就是這樣一種hash算法，簡單的說，在移除/添加一個 cache 時，它能夠盡可能小的改變已存在 key 映射關系，盡可能的滿足單調性的要求。
1．環形Hash空間
? ? ? ?按照常用的hash算法來將對應的key哈希到一個具有2^32個桶的空間中，即0~(2^32)-1的數字空間中?？梢詫⑦@些數字頭尾相連，想象成一個閉合的環形。如下圖:
2．把數據（key）通過一定的hash算法處理后映射到環上
? ? ? 現在將object1、object2、object3、object4四個對象通過特定的Hash函數計算出對應的key值，然后散列到Hash環上。如下圖：
? ? ? Hash(object1) = key1；
? ? ? Hash(object2) = key2；
? ? ? Hash(object3) = key3；
? ? ? Hash(object4) = key4；
3．將機器通過hash算法映射到環上
? ? ? 在采用一致性哈希算法的分布式集群中將新的機器加入，其原理是通過使用與對象存儲一樣的Hash算法將機器也映射到環中（一般情況下對機器的hash計算是采用機器的IP或者機器唯一的別名作為輸入值），然后以順時針的方向計算，將所有對象存儲到離自己最近的機器中。
? ? ? 假設現在有NODE1，NODE2，NODE3三臺機器，通過Hash算法得到對應的KEY值，映射到環中，其示意圖如下：
? ? ? ?Hash(NODE1) = KEY1;
? ? ? ?Hash(NODE2) = KEY2;
? ? ? ?Hash(NODE3) = KEY3;
? ? ? ?通過上圖可以看出對象與機器處于同一哈希空間中，這樣按順時針轉動object1存儲到了NODE1中，object3存儲到了NODE2中，object2、object4存儲到了NODE3中。在這樣的部署環境中，hash環是不會變更的，因此，通過算出對象的hash值就能快速的定位到對應的機器中，這樣就能找到對象真正的存儲位置了。
4．機器的刪除與添加
? ? ? ?普通hash求余算法最為不妥的地方就是在有機器的添加或者刪除之后會照成大量的對象存儲位置失效，這樣就大大的不滿足單調性了。下面來分析一下一致性哈希算法是如何處理的。
? ? ? ?1. 節點（機器）的刪除
? ? ? ?以上面的分布為例，如果NODE2出現故障被刪除了，那么按照順時針遷移的方法，object3將會被遷移到NODE3中，這樣僅僅是object3的映射位置發生了變化，其它的對象沒有任何的改動。如下圖：
? ? ? ?2. 節點（機器）的添加?
? ? ? ?如果往集群中添加一個新的節點NODE4，通過對應的哈希算法得到KEY4，并映射到環中，如下圖：
? ? ? ?通過按順時針遷移的規則，那么object2被遷移到了NODE4中，其它對象還保持這原有的存儲位置。通過對節點的添加和刪除的分析，一致性哈希算法在保持了單調性的同時，還是數據的遷移達到了最小，這樣的算法對分布式集群來說是非常合適的，避免了大量數據遷移，減小了服務器的的壓力。
5．平衡性
? ? ? ?根據上面的圖解分析，一致性哈希算法滿足了單調性和負載均衡的特性以及一般hash算法的分散性，但這還并不能當做其被廣泛應用的原由，因為還缺少了平衡性。下面將分析一致性哈希算法是如何滿足平衡性的。
? ? ? ?hash算法是不保證平衡的，如上面只部署了NODE1和NODE3的情況（NODE2被刪除的圖），object1存儲到了NODE1中，而object2、object3、object4都存儲到了NODE3中，這樣NODE3節點由于承擔了NODE2節點的數據，所以NODE3節點的負載會變高，NODE3節點很容易也宕機，這樣依次下去可能造成整個集群都掛了。
? ? ? ?在一致性哈希算法中，為了盡可能的滿足平衡性，其引入了虛擬節點?！疤摂M節點”（ virtual node ）是實際節點（機器）在 hash 空間的復制品（replica），一實際個節點（機器）對應了若干個“虛擬節點”，這個對應個數也成為“復制個數”，“虛擬節點”在 hash 空間中以hash值排列。即把想象在這個環上有很多“虛擬節點”，數據的存儲是沿著環的順時針方向找一個虛擬節點，每個虛擬節點都會關聯到一個真實節點。
? ? ? ? 圖中的A1、A2、B1、B2、C1、C2、D1、D2都是虛擬節點，機器A負載存儲A1、A2的數據，機器B負載存儲B1、B2的數據，機器C負載存儲C1、C2的數據。由于這些虛擬節點數量很多，均勻分布，因此不會造成“雪崩”現象。
?
? ? ? 使用虛擬節點的思想，為每個物理節點（服務器）在圓上分配100～200個點。這樣就能抑制分布不均勻，最大限度地減小服務器增減時的緩存重新分布。用戶數據映射在虛擬節點上，就表示用戶數據真正存儲位置是在該虛擬節點代表的實際物理服務器上。
? ? ? 下面有一個圖描述了需要為每臺物理服務器增加的虛擬節點。
? ? ? x軸表示的是需要為每臺物理服務器擴展的虛擬節點倍數(scale)，y軸是實際物理服務器數，可以看出，當物理服務器的數量很小時，需要更大的虛擬節點，反之則需要更少的節點，從圖上可以看出，在物理服務器有10臺時，差不多需要為每臺服務器增加100~200個虛擬節點才能達到真正的負載均衡。
總結
以上是生活随笔為你收集整理的Redis集群：一致性哈希的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Redis集群：redis cluste
- 下一篇： linux cmake编译源码,linu