Redis 集群演進探討和總結_ZenDei技術網路在線

Redis為什麼需要集群？首先Redis單實例主要有單點，容量有限，流量壓力上限的問題。 Redis單點故障，可以通過主從複製，和自動故障轉移哨兵機制。但Redis單實例提供讀寫服務，仍然有容量和壓力問題，因此需要數據分區，構建多個實例同時提供讀寫服務（不僅限於從節點提供讀服務）。那 ...

Redis為什麼需要集群？

首先Redis單實例主要有單點，容量有限，流量壓力上限的問題。

Redis單點故障，可以通過主從複製replication，和自動故障轉移sentinel哨兵機制。

但Redis單Master實例提供讀寫服務，仍然有容量和壓力問題，因此需要數據分區，構建多個Master實例同時提供讀寫服務（不僅限於從replica節點提供讀服務）。

那麼就需要一定的機制保證數據分區。這樣能充分把容量分攤到多台電腦，或能充分利用多核電腦的性能。

並且數據在各個主Master節點間不能混亂，當然最好還能支持線上數據熱遷移的特性。

探討數據分區方案

file
針對數據分區，一般來說，分為兩個大類：

邏輯拆分：
邏輯上能拆分，比如 Redis 中的 M1 節點存儲 A服務需要的業務數據，而 Redis 中的 M2 節點存儲 B服務需要的業務數據。
數據分區：
當邏輯上不能拆分，那麼只能按數據來拆分，需要保證客戶端讀和寫數據一致。
因此需要一個高效快速的數據結構來路由對應的Master節點。
最容易想到的就是類比 Java 中的 HashMap，採用哈希演算法，快速找到，快速設置。
這裡有四種方式，分別是固定取模，隨機，哈希一致性，哈希槽。

固定取模

file
假設有三個 Master，配置IP 和權重如下：

Real Server IP	weight
10.0.2.21	1
10.0.2.22	2
10.0.2.23	3

那麼會根據每一個real Server 及其權重虛擬出對應權重 weight 個的虛擬vritual server節點，映射關係會是：

Real Server IP	virtual server
10.0.2.21	1
10.0.2.22	2,3
10.0.2.23	4,5,6

一個 key 存儲在那個虛擬vritual server節點，通過哈希hash演算法：

virtual_server_index = hash(key) % (total_virtual_weight)

假設某個key，它的 hash 值是 10，那麼以上： 10%6=4，將落到 10.0.2.23 這個真實的 Master上。

缺點
因為取模的模數是固定的，當新增或刪除 master節點時，所有的數據幾乎要全部洗牌，幾乎需要重新遷移數據（而且相當麻煩），無法做到線上數據熱遷移。
意味著Redis在此種用法下，只能當緩存，不能當存儲資料庫！

隨機

file
隨機選取一個存儲和訪問。
一般結合 list，用於非順序性要求的消息隊列場景。

缺點：
使用場景比較單一。
並且由於隨機性問題，導致持久化存在不可靠性。Redis在此種用法下，也只能當緩存，不能當存儲資料庫！

一致性哈希

一致性哈希演算法（Consistent Hashing）最早在論文《Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web》中被提出。
簡單來說，一致性哈希將整個哈希值空間組織成一個虛擬的圓環，如假設某哈希函數H的值空間為0-2^32-1（即哈希值是一個32位無符號整形），整個哈希空間環如下：
file

1.有一個HASH環，環上每個節點都是一個自然數，從0開始順時針遞增，直到2^32-1，最後回到0
2.真實節點 M1 M2 M3 通過 hash（IP 或主機名）確定在哈希環上的位置
3.當客戶端請求時，首先 hash(key) 確定在哈希環上的位置，然後順時針往後找，找到的第一個真實節點，就是客戶端需要請求訪問的真實主機
優點：
哈希一致性其實是對固定取模的一種優化。
（1）擴展性：當增加節點時，只會影響順時針的真實節點（此部分數據比較難遷移），而不是影響全部的節點。
（2）容錯性：當節點宕機或刪除節點時，只會影響逆時針的真實節點，而不是影響全部的節點。
（3）平衡性：當哈希演算法的節點過少時，會可能造成某些伺服器的數據存儲較多，而另外一些存儲較少，造成數據傾斜，當節點足夠多時，這種現象得以緩解。
因此虛擬節點個數較大的時候，數據的平衡性得以保證。
缺點：
因為當增刪節點時，需要重新計算受影響部分的節點中的key全部找出來，才能遷移，這個很麻煩！！！
Redis在此種用法下，也只能當緩存，不能當存儲資料庫！

