借 redis cluster 集群，聊一聊集群中数据分布算法

Redis Cluster 集群中涉及到了数据分布问题，由于 redis cluster 是多 master 的结构，每一个 master 都是能够提供存储服务的，这就会涉及到数据分布的问题，在新的 redis 版本中采用的是虚拟槽分区技术来解决数据分布的问题，关于什么是虚拟槽分区技术咱们后面会详细的介绍。在集群中除了虚拟槽分区技术以外，还有几种数据分布的算法，好比哈希算法，一致性哈希算法，这篇文章咱们就来一块儿聊一聊这几种数据分布算法。

由于是集群，因此咱们须要一个大前提，在这篇文章中假设 redis cluster 集群中有三台 master，咱们须要存储的数据集为：[{id:1,"name":"1"},{id:2,name:"2"},{id:3,name:"3"},{id:4,name:"4"},{id:5:"name":"5"},{id:6,"name":"6"}]，在这个大前提下，咱们来聊一聊集群中的数据分布算法。

哈希算法

哈希算法在分布式架构中应用普遍，不只仅是数据存储，还有负载均衡等应用上有用的比较多，哈希算法的思想很是简单，也许你知道 HashMap 的哈希函数，哈希算法跟 HashMap 同样，也是经过一个哈希函数获得某一个数字，而后根据数字找到相应的服务器。哈希算法的哈希函数比较简单，通常是根据某个key的值或者key 的哈希值与当前可用的 master节点数取模，根据取模的值获取具体的服务器。哈希算法服务结构模型图以下图所示：

用咱们前面假设的数据，利用哈希算法来实验一把，加深咱们对哈希算法在分布式中的应用的理。咱们假设哈希算法中的哈希函数为“id % master 节点数”，结果为 0 的数据存放到 server1 服务器上，结果为 1 的数据存放到 server2 服务器上，结果为 2 的数据存放到 server3 服务器上。

因此通过哈希算法以后，id=三、id=6 的数据与 master 节点数取模为 0 （3%3=0,6%3=0），因此这两个数据会存放到 server1 服务器 ，以此类推，id=一、id=4 的数据将存放到 server2 服务器中，id=二、id=5 的数据将存放到 server3 上，这时候服务器存储数据以下图所示：

这就是哈希算法在分布式中的做用，比较简单，能够看出只要你哈希函数设计的好，数据在各个服务器上是比较均匀分布的，可是哈希算法有一个致命的缺点：扩展性特别的差，好比咱们的集群中，服务器server3 宕机了，这时候集群中可用的机器只有两台了，这样哈希函数就变成了id % 2了，这就会致使一个问题，全部的数据须要从新计算，找到新的存储节点，每次有服务器宕机或者添加机器时，都须要进行大量的数据迁移，这会使得系统的可用性、稳定性变差。

一致性哈希算法

一致性哈希算法能够说是哈希算法的升级版，解决了哈希算法扩展性差的问题，一致性哈希算法跟哈希算法不同，一致性哈希算法会将服务器和数据都经过哈希函数映射到一个首尾相连的哈希环上，存储节点映射能够根据 ip 地址来进行哈希取值，数据映射到哈希环上后按照顺时针的方向查找存储节点，即从数据映射在环上的位置开始，顺时针方向找到的第一个存储节点，那么他就存储在这个节点上。

咱们使用一致性哈希算法来存储咱们的数据，我画了一张图来模拟一致性哈希算法可能出现的结果：

咱们先来解读一下这张图，按照一致性哈希算法的规则，数据沿着顺时针的方向查找数据，那么 id=4 的数据存放在 server1 服务器，id=2 的数据存放在服务器 server2 上，id=三、id=一、id=五、id=6 的数据都存放在服务器 server3 上，若是你比较敏感的话，也许你就会发现一致性哈希算法的不足之处， 从图中能够看出，咱们六条数据分布不均匀，并非每台服务器存储 2 条数据，并且差距好像还有点大，这里咱们就要来讲一说一致性哈希算法的缺点：一致性哈希算法会会形成数据分布不均匀的问题或者叫作数据倾斜问题，就像咱们图中那样，数据分布不均匀可能会形成某一个节点的负载过大，从而宕机。形成数据分布不均匀有如下两种状况：

• 第一：哈希函数的缘由，通过哈希函数以后服务器在哈希环上的分布不均匀，服务器之间的间距不相等，这样就会致使数据不均匀。
• 第二：某服务器宕机了，后继节点就须要承受本来属于宕机机器的数据，这样也会形成数据不均匀。

前面咱们提到过一致性哈希算法解决了哈希算法中扩展性差的问题，这个怎么理解呢？咱们来看看，在一致性哈希算法中当有存储节点加入或者退出时，只会影响应该该节点的后继节点，举个例子说明一下，例如咱们要在服务器server3 和服务 server2 之间加入了一个服务器存储节点 server4，只会对服务器server3 形成影响，本来存储到服务器server3 上的数据有一部分会落入到服务器 server4 上，对服务器 server1 和 server2 并无任何影响，这样就不会进行大量的数据迁移，扩展性就变强了。

