当前位置: 首页 > 科技观察

下面说说使用RedisCluster集群在集群中的数据分发算法_0

时间:2023-03-12 13:55:58 科技观察

最近看到RedisCluster集群。RedisCluster集群涉及到数据分布问题。因为RedisCluster是多master结构,每个master都可以提供存储。对于服务来说,这会涉及到数据分布的问题,所以借此机会说说分布式中的数据分布算法。在新的redis版本中,采用了虚拟槽分区技术来解决数据分布问题。那就是虚拟插槽分区技术,后面我们会详细介绍。除了虚拟槽分区技术,分布式集群中还有几种数据分布算法,如哈希算法和一致性哈希算法。在本文中,我们将讨论这些数据分发算法。因为是集群,所以需要一个大前提。本文假设rediscluster集群中有3个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的hash值与当前可用主节点的数量取模,根据取模的值得到具体的服务器。哈希算法服务结构模型图如下图所示:哈希算法结构模型图使用我们前面假设的数据,使用哈希算法进行实验,加深了我们对哈希算法在分布式应用的理解。我们假设hash算法中的hash函数为“id%主节点号”,结果为0的数据存放在server1服务器上,结果为1的数据存放在server2服务器上,数据结果2存储在server3上级服务器上。因此,经过hash算法后,id=3和id=6且master节点个数的数据取模为0(3%3=0,6%3=0),所以这两个数据会存储在服务器1服务器。以此类推,id=1和id=4的数据会存储在server2中,id=2和id=5的数据会存储在server3中。此时服务器存储的数据如下图所示:服务器存储的数据是Ha希腊算法在分布式中的作用比较简单。可以看出只要你的hash函数设计的好,数据在各个服务器上的分布是比较均匀的,但是hash算法有一个致命的缺点:扩展性特别差,比如我们的集群中,服务器server3下来了。这个时候集群只有两台机器可用,所以hash函数变成了id%2,这样会导致一个问题,所有的数据都需要重新计算,寻找新的存储节点,每次有一台服务器宕机或者增加一台机器,需要进行大量的数据迁移,这会降低系统的可用性和稳定性。ConsistentHashAlgorithm一致性哈希算法可以说是哈希算法的升级版,解决了哈希算法扩展性差的问题。一致性哈希算法不同于散列算法。一致性哈希算法将数据和数据都通过哈希函数映射到一个端到端的哈希环上。可以根据ip地址哈希存储节点映射。数据映射到哈希环后,按顺时针方向查找存储节点,即从数据在环上映射的位置开始,顺时针找到第一个存储节点,则存储到该节点上.我们使用一致的哈希算法来存储我们的数据。我画了一张图来模拟一致性哈希算法的可能结果:一致性算法模拟存储图我们先来解读一下这张图,一致性哈希算法根据希腊算法的规则,按顺时针方向查找数据,那么id=4的数据存放在server1服务器上,id=2的数据存放在服务器server2上,id=3、id=1、id=5、id=6的数据存放在服务器server3上,如果你比较敏感,可能会发现一致性哈希算法的缺点,从图中可以看出,我们的6个数据分布是不均匀的,并不是每个服务器都存储2条数据,差距好像有点大大的。这里说一下一致性哈希算法的缺点:一致性哈希算法会造成数据分布不均或者数据倾斜的问题。如图所示,不均匀的数据分布可能会导致节点过载,从而导致停机。造成数据分布不均匀的情况有两种:第一:哈希函数的原因。经过哈希函数后,哈希环上的服务器分布不均匀,服务器之间的距离不等,会导致数据分布不均匀。制服。第二:如果一台服务器宕机,后继节点需要承担原本属于宕机机器的数据,同样会造成数据不均匀。前面我们提到,一致性哈希算法解决了哈希算法中可扩展性差的问题。你怎么理解这个?让我们来看看。在一致性哈希算法中,当一个存储节点加入或退出时,只会影响它应该是这个节点的后继节点。让我用一个例子来解释。比如我们要在服务器server3和服务server2之间增加一个服务器存储节点server4,那么只会影响到服务器server3。原本存放在服务器server3上的部分数据会落到服务器server4上,对服务器server1和server2没有影响。这样就不会进行大量的数据迁移,扩展性会变得更强。负载受限的一致性哈希算法由于一致性哈希算法存在数据分布不均的问题,谷歌在2017年提出了负载受限的一致性哈希算法来解决这个问题。负载受限的一致性哈希算法希腊算法的思想是比较简单。为每个存储节点设置一个存储上限,以控制由于存储节点的增加或移除而导致的数据不均匀性。当数据根据一致性哈希算法找到对应的存储节点时,首先要判断存储节点是否已经达到存储上限;如果已经达到上限,则需要继续按顺时针方向查找存储节点之后的节点进行存储。我们使用负载有限的一致性哈希算法来改进上面的数据存储。我们限制每个服务器节点存储的数据上限为2,数据插入的顺序是按照ID大小的顺序。我也画了一个模拟图:Consistenthashingalgorithmwithlimitedload我们一起来分析这张图,因为我们的添加顺序是按照id大小的顺序,所以前四个数据是没有问题的,此时的服务器没有超过最大负载数,id=5的数据落在服务器server2和服务器server3之间,应该存储在服务器server3上,但是id=1和id=3的数据已经存储在服务器server3上了此时达到最大限制,所以id=5的数据会继续顺时针方向寻找服务器,下一个服务器是server1,此时服务器server1已经存储了id=4的数据,并且没有达到上限,所以id=5的数据同理会存储在服务器server1,id=6的数据中。这样,使用负载受限的一致性哈希算法解决了一致性哈希算法中数据分布不均的问题。具有虚拟节点的一致性哈希算法负载受限的一致性哈希算法也有一个问题,即每个服务器的性能配置可能不同。浪费,这是因为服务器之间可能存在差异,这叫做服务器之间的异构性。为了解决服务器之间的异构性问题,引入了一种称为虚拟节点的一致性哈希算法,以虚拟节点为核心的一致性哈希算法的核心思想是:根据每个节点的性能,划分不同数量的虚拟节点对于每一个节点,并将这些虚拟节点映射到哈希环上,然后根据一致的哈希算法和存储进行数据映射。为了演示与虚拟节点的一致性哈希算法,我们首先假设server3是最差的配置,所以我们以server3为基准,server2是server3的两倍,server1是server3的三倍,有了这个前提,我们就可以创建一个虚拟节点了,我们假设服务器server3的虚拟节点是服务器server3_1,服务器server2有两个虚拟节点server2_1,服务器server2_2,服务器server1有三个虚拟节点服务器server1_1,服务器server1_2,服务器server1_3。我还是像之前一样画了一个模拟图:落在虚拟节点上的数据会存储到对应的物理服务器上,所以经过与虚拟节点的一致性哈希算法后,数据存储结果为:dataid=2,id=3,id=5的数据会存放在服务器server1,id=1的数据会存放在服务器server2,数据id=4,id=6的会存放在服务器server3。虚拟节点可以让配置的服务器存储更多的数据,解决了系统异构的问题。同时,由于大量虚拟节点的存在,在数据迁移过程中,数据会落在不同的物理机上,从而降低了数据迁移过程中通过分担某台服务器的压力来保证系统的稳定性。虚拟槽分区虚拟槽分区是redis集群默认的数据分布技术。Virtualslotpartition巧妙地使用了hash空间,使用一个良好分散的hash函数将所有数据映射到一组固定范围的整数上。这个整数被定义为一个槽,槽的数量一般远大于节点的数量。redis集群中有16384(0~16383)个槽位,这些槽位会平均分配给各个master。存储数据时,使用CRC16算法。具体计算公式为:slot=CRC16(key)/16384来计算key属于哪个slot。在我们的集群环境中,一个key的存储或者查找过程可能如下图所示:虚拟slot分区解耦了数据和节点的关系。通过引入槽,槽成为集群中数据管理和迁移的基本单位。简化了节点扩容和缩容的难度。只需要关注数据在哪个槽,不需要关心数据在哪个节点。因此,虚拟槽分区可以说更能兼容数据均匀分布和可扩展性的问题。以上就是我想分享的关于集群中数据分发的技术。希望本文的内容能为您的学习或工作带来一些帮助。感谢您的支持!