redis--集群Cluster模式

一、简介

sentinel模式基本可以满足一般生产的需求，具备高可用性。但是当数据量过大到一台服务器存放不下的情况时，主从模式或sentinel模式就不能满足需求了，这个时候需要对存储的数据进行分片，将数据存储到多个Redis实例中。cluster模式的出现就是为了解决单机Redis容量有限的问题，将Redis的数据根据一定的规则分配到多台机器。

Redis Cluster 是 Redis 的分布式解决方案，在 3.0 版本正式推出，有效地解决了Redis 分布式方面的需求，本篇文章只讲理论不讲实操

二、分区规则

分布式数据库首先要解决把整个数据集按照分区规则映射到多个节点的问题，即把数据集划分到多个节点上，每个节点负责整体数据的一个子集，redis是采用哈希分区的方式，接下来介绍几种常见的哈希分区算法

 

1.节点取余分区

使用特定的数据，如Redis的键或用户ID，再根据节点数量N使用公式： hash（key）%N计算出哈希值，用来决定数据映射到哪一个节点上。这种方案存在一个问题：当节点数量变化时，如扩容或收缩节点，数据节点映射关系需要重新计算，会导致数据的重新迁移
这种方式的突出优点是简单性，常用于数据库的分库分表规则，一般采用预分区的方式，提前根据数据量规划好分区数，比如划分为512或1024张表，保证可支撑未来一段时间的数据量，再根据负载情况将表迁移到其他数据库中。扩容时通常采用翻倍扩容，避免数据映射全部被打乱导致全量迁移的情况

该取余方式缺点总结：

（1）必须翻倍扩容不然就会影响映射关系导致全量迁移

（2）因翻倍所以数据迁移约50%的数据，扩展性差

2.一致性哈希分区

暂略

 

3.虚拟槽技术

虚拟槽分区巧妙地使用了哈希空间，槽并不是真实存在只是逻辑上的，使用分散度良好的哈希函数把所有 数据映射到一个固定范围的整数集合中，整数定义为槽（slot ）。这个范围 一般远远大于节点数，比如Redis Cluster 槽范围是 0~16383 。槽是集群内数据 管理和迁移的基本单位。采用大范围槽的主要目的是为了方便数据拆分和集群扩展。每个节点会负责一定数量的槽如下图，每个节点管理了3276个槽

3.1.数据分配：

当插入数据时分以下步骤

（1）首先通过CRC16算法算出redis key的散列值

（2）将此散列值对槽数也就是16383取余算出该数据应该进入到哪个槽中

（3）redis会根据管理的映射关系查到该槽归哪个节点管理

（4）将该数据放入该节点中

3.2.节点的伸缩：

• 当新增一个节点时，例如插入node-6时发生了以下操作

（1）将node-1管理的槽分配一半给node-6，此时node-1管理的槽为0-1638，node-6管理的槽为1639-3276

（2）将node-1中分配出去的槽对应的数据复制到node-6中

 

3.3.虚拟槽技术的优点

（1）伸缩时无需复制大量数据，只需复制一个节点的一半数据即可

（2）可以单个新增，即便不倍数扩容也可以保证映射关系，但是实际还是建议倍数扩容，不然会发生数据偏移（有的节点数据多有的节点数据少 ）

四、集群收缩

收缩集群意味着缩减规模，需要从现有集群中安全下线部分节点

流程说明：

1 ）首先需要确定下线节点是否有负责的槽，如果是，需要把槽迁移到其他节点，保证节点下线后整个集群槽节点映射的完整性。

2 ）当下线节点不再负责槽或者本身是从节点时，就可以通知集群内其他节点忘记下线节点，当所有的节点忘记该节点后可以正常关闭。

 

五、集群倾斜

1.数据倾斜

数据倾斜主要分为以下几种：

（1）节点和槽分配严重不均。

（2）不同槽对应键数量差异过大。

（3）集合对象包含大量元素。

（4）内存相关配置不一致。

 

2.请求倾斜

集群内特定节点请求量 / 流量过大将导致节点之间负载不均，影响集群均衡和运维成本。常出现在热点键场景，当键命令消耗较低时如小对象的 get、 set 、 incr 等，即使请求量差异较大一般也不会产生负载严重不均。但是当热点键对应高算法复杂度的命令或者是大对象操作如hgetall、smembers 等，会导致对应节点负载过高的情况。避免方式如下：

（1）合理设计键，热点大集合对象做拆分或使用 hmget 替代 hgetall 避免整体读取。

（2）不要使用热键作为 hash_tag ，避免映射到同一槽。

（3）对于一致性要求不高的场景，客户端可使用本地缓存减少热键调用。

 

五、Cluster集群模式工作原理

主观下线(pfail)：集群中的每个节点都会定期向其他节点发送ping消息，如果在一段时间内一直通信失败，则发送节点方认为接收节点存在故障，把接收节点标为主观下线(pfail)状态。

客观下线(fail)：当某个节点判断另一个节点主观下线后，相应的节点状态就会在集群中进行传播，如果集群中所有节点都将它标为主观下线，那么该节点为客观下线，并通知该节点的Slave进行故障转移操作。

故障转移：在某个节点客观下线后，该节点的从节点开始故障转移流程，首先进行资格检查，每个从节点检查与主节点的断开时间，超过一定时间的取消选举资格，然后同样在所有从节点中寻找复制偏移量最大的节点先开始进行选举，只有持有槽的主节点才有投票权，当从节点收集到过半的票数时，即晋升为Master，随即通知Slave当前Master变为自己。

 

六、集群架构特点总结

1.多个redis节点网络互联，数据共享

2.所有的节点都是一主一从（也可以是一主多从），其中从不提供服务，仅作为备用，非集群架构可以从节点参与

3.不支持同时处理多个key（如MSET/MGET），因为redis需要把key均匀分布在各个节点上，并发量很高的情况下同时创建key-value会降低性能并导致不可预测的行为
  
4. 支持在线增加、删除节点

5.客户端可以连接任何一个主节点进行读写