带有限负载的一致性哈希算法

由于一致性哈希算法的数据分布不均匀的问题，Google 在 2017 年提出了带有限负载的一致性哈希算法来解决这个问题，带有限负载的一致性哈希算法思想比较简单，给每一个存储节点设置了一个存储上限值来控制存储节点添加或移除形成的数据不均匀，当数据按照一致性哈希算法找到相应的存储节点时，要先判断该存储节点是否达到了存储上限；若是已经达到了上限，则须要继续寻找该存储节点顺时针方向以后的节点进行存储。

咱们利用带有限负载的一致性哈希算法来改进上面的数据存储，咱们限定每台服务器节点存储的数据上限为 2 ，数据插入的顺序就按照 ID 大小的顺序，一样我也画了一张模拟图：

一块儿来分析一下这张图，由于咱们的添加顺序是按照 id 大小的顺序，因此前四个数据都没有问题，这时候的服务器都没有超过最高负载数量，id=5 的数据落在了服务器server2 和服务器server3 之间，本应该是存储在服务器server3 上，可是因为此时的服务器server3 上已经存储了 id=一、id=3 的数据达到了最高限定，所以 id=5 的数据会沿着顺时针的方向继续往下寻找服务器，下一个服务器就是server1，此时的服务器server1 就存储了 id=4 的数据并无达到上限，因此 id=5 的数据就会存储在服务器server1，id=6 的数据一样的道理。这样就利用带有限负载的一致性哈希算法解决了一致性哈希算法中数据分布不均匀的问题。

带虚拟节点的一致性哈希算法

带有限负载的一致性哈希算法也有一个问题，那就是每台服务器的性能配置可能存在不同，若是规定数量太小的话，对于配置高的服务器来讲有点浪费，这是由于服务器之间可能存在差别，叫作服务器之间的异构性，为了解决服务器之间的异构性问题，引入了一种叫作带虚拟节点的一致性哈希算法，带虚拟节点的一致性哈希算法核心思想是：根据每一个节点的性能为每一个节点划分不一样数量的虚拟节点，并将这些虚拟节点映射到哈希环中，而后再按照一致性哈希算法进行数据映射和存储。

为了演示带虚拟节点的一致性哈希算法，咱们先作一个假设服务器server3是配置最差的，因此咱们以服务器server3 为基准，服务器server2 是服务器server3 的两倍，服务器server1 是服务器server3 的三倍，有了这个前提以后，咱们就能够来创建虚拟节点，咱们假设服务器server3 的虚拟节点为服务器server3_1，服务器server2 就有两个虚拟节点服务器server2_一、服务器server2_2，服务器server1 有三个虚拟节点 服务器server1_一、服务器server1_二、服务器server1_3。我仍是跟前面同样画了一张模拟图：

落到虚拟节点上的数据都会存到对应的物理服务器上，因此经过带虚拟节点的一致性哈希算法后，数据存储结果为：数据id=二、id=三、id=5 的数据都会存储到服务器server1 上，id=1 的数据将会存储到服务器server2 上，数据 id=四、id=6 都会存放到服务器server3上。

虚拟节点可让配置好的服务器存储更多的数据，这样就解决了系统异构性的问题，同时因为大量的虚拟节点的存在 在数据迁移时数据会落到不一样的物理机上，这样就减少了数据迁移时某台服务器的分担压力，可以保证系统的稳定性。

虚拟槽分区

虚拟槽分区是 redis cluster 中默认的数据分布技术，虚拟槽分区巧妙地使用了哈希空间，使用分散度良好的哈希函数把全部数据映射到一个固定范围的整数集合中，这个整数定义为槽（slot），并且这个槽的个数通常远远的大于节点数。

在 redis cluster 中有16384（0~16383）个槽，会将这些槽平均分配到每一个 master 上，在存储数据时利用 CRC16 算法，具体的计算公式为：slot=CRC16（key）/16384 来计算 key 属于哪一个槽。在咱们的集群环境中，一个 key 的存储或者查找过程，可能以下图所示：

虚拟槽分区解耦了数据与节点的关系，经过引入槽，让槽成为集群内数据管理和迁移的基本单位，简化了节点扩容和收缩难度，你只须要关注数据在哪一个槽，并不须要关心数据在哪一个节点上。因此虚拟槽分区能够说比较好的兼容了数据均匀分布和扩展性的问题。

以上就是我要分享关于集群中数据分布的技术，但愿本文的内容对你们的学习或者工做能带来必定的帮助，感谢你们的支持

最后

目前互联网上不少大佬都有数据分布相关文章，若有雷同，请多多包涵了。原创不易，码字不易，还但愿你们多多支持。若文中有所错误之处，还望提出，谢谢。

欢迎扫码关注微信公众号：「平头哥的技术博文」，和平头哥一块儿学习，一块儿进步。