redis数据分布

    分布式数据库首要问题是要解决把整个数据集按照分区的规则映射到多个节点的问题。即把数据划分到多个节点上，每个节点负责整体数据的一个子集。大致如下图所示：

我们需要重点关注的是分区的规则。常见的规则由顺序分区，哈希分区。

顺序分区：离散度易倾斜，数据分布业务相关，可顺序访问。

哈希分区：离散度好，数据分布业务无关，无法顺序访问。

因为redis cluster采用了哈希分区规则，我们就重点介绍哈希分区。常见的哈希分区规则有几种：

节点取余分区：

使用特定的数据（包括redis的键或用户ID），再根据节点数量N，使用公式：hash(key)%N计算出一个0~（N-1）值，用来决定数据映射到哪一个节点上。即哈希值对节点总数取余。余数x，表示这条数据存放在第（x+1）个节点上。

优点：简单

缺点：当节点数量N变化时（扩容或者收缩），数据和节点之间的映射关系需要重新计算，这样的话，按照新的规则映射，要么之前存储的数据找不到，要么之前数据被重新映射到新的节点（导致以前存储的数据发生数据迁移）。这是难以接受的。

实践：常用于数据库的分库分表规则，一般采用预分区的方式，提前根据数据量规划好分区数，比如划分为512或1024张表，保证可支撑未来一段时间的数据量，再根据负载情况将表迁移到其他数据库中。扩容时通常采用翻倍扩容，避免数据映射全部被打乱导致全量迁移的情况，如下图所示：

一致性哈希分区：

在一致性哈希中，我们把所有的数据包括节点数据都放在一个哈希环上，我们除了需要计算要存储的数据的key的hash之外，还要计算节点的hash，然后在存储时，选择一个跟key的hash最接近的节点（顺时针找到第一个大于等于该哈希值的节点），存储进去．

优点：加入和删除节点只影响哈希环中相邻的节点，对其他的节点无影响。

缺点：1加减节点，会造成哈希环中部分数据无法命中，需要手动处理或者忽略这部分数据，因此一致性哈希常用于缓存场景。？？？2当使用少量节点时，节点变化将大范围影响哈希环中数据映射，因此这种方式不适合少量数据节点的分布式方案。3普通的一致性哈希分区在增加节点时需要增加一倍或减去一半节点才能保证数据和负载的均衡。

上图中的前缀为s的节点，表示集群中的一个节点，前缀为x的节点，表示要写或读的数据．从第一张圆圈中，我们可以看到，由于x1, x2的hash值里s0最近，所以被存到s0这台节点中了，同理，x0被存到了s2这个节点中了．在第二个圆圈中，由于多了一台节点，s3, 而x2现在又离它最近，所以，x2需要从s0节点迁移到s3中．

从上图中，我们也能看到，一致性哈希解决了由于集群变动而导致的数据迁移率高的问题。但是又引入了另一个复杂的问题，就是每个节点的负载不相同，因为每个节点的hash是根据IP计算出来的．换句话说就是：假设key足够多，被hash算法打散得非常均匀，但是由于图中的S没有被均匀的打散在环形中，导致每个节点处理的key个数不太一样，甚至相差很大。

虚拟槽分区：

虚拟槽分区就是为了解决一致性哈希分区的不足而被创造的。虚拟槽分区巧妙地使用了哈希空间，使用分散度良好的哈希函数把所有的数据映射到一个固定范围的整数集合中，整数定义为槽（slot）。这个范围一般远远大于节点数，比如redis Cluster槽的范围是0-16383，一共16384个槽。槽是集群内数据管理和迁移的基本单位。采用大范围槽的主要目的是为了方便数据拆分和集群扩展。每个节点会负责一定数量的槽（虚拟节点），之前我们在介绍一致性哈希的时候，是将物理节点直接通过哈希运算得到其hash值，而后数据的key计算出来之后，与节点的哈希进行比较，决定存放在哪个节点中．而现在，我们用几个槽（虚拟节点）代表一个物理节点．不同槽（虚拟节点）的hash是通过不同的哈希函数计算出来的。以redis为例子，假设现在我们有5个节点，一共分配16384个槽（虚拟节点）。那么数据，槽（虚拟节点），节点的关系看起来就是这样的了：

redis把数据分布到不同节点带来集群功能的限制：

1>key批量操作支持有限：如mset，mget,目前只支持 具有相同slot值得key执行批量操作。对于映射为不同slot值得key由于执行mset,mget等操作可能存在于多个节点上因此不被支持。

2>key事物操作支持有限:同理只支持多个key在同一个节点上的事物操作，当多个key分布在不同的节点上时无法使用事物功能。

3>key作为数据分区的最小粒度，因此不能将一个大的键值对象如hash,list等映射到不同的节点。

4>不支持多数据库空间。单机下的redis可以支持16个数据库，集群模式下只能使用一个数据空间，即db 0。

5>复制结构只支持一层，从节点只能复制主节点，不支持嵌套树状复制结构。