架构与思维:如何应对Redis热Key?

2023-12-26 16:35:41

1 什么是Redis HotKey?

分布式系统绕不开的核心点之一的就是数据缓存,有了缓存的支撑,系统的整体吞吐量会有很大的提升。我们通过使用缓存,我们把频繁查询的数据由磁盘调度到高速缓存中,保证数据的高效率读写。
在互联网的大流量场景下,我们经常会遇到一些热点的信息需要存储到Redis中,而这种访问频率高的Key,称为 Hot Key。
Hot Key 处理不好,会产生一些问题。比如短时间的群蜂效应(群蜂请求),大量请求会在短时间内朝着Redis服务冲击,很可能会导致被访问的Redis服务器压力剧增,甚至可能将Redis服务器击垮。
Redis服务关了之后,那对这个Key的请求,都会直接透过缓存层请求到我们的数据库中,数据库性能远低于高速缓存,这样的结果就是直接压垮数据库,进而导致后端服务不可用,造成整体雪崩。

2 Hot Key出现的场景

Hot Key的主要场景包括如下:

  • 电商商品秒杀、活动积分竞拍、热点惊爆新闻等

    • 双十一、618 的商品秒杀,造成短时间内某宝或者夕夕上的爆款商品被浏览百万次
    • 某博上的惊爆新闻等引发大量围观,造成一个redis缓存信息被群蜂冲击,热点Key问题造成服务雪崩,某博研发同学被迫加班修复
  • 请求分片集中,调度不合理,超过单台Redis服务的吞吐瓶颈和性能极限
    Redis缓存会采用分片进行数据管理和性能提升。服务端对数据进行访问时,会通过一些负载均衡策略进行访问平衡,但是类似hash计算,也有可能会落入同一台redis服务器,如果瞬间访问量过大,超过主机吞吐极限时,就会导致热点 Key 现象发生。

  • 突发事件
    系统故障、黑客攻击、自然灾害等,导致大量的用户访问某个特定的Redis Key。

3 Hot Key产生的危害

在Redis中,Hot Key的危害主要体现在以下几个方面:

  1. 单点访问频率过高:Hot Key会导致大部分的访问流量集中在某一个Redis实例上,使得该实例的负载过高,可能会导致该实例崩溃,影响线上业务。
  2. 分片服务瘫痪:Redis集群会分很多个分片,每个分片有其要处理的数据范围。当某一个分片被频繁请求,该分片服务就可能会瘫痪。
  3. Redis分布式集群优势弱化:如果请求不够均衡,过于单点,那么Redis分布式集群的优势也必然被弱化。
  4. 可能造成资损:在极端场景下,容易发生边界数据处理不及时,在订单等场景下,可能造成资损。
  5. 引发缓存击穿:如果缓存请求不到,就会去请求数据库。如果请求过于集中,Redis承载不了,就会有大量请求打到数据库。此时,可能引发数据库服务瘫痪,进而引发系统雪崩。我们在之前的文章中,大量讨论到 缓存击穿、缓存雪崩、缓存穿透
  6. CPU占用高,影响其他服务:单个分片CPU占用率过高,其他分片无法拥有CPU资源,从而被影响。

4 如何监测并分析Hot Key

  1. 容量评估
    联网的业务场景具备一定规律的,根据一些决策树,结合业务场景,可以分析出哪些是热点场景,哪些信息可能是Hot Ke,比如

    • 双11、618的秒杀商品、积分竞拍商品,那么这个商品信息、竞拍/购买操作都是热操作,关联的Redis信息都可能是HotKey。
    • 比如突发的新闻热点,依照画像识别,数据不断攀升,在某个时间点有概率会成为HotKey新闻,需要提前干预
  2. 业务埋点上报
    这种方式low一点,需要切入我们的业务代码进行埋点,加入对Redis Key 调用次数的统计,并把收集到的数据上报到统一的服务进行聚合计算,缺点就是对业务有一定的侵入性。

  3. 使用Redis自带命令
    可以使用INFO命令获取关于Redis服务器的各种信息,包括键的读写次数。通过定期执行INFO命令并分析返回的信息,可以判断哪些键是Hot Key。另外,Redis 4.0.3提供了redis-cli的热点key发现功能,执行redis-cli时加上–hotkeys选项即可。

  4. 使用第三方工具
    如redis-faina是一个现成的分析工具,可以用来分析Redis中的Hot Key。

  5. 使用Redis监控工具
    如使用Redis Exporter可以导出Redis服务器的各种信息,包括键的访问频率等,方便进行监控和分析。

以上是Redis监测并分析Hot Key的几种常见方法,可以根据实际需求选择适合的方法进行操作。

5 如何避免Hot Key引发线上故障

解决Redis中的热key问题,可以采取以下几种解决方案:

  1. 缓存预热
    既然是可预见的HotKey,那么缓存预热是一个好办法,比如双11开启活动前,热点新闻爆出之后,预先加载一些热key的数据到缓存中,以减少对数据库的冲击

    image

  2. 缓存击穿处理
    根据上面的监测预判一些可能会成为HotKey的信息,对缓存击穿进行一些应对处理。详细可以参考『?架构与思维:再聊缓存击穿』的4.5、4.6、4.7节。
    大概如下:

  • 短暂降级之备选缓存

    image

  • 短暂降级之客户端缓存(Redis 6.0)

    image

  • 短暂降级之空初始值

    image

  1. 分布式缓存
    通过分布式缓存系统来分散请求负载,避免单一节点压力过大。现在的Redis高可用部署模式最常见的是主从和Cluster,无论哪一种,都会降低单点带来的影响。

    image

  2. 限流和降级
    可以使用 Hystrix进行限流 + 降级 ,比如一下子来了1W个请求,不是当前系统的吞吐能力能够承受的,假设单秒TPS的能力只能是 5000个,那么剩余的 5000 请求就可以走限流逻辑。
    可以设置一些默认值,然后调用我们自己降级逻辑去FallBack,保护最后的 MySQL 不会被大量的请求挂起。 除了Hystrix之外,阿里的Sentinel 和 Google的RateLimiter 都是不错的选择。

Sentinel 漏桶算法

image

RateLimiter 令牌桶算法

image

  1. 优化数据结构和算法
    通过优化数据结构和算法来减少对热key的访问和更新操作。

  2. 定期清理过期数据
    定期清理过期数据可以避免过多的热key占用缓存空间,从而减少缓存分片服务的压力。

  3. 使用二级缓存
    如JVM本地缓存来实现二级缓存,减少Redis的读请求,可以先从本地缓存中取,取不到再去redis中去取,Redis再取不到采取数据库中取。
    提供了多层保障。

6 总结

本文主要介绍了Redis中的热Key(Hot Key)产生的原因,讨论监测和排查Hot Key的方法,以及采用哪些解决方案来避免Hot Key引发线上故障。

文章来源:https://blog.csdn.net/ruixijava/article/details/135199631
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。