注册

Redis中的HotKey如何解决

对于三高系统,Redis是必须/必需的,当并发高到一定的程度就可能会出现HotKey的问题,今天我们来看下Redis中的HotKey如何解决。


什么是HotKey


在较短的时间内,海量请求访问一个Key,这样的Key就被称为HotKey。


HotKey的危害



  • 海量请求在较短的时间内,访问一个Key,势必会导致被访问的Redis服务器压力剧增,可能会将Redis服务器击垮,从而影响线上业务;
  • HotKey过期的一瞬间,海量请求在较短的时间内,访问这个Key,因为Key过期了,这些请求会走到数据库,可能会将数据库击垮,从而影响线上业务。(这是缓存击穿问题)

HotKey如何解决


HotKey如何解决是一个比较宽泛的问题,涉及到多个方面,我们一个个来看。


Redis部署


通常来说,Redis有两种集群形式:数据分片集群、主从+哨兵集群,其实这两种集群形式或多或少的都一定程度上缓解了HotKey的问题。


主从+哨兵集群


如果我们采用单主:



  • 所有的读请求都会打在仅有的一个Redis服务器,都不用管Key是什么,只要并发一高,就会导致Redis服务器压力剧增;
  • 一旦仅有的一个Redis服务器挂了,就没有第二个Redis服务器顶上去了,无法继续提供服务。

如果我们采用主从+哨兵集群:



  • 读请求会被分散到Master节点或者多台Slave节点,将请求进行了初步的分散;
  • Master节点挂了,Slave节点会升级为新的Master节点,继续提供服务。

数据分片集群


Key被分散在了不同的Redis节点,将请求进行了进一步的分散。


如果采用数据分片集群,同时也会部署主从+哨兵,这样又有了主从+哨兵集群的特性:



  • 读请求会被分散到Master节点或者多台Slave节点,将请求进行了初步的分散;
  • Master节点挂了,Slave节点会升级为新的Master节点,继续提供服务。


画外音:我以前一直以为大部分公司都已经采用了数据分片集群,其实不然,某个我认为不差钱的公司,在2021年采用的还是主从+哨兵集群,出了问题,才转变成数据分片集群,我到我们公司一瞧,才发现我们公司也是主从+哨兵集群。



隔离


不同的业务分配不同的Redis集群,不要将所有的业务都“混杂”在一个Redis集群。


只要可以做到集群+隔离,在一定程度上就已经避免了HotKey,但是对于超高并发的系统来说,可能还有点不够,所以才会有下面的更进一步的措施。


如何应对HotKey


这个问题,可以拆分成三个子问题:如何发现HotKey、如何通知HotKey的产生、如何对HotKey进行处理。


如何发现HotKey


如何发现HotKey的前提是知道每个Key的使用情况,并进行统计,所以这又拆成了两个更小的子问题:如何知道每个Key的使用情况,如何进行统计。


如何知道每个Key的使用情况


谁最清楚知道每个Key的使用情况,当然是客户端、代理层,所以我们可以在客户端或者代理层进行埋点。


客户端埋点

在客户端请求Redis的代码中进行埋点。


优点:



  • 实现较为简单
  • 轻量级
  • 几乎没有性能损耗

缺点:



  • 进行统一管理较为麻烦:如果想开启或者关闭埋点、上报,会比较麻烦
  • 升级、迭代较为麻烦:如果埋点、上报方式需要优化,就需要升级Jar包,再找一个黄道吉日进行发布
  • 客户端会有一定的压力:不管是实时上报使用情况,还是准实时上报使用情况,都会对客户端造成一定的压力

代理层埋点

客户端不直接连接Redis集群,而是连接Redis代理,在代理层进行埋点。


优点:



  • 客户端没有压力
  • 对客户端完全透明
  • 升级、迭代比较简单
  • 进行统一管理比较简单

缺点:



  • 实现复杂
  • 会有一定的性能损耗:代理层需要转发请求到真正的Redis集群
  • 单点故障问题:需要做到高可用,更复杂
  • 单点热点问题:代理层本身就是一个热点,需要分散热点,更复杂

如何上报每个Key的使用情况


我们在客户端或者代理层进行了埋点,自然是由它们上报每个Key的使用情况,如何上报又是一个小话题。


实时/准实时


  • 实时上报:每次请求,都进行上报
  • 准实时上报:积累一定量或者一定时间的请求,再进行上报

是否预统计

如果采用准实时上报,在客户端或者代理层是否对使用情况进行预统计:



  • 进行预统计:减少上报的数据量,减轻统计的压力,自身会有压力
  • 不进行预统计:上报的数据量比较多,自身几乎没有压力

如何统计


不管如何进行上报,使用情况最终都会通过Kafka,发送到统计端,这个时候统计端就来活了。
一般来说,这个时候会借助于大数据,较为简单的方式:Flink开一个时间窗口,消费Kafka的数据,对时间窗口内的数据进行统计,如果在一个时间窗口内,某个Key的使用达了一定的阈值,就代表这是一个HotKey。


如何通知HotKey的产生


经过上面的步骤,我们已经知道了某个HotKey产生了,这个时候就需要通知到客户端或者代理层,那如何通知HotKey的产生呢?



  • MQ:用MQ通知客户端或者代理层HotKey是什么
  • RPC/Http:通过RPC/Http通知客户端或者代理层HotKey是什么
  • 配置中心/注册中心指令:既然遇到了HotKey的问题,并且想解决,那基本上是技术实力非常强大的公司,应该有非常完善的服务治理体系,此时,可以通过配置中心/注册中心下发指令到客户端或者代理层,告知HotKey是什么

如何处理HotKey


客户端或者代理层已经知晓了HotKey产生了,就自动开启一定的策略,来避免HotKey带来的热点问题:



  • 使用本地缓存,不至于让所有请求都打到Redis集群
  • 将HotKey的数据复制多份,分散到不同的Redis节点上

在实际开发中,可能在很大程度上,都不会有埋点、上报、统计,通知、策略自动开启,这一套比较完善的Redis HotKey解决方案,我们能做到的就是预估某个Key可能会成为热点,就采用本地缓存+复制多份HotKey数据的方式来避免HotKey带来的热点问题。我们还经常会因为偷懒,所以设计了一个大而全的Key,所有的业务都从这个Key中读取数据,但是有些业务只需要其中的一小部分数据,有些业务只需要另外一小部分数据,如果不同的业务读取不同的Key,又可以将请求进行分散,这是非常简单,而且有效的方式。


End


作者:CoderBear
链接:https://juejin.cn/post/7196393365314191417
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

0 个评论

要回复文章请先登录注册