如何应对Redis热Key

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的危害主要体现在以下几个方面：

单点访问频率过高：Hot Key会导致大部分的访问流量集中在某一个Redis实例上，使得该实例的负载过高，可能会导致该实例崩溃，影响线上业务。
分片服务瘫痪：Redis集群会分很多个分片，每个分片有其要处理的数据范围。当某一个分片被频繁请求，该分片服务就可能会瘫痪。
Redis分布式集群优势弱化：如果请求不够均衡，过于单点，那么Redis分布式集群的优势也必然被弱化。
可能造成资损：在极端场景下，容易发生边界数据处理不及时，在订单等场景下，可能造成资损。
引发缓存击穿：如果缓存请求不到，就会去请求数据库。如果请求过于集中，Redis承载不了，就会有大量请求打到数据库。此时，可能引发数据库服务瘫痪，进而引发系统雪崩。我们在之前的文章中，大量讨论到 缓存击穿、缓存雪崩、缓存穿透
CPU占用高，影响其他服务：单个分片CPU占用率过高，其他分片无法拥有CPU资源，从而被影响。
4 如何监测并分析Hot Key
容量评估
联网的业务场景具备一定规律的，根据一些决策树，结合业务场景，可以分析出哪些是热点场景，哪些信息可能是Hot Ke，比如

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

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

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

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

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