热点Key的发现与监控：多维度探测体系
热点Key的发现是削峰治理的第一步。在生产环境中，热点Key往往具有突发性、瞬时性、隐蔽性三大特征。仅靠人工巡检或业务感知远远不够，必须建立一套“客户端-代理层-服务端-持久化层”四维监控体系。本章将系统讲解Redis原生工具与第三方监控平台的热点发现能力，帮助你在毫秒级粒度内锁定热点。
核心原则：热点发现应遵循“先粗后细、先被动后主动”的策略。先通过慢查询日志和monitor命令粗筛可疑Key，再使用--hotkeys和第三方工具精确定位。
2.1 Redis-cli --hotkeys：离线热点扫描利器
Redis 4.0+ 版本内置了 redis-cli --hotkeys 命令，它通过扫描整个数据库的键空间，基于访问频率（LFU）统计信息输出热点Key排名。该命令无需侵入业务代码，适合在低峰期执行离线分析。
| 参数/特性 | 说明 | 适用场景 |
|---|---|---|
| 扫描范围 | 全库Key（默认0号库） | 小规模实例（Key数量 < 1000万） |
| 统计依据 | LFU计数器（object freq） | 需开启 maxmemory-policy allkeys-lfu 或 volatile-lfu |
| 输出格式 | 按热度降序排列，包含Key名、类型、频率值 | 离线分析、定期巡检 |
| 性能影响 | 全量扫描，CPU和内存开销较大 | 建议在业务低峰期执行，或使用 --sleep 参数控制扫描间隔 |
# 基本用法（扫描0号库）
redis-cli --hotkeys
# 指定数据库并控制扫描间隔（单位：微秒）
redis-cli -n 5 --hotkeys --sleep 100
# 输出示例
# [00.00%] Key: user:profile:10086 - 类型: hash - 频率: 152
# [00.01%] Key: product:hot:9527 - 类型: string - 频率: 98
# [00.02%] Key: live:room:8888 - 类型: zset - 频率: 76
注意事项：--hotkeys 依赖LFU策略，如果实例未配置LFU淘汰策略，则无法获取频率信息，命令会返回空结果。此外，全量扫描在百万级Key以上实例中可能阻塞主线程数秒，务必在从节点或低峰期执行。
2.2 monitor命令：实时流量嗅探
monitor 是Redis提供的实时调试命令，能够打印出服务器当前处理的所有命令请求。对于热点Key的实时发现和突发流量追踪，monitor是最直接的手段。但需要注意，monitor在高并发场景下会显著增加服务端CPU开销，且输出日志量极大。
# 启动monitor（默认输出到终端）
redis-cli monitor
# 结合grep过滤特定Key
redis-cli monitor | grep "user:profile:10086"
# 输出示例（每行包含时间戳、客户端IP、命令和Key）
# 1712345678.123456 [0 10.0.0.1:54321] "GET" "user:profile:10086"
# 1712345678.123789 [0 10.0.0.2:54322] "SET" "product:hot:9527" "{\"price\":99}"| 维度 | monitor优势 | monitor劣势 |
|---|---|---|
| 实时性 | 毫秒级输出，无延迟 | 输出量巨大，1万QPS下每秒产生约2MB日志 |
| 精确度 | 可精确到每个命令和Key | 无法直接聚合统计，需配合脚本分析 |
| 性能影响 | 无锁机制，适合短时采样 | 长时间开启可能导致服务端CPU飙升50%以上 |
生产建议：monitor仅用于短时采样（建议不超过30秒），或通过管道将输出重定向到分析脚本进行实时聚合。切勿在生产环境长时间开启monitor，否则可能引发服务降级。
2.3 慢查询日志：定位耗时热点
热点Key不仅表现为高访问频率，还可能表现为高耗时操作（如大Key的HGETALL、SMEMBERS、ZRANGE等）。Redis的慢查询日志（slowlog）能够记录执行时间超过阈值的命令，帮助我们发现那些“虽然频率不高但每次都很慢”的潜在热点。
# 配置慢查询阈值（单位：微秒，10000微秒=10毫秒）
CONFIG SET slowlog-log-slower-than 10000
# 配置慢查询最大记录数
CONFIG SET slowlog-max-len 128
# 查看最近10条慢查询
SLOWLOG GET 10
# 输出示例
# 1) 1) (integer) 14 -- 唯一ID
# 2) (integer) 1712345678 -- Unix时间戳
# 3) (integer) 12000 -- 执行耗时（微秒）
# 4) 1) "HGETALL" -- 命令
# 2) "user:profile:10086" -- Key
# 5) "127.0.0.1:6379" -- 客户端地址
# 6) "user-agent=redis-cli"| 参数 | 推荐值 | 说明 |
|---|---|---|
| slowlog-log-slower-than | 10000~20000（10~20ms） | 根据业务容忍度调整，过小会记录大量正常命令 |
| slowlog-max-len | 128~256 | 内存中保留的慢查询条数，超出后旧记录被丢弃 |
| 监控频率 | 每5分钟采集一次 | 配合定时任务或监控平台轮询 |
最佳实践：将慢查询日志与--hotkeys结果交叉比对。如果一个Key同时出现在慢查询列表和热点列表中，说明该Key既是高频访问又是高耗时操作，需要优先治理。
2.4 第三方监控工具：可视化与告警
原生工具适合临时排查，但无法满足7×24小时的持续监控需求。第三方监控平台提供了可视化仪表盘、历史趋势、阈值告警等能力，是生产环境热点发现的核心载体。以下对比两款主流工具：
| 特性 | RedisLive | CacheCloud |
|---|---|---|
| 部署方式 | Python + Redis存储，轻量级 | Java + MySQL + Redis，企业级 |
| 热点Key发现 | 基于monitor采样 + 频率统计 | 基于代理层拦截 + LFU统计 + 慢查询聚合 |
| 可视化能力 | Top N Key排行、QPS曲线 | 多维热点热力图、大Key分析、命令分布 |
| 告警机制 | 基础阈值告警（邮件） | 多级告警（短信/电话/钉钉），支持自定义规则 |
| 适用规模 | 单机或小集群（< 50节点） | 大规模集群（100+节点），支持应用管理 |
2.5 热点发现策略总结
在实际生产中，单一工具无法覆盖所有场景。建议按照以下分层策略组合使用：
- 离线扫描层：每日凌晨低峰期执行
redis-cli --hotkeys，输出Top 100热点Key，存入监控数据库用于趋势分析。 - 实时嗅探层：每整点开启monitor采样30秒，结合脚本统计当前热点Key，与离线数据交叉验证。
- 慢查询层：持续采集慢查询日志，每5分钟聚合一次，识别高耗时Key并标记为“潜在热点”。
- 平台可视化层：通过RedisLive或CacheCloud展示热点Key的QPS曲线、访问来源分布、命令类型占比，设置多级阈值告警。
实战案例：某电商平台在双11大促期间，通过CacheCloud的“热点Key热力图”发现商品详情页的Key
product:detail:9527 在10秒内QPS从200飙升至8000。系统自动触发告警并通知值班工程师，工程师立即执行本地缓存+Key拆分策略，避免了缓存雪崩。整个过程从发现到治理仅用时3分钟。
通过以上多维度的热点发现与监控体系，你可以在热点Key造成系统故障之前提前感知、精准定位，为后续的削峰治理提供可靠的数据支撑。