redis数据分布

我们为什么需要redis集群这样的功能

1.并发量

我们知道redis官方说他是可以支持10万/每秒的并发量，但是如果我们的业务场景需要100万/每秒呢？

2.数据量

还有就是我们的机器最大内存是200G，但是我们的业务需要500G，单机是不能够支持的.

我们的解决方案

1.换更大的内存，更好性能的机器.

2.加多个机器.

当然我们不可能老去买性能好的机器，由于机器的价格昂贵，机器的性能也是有限度的，所以我们只能加多个机器，实现分布式集群这种，才是我们解决问题的最好方案，官方redis也在3.0实现了集群的功能

数据分布

我们按照一定的规则把数据分分布到不同的机器，常见的的规则有

1. 顺序分布

特点 数据分散度易倾斜 键值业务相关 可顺序访问 可以批量操作

1. 哈希分布

特点

数据分散度高

键值分布业务无关

无法顺序访问

可以批量操作

常见的数据分布有三种

1. 节点取余分区
2. 一致性哈希分区
3. 虚拟槽分区

节点取余

我们在刚才已经介绍了节点取余的当时，节点取余是非常简单的方式，他的优点就是简单，但是他在当添加节点的时候，迁移数据是一个明显的缺点，但是我们可以使用成倍的添加节点，可以优化数据迁移的缺点，但是他的迁移量也达到了50%.如下图

一致性哈希

一致性哈希是把数据分成到多个节点，每个节点接受一部分数据，比如上图，有几个数据添加，当数据放到了n1和n2之间，他就会按照顺序放到最近的节点，正如上图添加的数据放到了n2的节点。

当扩容的时候，增加一个节点，他也就会影响邻近的的节点，响应范围小。当节点达到1000节点的时候，效果更佳明显，影响的范围1/1000.

一致性哈希也是客户端的分片，按照哈希和顺时针优化取余，他的节点伸缩，也只会影响临近节点，但是还是有数据的迁移，上图，还会带来一定的问题，比如，数据的负载均衡，当n3和n4的数据量比较大，而n1,n5,n2，数据量比较少，压力都会在n3和n4节点上，因此我们一般扩容都会成倍的扩容节点，如上图，4个节点变成8个节点。

虚拟槽

redisCluster实现数据分布是按照哈希槽实现的，包含了16384个哈希槽，每个节点负责一部分数据，当我们有数据插入的时候，每个key通过CRC16取哈希，再和16384取余，计算出槽的值，然后放到对应的节点中，但是当计算出的槽不在对应的节点，由于节点之间数据共享，节点会告诉你你应该在哪个节点，你去对应的节点操作就可以了。