Redis 叢集演進探讨和總結

Redis 叢集演進探讨和總結

Redis為什麼需要叢集？

首先Redis單執行個體主要有單點，容量有限，流量壓力上限的問題。

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

但Redis單Master執行個體提供讀寫服務，仍然有容量和壓力問題，是以需要資料分區，建構多個Master執行個體同時提供讀寫服務（不僅限于從replica節點提供讀服務）。

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

并且資料在各個主Master節點間不能混亂，當然最好還能支援線上資料熱遷移的特性。

探讨資料分區方案

針對資料分區，一般來說，分為兩個大類：

邏輯拆分： 邏輯上能拆分，比如 Redis 中的 M1 節點 存儲 A服務需要的業務資料，而 Redis 中的 M2 節點存儲 B服務需要的業務資料。

資料分區： 當邏輯上不能拆分，那麼隻能按資料來拆分，需要保證用戶端讀和寫資料一緻。 是以需要一個高效快速的資料結構來路由對應的Master節點。 最容易想到的就是類比 Java 中的 HashMap， 采用 雜湊演算法，快速找到，快速設定。 這裡有四種方式，分别是固定取模，随機，哈希一緻性，哈希槽。

固定取模

假設有三個 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.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在此種用法下，隻能當緩存，不能當存儲資料庫！

随機

随機選取一個存儲和通路。 一般結合 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位無符号整形），整個哈希空間環如下：

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。

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。

➜ 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

-> 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

原文位址

https://my.oschina.net/langxSpirit/blog/4287672