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.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在此種用法下，只能當緩存，不能當存儲數據庫！

隨機

隨機選取一個存儲和訪問。
通常結合 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
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/)
更多請關注微信公衆號【編程不離宗】，專一於分享服務器開發與編程相關的技術乾貨：