如何发现缓存中热Key？
作者：程序员马丁
在线博客：https://open8gu.com
大话面试，技术同学面试必备的八股文小册，以精彩回答应对深度问题，助力你在面试中拿个offer。
回答话术
与大 Key 一样，热 Key 没有一个明确定义，通常情况下，当某个 Key 的请求频率显著高于其他 Key 时，我们就可以将其视为热 Key。
热 Key 可能会引发多种问题，包括占用大量的 CPU 资源从而影响 Redis 的吞吐量，或者在集群中可能导致流量不均衡，形成读写热点问题等。
我们可以采用多种途径来发现缓存中的热 Key：
1. 经验评估
对于特定业务场景，我们可以预先评估哪些数据可能成为热点数据，例如秒杀商品、热门商品、大 V 的动态内容等等。
这种方案的优点是实施成本较低，但是由于是基于经验而非实际数据，因此最终的结果可能与实际情况有所偏差。
2. 使用 hotkey 命令
Redis 从版本 4.0 开始引入了 hotkey 命令，允许通过客户端的 redis-cli --hotkeys 命令扫描库中的所有热点 Key。
这种方案的优点是无需引入其他配置或组件，但缺点是性能较差，尤其在处理大量数据时可能会非常耗时。
3. 使用 monitor 命令
当通过 MONITOR 命令开启监视器后，Redis 将在执行命令后输出一些相关的信息。结合日志和相关分析工具（如 redis-faina）就可以对其进行统计。
这种方案的缺点在于，开启监控会显著降低 Redis 性能（单个实例会降低差不多 50% 的性能），如果 Redis 实例本身已经承受较大负荷，启用此功能可能会雪上加霜。
4. 客户端监控
通常情况下，我们会使用客户端（如 Jedis 或 Lettuce）来与 Redis 进行通信。因此，通过在代码中添加一层代理，或使用字节码插桩的方式，我们可以在程序实际请求 Redis 之前上报请求内容，然后通过第三方组件或平台进行分析，以确定哪些 Key 是热 Key。
这种方法的优点在于实施门槛较低，并且由于可以直接在代码里面修改，所以比较灵活。缺点在于二次开发也需要成本，而且在不同的系统中可能无法复用。
当然，目前市场上也有一些带客户端的一站式开源解决方案，比如京东的 Gitee/hotkey，也很好地解决了热 Key 问题。
5. 代理层监控
对于大规模的 Redis 集群（例如各大云商提供的 Redis 服务）的请求通常会经过代理或网关层进行转发。因此，如果代理层可以收集请求信息并上报，那就可以通过分析相关请求信息来确认热 Key。
这种方法与客户端监控相似，但适用范围更广，缺点是引入额外的代理层会增加运维成本，而不是所有集群都支持这种方式。
此处推荐阅读一下得物技术团队的文章：得物热点探测设计与实践 sourl.cn/WGJRaH
6. 服务端监控
除了上述方法，还可以尝试在服务端监听端口以抓包分析请求，或直接修改 Redis 源码添加上报功能。这种方法类似于代理层监控，但最大的问题是实施成本较高。