redis 集群数据分区

一.数据分区的介绍

实例图

将全部数据根据分区规则分成多个子集并存储到redis中

二.数据分区的方式

1.顺序分布

特点：数据分散度易倾斜，键值业务相关，可顺序访问
应用：Hbase

2.哈希分布

特点：数据分散度高，兼职分部业务无关，无法顺序访问，支持批量操作

应用：一致性哈希 memcache和redis集群及其他缓存产品

3.哈希分区的三种方式

1）节点取余：hash(key)%node

节点取余

可能出现问题：

当集群充添加一个节点时，数据迁移率太大。建议添加节点时，采用多倍扩容的方式(使迁移率下降到50%)，不推荐使用该分区方法。

节点取余的特点：

a.客户端分片：哈希+取余

b.节点伸缩:数据节点数量的变化，导致数据迁移

c.迁移数量和添加节点数量关系：建议翻倍扩容

2）一致性哈希分区方式：

基本原则：解决了上述取余分区的问题、为系统中每个节点分配一个token，范围一般在0~2的32次方，这些token构成哈希环。数据读写执行节点查找操作时，先根据key计算hash值，然后顺时针找到第一个大于等于该哈希值的token节点。例如，按照顺时针的原则，当key的hash出现在node1和node2之间，则该key就对属于node2；（顺时针取值）

一致性哈希分布

添加节点后的示意图：

添加节点后

一致性哈希扩容：当添加节点时，只会影响相邻的节点；（适用于节点较多的情况）

出现的问题：

a.加减节点会造成哈希环中部分数据无法命中，需要手动处理或者忽略这些数据，常用于缓存场景。因为加入node5之后，原来缓存在node2的部分数据，只能在node5中获取，但是node5没有！

b.当使用少量节点时，节点变化将大范围影响哈希环中数据映射，因此不适合少量数据节点的分布式方案。

c.普通的一致性哈希分区在增减节点时需要增加一倍或者减少一半，才可以保证数据和负载均衡！

特点总结：

a. 客户端分片：哈希+顺时针（优化取余）

b.节点伸缩：只影响邻近的节点，但是还是有数据迁移

c.翻倍伸缩：保障最小的迁移数据和负载均衡

3）虚拟槽分区方式--------->redis集群使用此方法

虚拟槽使用良好的哈希函数把所有数据映射到一个固定范围的整数集合中，整数定义为槽（slot）。

这个范围远远大于节点数，比如redisCluster槽的范围是0~16383;

每一个节点负责维护一部分槽以及所映射的键值数据。

虚拟槽分区

虚拟槽分区的特点：

a.解耦数据和节点之间的关系，简化了节点扩容和收缩的难度。

b.节点自身维护槽的映射关系,不需要客户端或者代理服务维护槽分区元数据

c.支持节点，槽，键之间的映射关系,用于数据路由、在线伸缩等场景。