怎么快速找到Redis里那些特别火的数据，热点到底咋判断才靠谱呢

要快速找到Redis里的热点数据，并且用一种比较靠谱的方式来判断，这事儿说难也不难，说简单也不简单，核心思路就是，你不能靠猜，得靠“看”，看什么呢？看每个数据被访问的频率和模式，下面我们抛开那些让人头疼的专业术语,用大白话聊聊具体可以怎么做。

最直接但有点笨的办法：用Redis自带的命令监控

一个最直接的想法是，我能不能看到每个键被访问了多少次？Redis本身没有提供一个像HOTKEYS这样的神奇命令，一运行就直接把热点键列给你，Redis提供了一个叫monitor的命令（来源：Redis官方文档关于MONITOR命令的说明），当你运行monitor后，Redis服务器会把你接下来执行的所有命令，包括键名,都实时打印出来。

你可以这么做：在业务高峰期，开一个客户端，执行monitor，然后让这个命令跑上一小段时间，比如一分钟，这时候，你的屏幕上会飞速滚动过去这段时间内所有的操作记录，你把这段输出保存到文件里，然后用一些文本处理工具，比如grep、awk之类的，去统计哪个键名出现的次数最多，出现次数最多的那些,八九不离十就是热点键了。

这个方法有个巨大的缺点（来源：Redis官方文档通常不推荐在生产环境长时间使用MONITOR），第一，monitor命令本身非常耗性能，它会严重拖慢Redis服务器的速度，因为所有命令它都要过一遍并输出，在生产环境上长时间跑这个，简直就是给自己找麻烦，可能会引发线上故障，第二，一分钟的数据量可能就非常巨大，分析起来很麻烦；而且它统计的是命令次数，如果一个键被反复get，那它肯定是热点，但如果是一个大的hash键，虽然只被hgetall了一次，但实际访问了内部大量数据，这种模式monitor可能就反映不出来其“热”的真正程度，这算是个“杀鸡用牛刀”且风险较高的临时性办法，只能偶尔用于紧急排查,不能作为常规的热点发现机制。

更靠谱的办法：利用Redis 4.0之后引入的LFU算法信息

从Redis 4.0版本开始，它内部淘汰数据的策略多了一个叫LFU（最近最少使用）的选项（来源：Redis 4.0 release notes 中关于LFU eviction policy的说明），LFU的意思是，Redis会跟踪每个键的被访问频率，而不仅仅是最近一次被访问的时间，这正好就是我们判断热点需要的信息——频率！

虽然Redis还是没有直接提供一个命令来列出热点键，但它提供了一个非常关键的诊断命令：OBJECT freq <key>（来源：Redis官方文档关于OBJECT命令的说明），这个命令可以查询任意一个指定键的“热度”值，这个值就是一个反映访问频率的数字,数字越大表示越热。

怎么利用这个功能呢？你没办法手动去猜哪些键可能是热的然后一个个查，这里的技巧是结合另一个命令：scan。scan命令可以安全地、渐进式地遍历数据库里所有的键，而不会像keys *那样阻塞服务器。

一个可行的自动化思路是（来源：基于Redis特性和常见实践方案的推导）：

1. 写一个脚本，定期（比如在业务低峰期）用scan命令遍历Redis里所有的键。
2. 对于遍历到的每一个键，都用OBJECT freq命令去获取它的频率值。
3. 设定一个你认为的“热点阈值”，比如频率值大于100的，把所有频率超过这个阈值的键记录下来，或者直接按频率值从高到低排个序，取Top N（比如前20个）。
4. 这样,你就能得到一份当前数据库中的热点键候选名单。

这个方法比monitor要安全得多，因为它不会持续产生巨大开销，只是在低峰期做一次快照式的扫描，得到的数据是基于Redis内部统计的访问频率，也更准确反映了“热”的本质，它也不是实时的,会有一定的延迟。

终极武器：使用Redis的缓存穿透保护功能

如果你用的Redis版本比较新（比如5.0或以上），还有一个更“自动化”的途径，就是利用Redis的缓存穿透保护机制，也叫“客户端缓存追踪”（来源：Redis官方博客关于Client side caching的介绍），这个功能的本意是让Redis服务器能追踪哪些键被哪些客户端缓存了,当键被修改时通知客户端失效其本地缓存。

但这个功能的底层实现需要服务器知道每个键的被访问情况，在一些云服务商提供的Redis产品或者一些企业级的Redis监控工具中，它们可能会基于这个底层能力，开发出图形化的热点Key实时监控功能，你直接在管理控制台上就能看到一个实时的热点Key排行榜，非常直观，如果你的环境支持这种功能，那这无疑是最省心、最靠谱的方式了,你需要做的就是去查看你的Redis服务提供商是否提供了此类监控面板。

判断热点“靠不靠谱”还需要结合业务逻辑

光有技术手段找到的“热点键”还不够，判断它是否“靠谱”还需要你动脑筋结合业务想一想。

• 访问模式：一个键每秒被读1000次，另一个键每秒被写500次，哪个对系统压力更大？通常写的压力更大,所以热点也要区分是读热点还是写热点。
• 键的大小：一个存储了10KB数据的键被访问100次，和一个存储了1MB数据的键被访问50次，后者带来的网络流量和内存操作压力可能远大于前者，大Key”即使访问频率不是最高，也可能是个需要关注的“热点”。
• 是否可优化：找到热点不是终点，目的是优化，这个热点数据是否可以被进一步拆分？是否可以通过本地缓存（如Guava Cache）减轻Redis压力？它的过期时间设置是否合理？

快速找到Redis热点数据，从靠谱程度和可行性来看：优先查看你的管理控制台是否有现成工具 -> 其次考虑用scan+object freq脚本定期扫描 -> 万不得已时再短暂使用monitor命令，永远记得结合业务场景来最终判断一个热点是否真的“有问题”以及如何解决它。