哈希槽（PreSharding，預先分片）

這個跟哈希一致性很相似。
區別在於，它預先分配好真實節點管理的哈希槽（slot），並存儲管理起來，我們可以預先知道哪個master主機擁有哪些哈希槽（slot）,這裡總數是16384。
file

127.0.0.1:7001> cluster nodes
2aaf59558f1b9f493a946a695e51711eb03d15f9 127.0.0.1:7002@17002 master - 0 1590126183862 2 connected 5461-10922
6439c3e9468fd2c545a63b3b9bfe658c5fc14287 127.0.0.1:7003@17003 master - 0 1590126181856 3 connected 10923-16383
340d985880c23de9816226dff5fd903322e44313 127.0.0.1:7001@17001 myself,master - 0 1590126182000 1 connected 0-5460

我們可以清晰看到Redis Cluster中的每一個master節點管理的哈希槽。
比如 127.0.0.1:7001 擁有哈希槽 0-5460， 127.0.0.1:7002 擁有哈希槽 5461-10922， 127.0.0.1:7003 擁有哈希槽 10923-16383。
file

➜  redis-cli -p 7001         
127.0.0.1:7001> set a 1
(error) MOVED 15495 127.0.0.1:7003

➜  redis-cli -p 7001 -c
127.0.0.1:7001> set a 1
-> Redirected to slot [15495] located at 127.0.0.1:7003
OK

我們看到的是master節點在 Redis Cluster中的實現時，都存有所有的路由信息。
當客戶端的key 經過hash運算，發送slot 槽位不在本節點的時候。
（1）如果是非集群方式連接，則直接報告錯誤給client，告訴它應該訪問集群中那個IP的master主機。
（2）如果是集群方式連接，則將客戶端重定向到正確的節點上。
註意這裡並不是127.0.0.1:7001 幫client去連接127.0.0.1:7003獲取數據的，而是將客戶端請求重定向了。

優點：
繼承並增強一致性哈希的容錯性，擴展性，以及平衡性。
Redis在此種用法下，可以當緩存，也能當存儲資料庫！
這裡Redis給出更詳細的說明：https://redis.io/topics/partitioning

具體方案

以下列表為按照出現的先後順序排列：

方案	描述	數據分區支持策略	分散式	線上數據熱遷移
twemproxy	twitter 開源的redis代理中間件，不修改redis源碼 https://github.com/twitter/twemproxy	存在modula（固定取模）、 random （隨機）、ketama（哈希一致性）三種可選的配置	本身是單點的，可以通過keepalived等保證高可用	不支持，無法平滑地擴容/縮容
Redis Cluster	官方提供的集群方案	採用預先分片（PreSharding），即哈希槽方式，存儲在每一個master節點上	沒有proxy代理層，客戶端可以連接集群中的任意master節點	提供客戶端命令`redis-cli --cluster reshard ip port`按哈希槽遷移指定節點的數據
codis	豌豆莢開源的redis代理中間件，修改了redis源碼 https://github.com/CodisLabs/codis	採用預先分片（PreSharding），即哈希槽方式，存儲在ZooKeeper上	集群部署，部署相對複雜	支持數據熱遷移

Redis Cluster ：一般生產環境量不大，且採用 Spring 提供的 RedisTemplate 之類封裝好的 fat client ，可以採用
redis6.0後，官方也推出Redis Cluster的proxy方案（https://github.com/RedisLabs/redis-cluster-proxy），只是尚為新，且處於beta階段（2020.5處於1.0beta版本），不成熟。但未來可期，畢竟是官方支持的。
目前如果生產環境量大，但尚無研發能力，可以選用 codis

@SvenAugustus(https://www.flysium.xyz/)
更多請關註微信公眾號【編程不離宗】，專註於分享伺服器開發與編程相關的技術乾貨：