一致性哈希原理应用

一致性哈希


前言

本文主要讲明一致性哈希的 原理,优点,新问题及解决,应用场景。


一、基本概念/原理

      一致性哈希算法也是使用取模的方法,只不过是对232取模,然后将232个点均匀的散列在一个圆上,这个圆环叫做哈希环。
      可以参考下图,正上方的点代表0,顺时针方向为0,1,2,3…232-1 。
hash环
      结合实际问题解释:
      有三台缓存服务器,需要将信息均匀的放到三台缓存服务器中。
      1、对三台机器的ip进行哈希计算后对232取模,计算出的结果是一个0到232-1之间的一个整数,这样三台机器就映射到了这个环上。(图例为理想情况)
服务器放置hash环
      2、将要存的信息同样映射放置到哈希环上,对信息的key进行hash计算后对232进行取模,计算出来的数值对应hash环上的位置如下图橙点所示,按照顺时针方向找到第一个服务器是A服务器,那么就会把信息放到A服务器中。
资源信息放置服务器
      通过这种方法,判断一个资源应该被缓存到哪台服务器上,将缓存服务器与被缓存资源都映射到hash环上以后,从被缓存资源的位置出发,沿顺时针方向遇到的第一个服务器,就是当前资源将要缓存在上面的服务器,由于被缓存资源与服务器hash后的值是固定的,所以,在服务器不变的情况下,一个资源必定会被缓存到固定的服务器上。下次想要访问这个资源时,只要再次使用相同的算法进行计算,即可算出这个资源被缓存在哪个服务器上,直接去对应的服务器查找对应的资源就可以了。


二、优势

1.服务器故障宕机节点减少

      结合上面三台服务器来说,如果B服务器出现了故障,那么B服务器会从Hash环上移除。如下图所示,原先的资源3是放在B服务器的,现在B宕机移除后,资源3的位置会发生变化,会放到C机器中,但是其他的资源位置不会发生变动。

      一致性hash优点:如果使用之前的hash算法,服务器数量发生改变时,所有服务器的所有缓存在同一时间失效需要重新计算缓存拉取,而使用一致性哈希算法时,服务器的数量如果发生改变,并不是所有缓存都会失效,而是只有部分缓存会失效,前端的缓存仍然能分担整个系统的压力,而不至于所有压力都在同一时间集中到后端服务器上。
B服务器宕机

2.扩容/动态添加服务器

      当我们发现三台机器压力过大需要增加机器时,对新加的机器D进行hash计算后对 232取模映射放置到hash环上,如下图所示,此时只会影响资源2所存的位置,而不会影响其他的资源。
集群扩容

三、存在问题及解决方案

1.哈希环偏斜

      问题:
      在上面hash环上的服务器分布是极其理想化的,在实际情况中可能会出现下图情况,这样的话,1,2,3,4,6号资源均被缓存在了服务器A上,5号资源被缓存在了服务器B上,服务器C上没有缓存任何资源,三台服务器并没有被合理的平均的充分利用。如果此时服务器A出现故障,那么失效缓存的数量也将达到最大值,在极端情况下,仍然有可能引起系统的崩溃,这种情况为hash环的偏斜。
哈希环偏斜

      解决方案:
      可以通过虚拟节点来解决偏斜问题。将现在已有的三台真实的物理服务器节点通过虚拟的方法复制出来,这些节点为虚拟节点。“虚拟节点"是"实际节点”(实际的物理服务器)在hash环上的复制品,一个实际节点可以对应多个虚拟节点。
      如下图所示ABC三台机器分别虚拟出了一个虚拟节点,也可以虚拟出更多的虚拟节点,这样缓存的分布就会刚加均衡,虚拟节点越多,hash环上的节点就越多,缓存被均匀分布的概率就越大。
虚拟节点

2.新增节点数据命中问题

      问题:
      当需要新增服务器时,读取资源的时候,会造成一小部分资源无法直接命中,在新增的服务器上获取资源但新增的服务器中并没有该资源,这个时候会穿透到数据库(或持久性服务器)中先取回资源放到新增机器上后再给服务返回需要的资源。

      解决方案:
      可以分为两阶段,如果拉取的资源没有在离自己最近的服务器上,那么首先去离自己第二近的服务器上拉取资源,然后异步将资源再缓存到最近的服务器上。

四、应用场景

      1、最主要用的场景是redis中多节点集群的负载中。
      2、如果像是图片等资源存的位置是自己管理的集群,可以使用该方式进行负载。一是避免集群中服务器数量发生变化的时候,会发生大量拉取图片的请求无法直接命中而引起的雪崩,导致整体系统压力过大而崩溃;二是如果使用的是其他的负载均衡方式,可能会导致几乎所有的图片资源位置发生变动,在此期间系统可用性会变差。
      3、集群经常需要变动时负载均衡方式可以采用该种方式,动态扩容,宕机等。

总结


本文主要依据实际场景来讲明了一致性hash的原理

  • 12
    点赞
  • 8
    收藏
    觉得还不错? 一键收藏
  • 8
    评论
Redis使用了CRC16校验算法而不是直接使用哈希算法hash()。CRC16是一种校验算法,它可以将任意长度的数据转换成一个16位的校验值。在Redis中,每个Key经过计算后会落在一个具体的槽位上,而槽位具体在哪个机器上是用户根据自己机器的情况配置的。Redis集群包含了16384个哈希槽,通过这种分配方式可以灵活地控制数据分布,避免数据倾斜问题的发生。同时,CRC16校验算法在性能上也有一定的优势。 一致性哈希是另一种常见的数据分布算法,它的空间是一个圆环,节点的分布是基于这个圆环的。然而,Redis集群并没有直接使用一致性哈希算法,而是使用了哈希槽的概念来定义哈希空间。哈希槽可以看作是一个个空间的单位,类似于Windows盘分区的概念。通过自定义分配槽位的大小和位置,可以更好地控制数据的分布,解决了一致性哈希的一些弊端。 在容错性和扩展性方面,Redis集群与一致性哈希算法类似,都可以对受影响的数据进行转移而不影响其他的数据。对于故障节点,可以将其负责的槽位转移到其他正常的节点上;对于扩展节点,可以将其他节点上的槽位转移到新的节点上。这种通过槽位转移来实现容错性和扩展性的方式,与一致性哈希算法中对节点的添加和删除操作类似。 总结来说,Redis使用了CRC16校验算法哈希槽的概念来实现数据的分布和节点的容错性、扩展性。这种方式在控制数据分布和解决数据倾斜问题上具有一定的优势,同时也能够满足中间件等应用场景的需求。<span class="em">1</span><span class="em">2</span><span class="em">3</span> #### 引用[.reference_title] - *1* *3* [redis哈希槽和一致性哈希实现原理](https://blog.csdn.net/csdn_life18/article/details/109262992)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_1"}}] [.reference_item style="max-width: 50%"] - *2* [Redis哈希槽和一致性哈希实现原理](https://blog.csdn.net/xishilife/article/details/120256844)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_1"}}] [.reference_item style="max-width: 50%"] [ .reference_list ]

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 8
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值