最近一個月一直忙碌自己的事情沒有更新「知乎」，今天就繼續一個月前的文章繼續我們下面的課程，這裡跟有興趣的朋友說下，因為工作和家庭的原因，我會盡量每周更新一篇文章，歡迎大家關注。謝謝。

redis-cluster簡介說明：

Redis Cluster 是 Redis 的分散式解決方案，在3.0版本正式推出，有效地解決了 Redis 分散式方面的需求。當遇到單機內存、並發、流量等瓶頸時，可以採用 Cluster 架構方案達到負載均衡的目的。

結構圖：

在這個圖中，每一個藍色的圈都代表著一個redis的伺服器節點。它們任何兩個節點之間都是相互連通的。客戶端可以與任何一個節點相連接，然後就可以訪問集群中的任何一個節點，對其進行存取和其他操作。

Redis 集群提供了以下兩個好處：

1、將數據自動切分到多個節點的能力。

2、當集群中的一部分節點失效或者無法進行通訊時， 仍然可以繼續處理命令請求的能力，擁有自動故障轉移的能力。

redis-cluster 和 replication + sentinel如何選擇

1、如果你的數據量很少，主要是承載高並發高性能的場景，比如你的緩存一般就幾個G，單機足夠了

2、Replication：一個mater，多個slave，要幾個slave跟你的要求的讀吞吐量有關係，結合sentinel集群，去保證redis主從架構的高可用性，就可以了。

3、redis-cluster：主要是針對海量數據+高並發+高可用的場景，海量數據，如果你的數據量很大，那麼建議就用redis-cluster。

數據分布的進行方式：

什麼是數據分布？數據分布有兩種方式，順序分區和哈希分區。

分散式資料庫首先要解決把整個數據集按照分區規則映射到多個節點的問題，即把數據集劃分到多個節點上，每個節點負責整體數據的一個子集。

順序分區：

順序分布就是把一整塊數據分散到很多機器中，如下圖所示。

順序分布一般都是平均分配的。

哈希分區：

如下圖所示，1~100這整塊數字，通過 hash 的函數，取余產生的數。這樣可以保證這串數字充分的打散，也保證了均勻的分配到各台機器上。

哈希分布和順序分布只是場景上的適用。哈希分布不能順序訪問，比如你想訪問1~100，哈希分布只能遍歷全部數據，同時哈希分布因為做了 hash 後導致與業務數據無關了。

分布方式 特點 代表產品

哈希分區 離散度好 Redis-cluster
數據分布與業務無關 Cassanda
無法順序訪問 Dynamo

順序分區 離散度低 Bigtable
數據分布與業務相關 HBase
可順序訪問 Hypertable

數據切斜、數據遷移和節點伸縮：

順序分布是會導致數據傾斜的，主要是訪問的傾斜。每次點擊會重點訪問某台機器，這就導致最後數據都到這台機器上了，這就是順序分布最大的缺點。

但哈希分布其實是有個問題的，當我們要擴容機器的時候，專業上稱之為「節點伸縮」，這個時候，因為是哈希演算法，會導致數據遷移，而無法命中。

哈希分區方式

因為redis-cluster使用的就是哈希分區規則所以分析下幾種分區形式

1、節點取余分區：

使用特定的數據（包括redis的鍵或用戶ID），再根據節點數量N，使用公式：hash(key)%N計算出一個0~（N-1）值，用來決定數據映射到哪一個節點上。即哈希值對節點總數取余。

缺點：當節點數量N變化時（擴容或者收縮），數據和節點之間的映射關係需要重新計算，這樣的話，按照新的規則映射，要麼之前存儲的數據找不到，要麼之前數據被重新映射到新的節點（導致以前存儲的數據發生數據遷移）

實踐：常用於資料庫的分庫分表規則，一般採用預分區的方式，提前根據數據量規劃好分區數，比如劃分為512或1024張表，保證可支撐未來一段時間的數據量，再根據負載情況將表遷移到其他資料庫中。

2、一致性哈希

一致性哈希分區（Distributed Hash Table）實現思路是為系統中每個節點分配一個 token，範圍一般在0~232，這些 token 構成一個哈希環。數據讀寫執行節點查找操作時，先根據 key 計算 hash 值，然後順時針找到第一個大於等於該哈希值的 token 節點

一致性哈希的原理解析

假設我們有 n1~n4 這四台機器，我們對每一台機器分配一個唯一 token，每次有數據（圖中黃色代表數據），一致性哈希演算法規定每次都順時針漂移數據，也就是圖中黃色的數 據都指向 n3。

這個時候我們需要增加一個節點 n5，在 n2 和 n3 之間，數據還是會發生漂移（會偏移到大於等於的節點），但是這個時候你是否注意到，其實只有 n2~n3 這部分的數據被漂移，其他的數據都是不會變的，這種方式相比節點取余最大的好處在於加入和刪除節點隻影響哈希環中相鄰的節點，對其他節點無影響

缺點：每個節點的負載不相同，因為每個節點的hash是根據key計算出來的,換句話說就是假設key足夠多，被hash演算法打散得非常均勻，但是節點過少，導致每個節點處理的key個數不太一樣，甚至相差很大，這就會導致某些節點壓力很大

實踐：加減節點會造成哈希環中部分數據無法命中，需要手動處理或者忽略這部分數據，因此一致性哈希常用於緩存場景。

3、虛擬槽分區

虛擬槽分區巧妙地使用了哈希空間，使用分散度良好的哈希函數把所有數據映射到一個固定範圍的整數集合中，整數定義為槽（slot）。這個範圍一般遠遠大於節點數，比如 Redis Cluster 槽範圍是0~16383。槽是集群內數據管理和遷移的基本單位。採用大範圍槽的主要目的是為了方便數據拆分和集群擴展。每個節點會負責一定數量的槽，下圖所示。

例如：當前集群有5個節點，每個節點平均大約負責3276個槽。由於採用高質量的哈希演算法，每個槽所映射的數據通常比較均勻，將數據平均劃分到5個節點進行數據分區。Redis Cluster 就是採用虛擬槽分區，下面就介紹 Redis 數據分區方法。

每當 key 訪問過來，Redis Cluster 會計算哈希值是否在這個區間里。它們彼此都知道對應的槽在哪台機器上，這樣就能做到平均分配了。

今天就給大家講到這，在下一節課我們繼續講解docker-Compose的介紹為部署redis cluster 做準備。歡迎大家關注我的知乎和我的專欄。

推薦閱讀：

相关文章