架构与思维：如何应对Redis热Key？

★ Redis系列文章

Redis系列1：深刻理解高性能Redis的本质
Redis系列2：数据持久化提高可用性
Redis系列3：高可用之主从架构
Redis系列4：高可用之Sentinel(哨兵模式）
Redis系列5：深入分析Cluster 集群模式
追求性能极致：Redis6.0的多线程模型
追求性能极致：客户端缓存带来的革命
Redis系列8：Bitmap实现亿万级数据计算
Redis系列9：Geo 类型赋能亿级地图位置计算
Redis系列10：HyperLogLog实现海量数据基数统计
Redis系列11：内存淘汰策略
Redis系列12：Redis 的事务机制
Redis系列13：分布式锁实现
Redis系列14：使用List实现消息队列
Redis系列15：使用Stream实现消息队列
Redis系列16：聊聊布隆过滤器（原理篇）
Redis系列17：聊聊布隆过滤器（实践篇）
Redis系列18：过期数据的删除策略
Redis系列19：LRU内存淘汰算法分析
Redis系列20：LFU内存淘汰算法分析
Redis系列21：缓存与数据库的数据一致性讨论
Redis系列22：Redis 的Pub/Sub能力
Redis系列23：性能优化指南
Redis系列24：Redis使用规范

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的数据到缓存中，以减少对数据库的冲击
   

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

• 短暂降级之备选缓存
  

• 短暂降级之客户端缓存（Redis 6.0）
  

• 短暂降级之空初始值
  

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

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

Sentinel 漏桶算法

RateLimiter 令牌桶算法

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

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

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

6 总结

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