## 为什么要做数据分布 * **分布式数据库首先要解决把整个数据集按照分区规则映射到多个节点的问题，即把数据集划分到多个节点上，每个节点负责整体数据的一个子集**。 如下图所示：  * **需要重点关注的是数据分区规则。**常见的分区规则有哈希分区和顺序分区两种，下图对这两种分区规则进行了对比：  ## 哈希分布 1. 节点取余; 2. 一致性哈希分区; 3. 虚拟槽分区; ## 节点取余分区 * 使用特定的数据，如Redis的键或用户ID，再根据节点数量N使用公式： hash（key）%N计算出哈希值，用来决定数据映射到哪一个节点上; * 这种方案存在一个问题：当节点数量变化时，如扩容或收缩节点，数据节点映射关 系需要重新计算，会导致数据的重新迁移; * 这种方式的突出优点是：简单性，常用于数据库的分库分表规则，一般采用预分区的方式，提前根据数据量规划好分区数，比如划分为512或1024张表，保证可支撑未来一段时间的数据量，再根据负载情况将表迁移到其他数 据库中。扩容时通常采用翻倍扩容，避免数据映射全部被打乱导致全量迁移的情况，如下图所示;  ## 一致性哈希 * 一致性哈希分区（Distributed Hash Table）实现思路是：为系统中每个节点分配一个token，范围一般在0~，这些token构成一个哈希环。数据读写执行节点查找操作时，先根据key计算hash值，然后顺时针找到第一个大于等于该哈希值的token节点，如下图所示  * **这种方式相比节点取余最大的好处在于**加入和删除节点只影响哈希环中相邻的节点，对其他节点无影响; * **但一致性哈希分区存在几个问题：** * 加减节点会造成哈希环中部分数据无法命中（例如一个key增减节点前映射到第3个节点，因此它的数据是保存在第3个节点上的；当我们增加一个节点后被映射到第2个节点上了，此时我们去第2个节点上去找这个key对应的值是找不到的，见下图），需要手动处理或者忽略这部分数据，因此一致性哈希常用于缓存场景 * 当使用少量节点时，节点变化将大范围影响哈希环中数据映射，因此这种方式不适合少量数据节点的分布式方案 * 普通的一致性哈希分区在增减节点时需要**增加一倍或减去一半节点**才能保证数据和负载的均衡; * 正因为一致性哈希分区的这些缺点，一些分布式系统采用虚拟槽对一致性哈希进行改造，比如Dynamo系统 ## 虚拟槽分区 1. 预设虚拟槽:每个槽映射一个数据子集,一般比节点数大; 2. 良好的哈希函数:例如CRC16; 3. 服务端管理节点,槽,数据:例如Redis cluster; *实现思路为： * 虚拟槽分区巧妙地使用了哈希空间，使用分散度良好的哈希函数把所有数据映射到一个固定范围的整数集合中，整数定义为槽（slot）。这个范围 一般远远大于节点数，比如Redis Cluster槽范围是0~16383 * 槽是集群内数据管理和迁移的基本单位。采用大范围槽的主要目的是为了方便数据拆分和集群扩展。每个节点会负责一定数量的槽 * 如下图所示：当前集群有5个节点，每个节点平均大约负责3276个槽  * 由于采用高质 量的哈希算法，每个槽所映射的数据通常比较均匀，将数据平均划分到5个节点进行数据分区 * Redis Cluster就是采用虚拟槽分区，下面就介绍Redis数据分区方法 ## Redis数据分区（槽分区） * **Redis Cluser采用虚拟槽分区，所有的键根据哈希函数映射到0~16383整数槽内，**计算公式：slot=CRC16（key）&16383。每一个节点负责维护一部分槽以及槽所映射的键值数据，如下图所示 ## 为什么是16384个槽位 `CRC16`算法产生的hash值有16bit，该算法可以产生2^16-=65536个值。换句话说，值是分布在0~65535之间。那作者在做`mod`运算的时候，为什么不`mod`65536，而选择`mod`16384？ 如果槽位为65536，发送心跳信息的消息头达8k，发送的心跳包过于庞大。 如上所述，在消息头中，最占空间的是`myslots[CLUSTER_SLOTS/8]`。 当槽位为65536时，这块的大小是: `65536÷8÷1024=8kb` 因为每秒钟，redis节点需要发送一定数量的ping消息作为心跳包，如果槽位为65536，这个ping消息的消息头太大了，浪费带宽。 (2)redis的集群主节点数量基本不可能超过1000个。 如上所述，集群节点越多，心跳包的消息体内携带的数据越多。如果节点过1000个，也会导致网络拥堵。因此redis作者，不建议redis cluster节点数量超过1000个。 那么，对于节点数在1000以内的redis cluster集群，16384个槽位够用了。没有必要拓展到65536个。 (3)槽位越小，节点少的情况下，压缩比高 Redis主节点的配置信息中，它所负责的哈希槽是通过一张bitmap的形式来保存的，在传输过程中，会对bitmap进行压缩，但是如果bitmap的填充率slots / N很高的话(N表示节点数)，bitmap的压缩率就很低。 如果节点数很少，而哈希槽数量很多的话，bitmap的压缩率就很低。  * **Redis虚拟槽分区的特点：** * 解耦数据和节点之间的关系，简化了节点扩容和收缩难度 * 节点自身维护槽的映射关系，不需要客户端或者代理服务维护槽分区 元数据 * 支持节点、槽、键之间的映射查询，用于数据路由、在线伸缩等场景 * 数据分区是分布式存储的核心，理解和灵活运用数据分区规则对于掌握 Redis Cluster非常有帮助 ## Redis集群功能限制 **Redis集群相对单机在功能上存在一些限制，需要开发人员提前了解， 在使用时做好规避。限制如下：** 1）key批量操作支持有限。**如mset、mget，目前只支持具有相同slot值的 key执行批量操作。对于映射为不同slot值的key由于执行mget、mget等操作可 能存在于多个节点上因此不被支持 2）key事务操作支持有限。**同理只支持多key在同一节点上的事务操 作，当多个key分布在不同的节点上时无法使用事务功能 3）key作为数据分区的最小粒度，因此**不能将一个大的键值对象如 hash、list等映射到不同的节点** 4）不支持多数据库空间。单机下的Redis可以支持16个数据库，集群模 式下只能使用一个数据库空间，即db0 5）复制结构只支持一层，从节点只能复制主节点，不支持嵌套树状复制结构