热key指一段时间内被频繁访问或操作的键。通常出现在商品限时抢购、瞬时新闻热点等业务场景，可能会对系统的稳定性和可用性造成影响，比如对应节点的网卡带宽被打满，出现丢包重传，请求波动耗时大幅上升，甚至影响到业务的正常使用，引发用户的不满。因此，不可能等到热Key出现已经拖垮了服务再去处理，那个时候业务一定已经受到影响，因此需要提前尽可能在设计和开发时避免引入全局热key，另外，真实的生成环境还是可能存在边界case、非预期的流量等，因此快速定位热key仍然需要研究。
需要做到高并发和高性能，对于高频变化的动态数据通常采用多级缓存，搭配缓存预热、缓存失效时长等手段控制。
按照实现的原理，我们可以尝试利用内置的命令或工具，或者外部流量工具，甚至代码层面开统计key的访问频率，进而对热key做进一步操作。
一、探测思路
从Redis请求路径的节点入手。
1. 客户端收集上报
改动 Redis SDK，记录每个请求，定时把收集到的数据上报，然后由一个统一的服务进行聚合计算。
- 优点：方案直观简单
- 缺点：没法适应多语言架构，一方面多语言 SDK 对齐是个问题，另外一方面后期 SDK 的维护升级会面临比较大的困难，成本很高
2. 代理层收集上报
如果所有的 Redis 请求都经过代理的话，可以考虑改动 Proxy 代码进行收集，思路与客户端基本类似。
- 优点：对使用方完全透明，能够解决客户端 SDK 的语言异构和版本升级问题
- 缺点：开发成本会比客户端高些
3. Redis 数据定时扫描
利用Redis自带的工具，优点：无需进行二次开发，能够直接利用现成的工具。
（1）--hotkeys 参数
Redis在4.0版本后提供了hotkeys功能，可以通过redis-cli --hotkeys命令获取当前keyspace的热点key，实现上是通过 scan + object freq 完成的。
- 缺点：
- 由于需要扫描整个 keyspace，实时性上比较差;
- 扫描时间与 key 的数量正相关，如果 key 的数量比较多，耗时可能会非常长。
（2） monitor命令
通过 redis-cli monitor实时抓取出 Redis 服务器接收到的命令，同时结合一些现成的分析工具，比如 redis-faina，统计出热 Key。
- 缺点：在高并发的条件下，有内存暴增的隐患，还会降低 Redis 的性能。
（3）慢查询日志
使用redis-cli slowlog命令查看慢查询日志，记录执行时间超过阈值的命令。间接发现热Key，侧重慢查询，非高频访问。
4. Redis 节点抓包解析
在可能存在热 key 的节点上(流量倾斜判断)，通过 tcpdump 抓取一段时间内的流量并上报，然后由一个外部的程序进行解析、聚合和计算。
- 优点：该方案无需侵入现有的 SDK 或者 Proxy 中间件，开发维护成本可控
- 缺点：热 key 节点的网络流量和系统负载已经比较高了，抓包可能会情况进一步恶化
二、热key的治理
三、生产案例
阿里：第二层，代理层上报
相关补充：
DAU（Daily Active Users，日活跃用户数），指一天内（24小时内）使用产品或服务的独立用户数量，是衡量产品活跃度和用户粘性的重要指标之一。具体由产品的体量决定，例如20w的DAU，对于淘宝就很小，对于小众论坛就很大。
补充：在Windows如何启动redis？
- 进入安装目录并
cmd - 运行命令
redis-server.exe redis.windows.conf。如果报错，依次执行第一条指令：redis-cli.exe，第二条指令：shutdown，第三条指令：exit
参考资料：
工具推荐：