📚 课程目录第2章热点Key的发现与识别

2. 热点Key的发现与识别

热点Key（Hot Key）是指在一段时间内被大量客户端频繁访问的Redis Key。在Report Export服务中，热点Key通常集中在报表模板、用户权限缓存或高频查询的聚合数据上。如果不能及时发现并处理，热点Key会导致单节点CPU飙升、网络带宽打满、请求超时甚至服务雪崩。本节系统梳理四种主流的热点Key发现手段，并给出每种手段的适用场景与操作要点。

2.1 四种识别手段总览

识别手段	原理	适用场景	主要风险
redis-cli –hotkeys	扫描键空间，统计访问频率	离线分析、快速定位	全量扫描可能阻塞实例
MONITOR 命令	实时捕获所有命令	临时排查、短时流量分析	高并发下性能开销极大
慢查询日志	记录执行时间超过阈值的命令	定位耗时热点操作	无法发现低延迟高频访问
客户端统计	在客户端SDK侧记录访问频次	生产环境长期监控	需改造客户端代码

2.2 redis-cli –hotkeys：离线快速扫描

Redis 4.0+ 提供了内置的热点Key分析工具，通过 redis-cli --hotkeys 命令扫描整个键空间，统计每个Key的访问频率并输出热度排名。该工具基于 OBJECT freq 命令（需要开启 maxmemory-policy 且使用LFU淘汰策略）或扫描键空间计数实现。

操作示例：

# 连接目标实例并执行热点Key扫描
redis-cli -h 10.0.1.100 -p 6379 --hotkeys

# 输出示例（部分）
# Scanning the entire keyspace to find hot keys...
# 1) "user:session:9527" – 访问次数: 45210
# 2) "report:template:weekly" – 访问次数: 38920
# 3) "cache:dept:finance" – 访问次数: 27500

注意：在生产实例上执行 --hotkeys 会触发全量键扫描，对于包含数百万Key的实例，可能造成数秒至数十秒的阻塞。建议在从节点或维护窗口执行，并设置 --sleep 参数降低扫描速度。

2.3 MONITOR 命令：实时抓取命令流

MONITOR 命令可以实时输出Redis服务器接收到的所有命令，通过分析命令流可以识别出高频访问的Key。这种方法适合短时间（1-5分钟）的临时排查，例如在Report Export服务出现突发延迟时，快速确认是否存在热点Key。

操作示例：

# 启动MONITOR，输出到文件
redis-cli -h 10.0.1.100 -p 6379 MONITOR > /tmp/monitor_output.txt

# 等待60秒后按 Ctrl+C 停止，然后统计高频Key
cat /tmp/monitor_output.txt | awk '{print $4}' | sort | uniq -c | sort -nr | head -10

性能警告：MONITOR 在高并发场景下会使Redis吞吐量下降50%以上，甚至导致OOM。仅建议在低峰期或从节点上使用，且持续时间不超过5分钟。

2.4 慢查询日志：定位耗时热点

慢查询日志记录执行时间超过 slowlog-log-slower-than 阈值的命令。虽然慢查询不直接等同于热点Key，但耗时较长的命令往往对应着大数据量操作或复杂计算，这些Key一旦被高频访问，就会成为热点。

配置项	推荐值	说明
slowlog-log-slower-than	10000 (10ms)	超过10ms的命令被记录
slowlog-max-len	128	最多保留128条慢查询记录

查看与分析：

# 查看最近10条慢查询
SLOWLOG GET 10

# 输出示例
# 1) 1) (integer) 14          # 唯一ID
#    2) (integer) 1734567890  # Unix时间戳
#    3) (integer) 45000       # 执行耗时(微秒)
#    4) "GET"                 # 命令
#    5) "report:data:2025-01" # Key名称
#    6) "127.0.0.1:54321"     # 客户端地址

如果慢查询日志中反复出现同一个Key，说明该Key的操作耗时且访问频繁，极有可能是热点Key。

2.5 客户端统计：生产级长期方案

最可靠的热点Key发现方式是在客户端SDK侧进行统计。在Report Export服务的Java/Python/Go客户端中，对每次Redis操作进行计数，按Key维度聚合访问频次，并上报到监控系统（如Prometheus + Grafana）。

推荐实现思路：

使用本地缓存（如Guava Cache）记录每个Key在1秒内的访问次数
每隔5秒将统计结果异步上报到监控系统
设置阈值（如QPS > 5000）触发告警
结合本地Bloom Filter过滤低频Key，减少上报数据量

// Java伪代码示例：客户端热点统计
public class HotKeyTracker {
    private final ConcurrentHashMap<String, AtomicLong> counter = new ConcurrentHashMap<>();
    
    public void recordAccess(String key) {
        counter.computeIfAbsent(key, k -> new AtomicLong()).incrementAndGet();
    }
    
    @Scheduled(fixedDelay = 5000)
    public void report() {
        counter.forEach((key, count) -> {
            long qps = count.get() / 5;
            if (qps > 5000) {
                // 上报告警：key + qps
                alertService.send("HotKey detected: " + key + " QPS=" + qps);
            }
        });
        counter.clear();
    }
}

2.6 四种手段对比与选择建议

2.7 实战建议与避坑指南

不要在生产高峰期使用MONITOR：MONITOR的单线程输出机制会拖垮主实例，如需实时抓取，请连接从节点。
–hotkeys 扫描前评估键数量：如果实例Key数量超过1000万，建议在从节点执行，并设置 --sleep 0.5 降低扫描速度。
慢查询日志无法发现高频小请求：例如每秒10万次GET一个1KB的Key，每次耗时仅0.1ms，不会出现在慢查询中，但却是典型热点。
客户端统计要控制内存开销：如果Key基数极大（百万级），本地计数器可能占用大量内存，建议使用近似计数算法（如Count-Min Sketch）或只统计Top N。
组合使用效果最佳：以客户端统计作为日常监控手段，慢查询日志辅助定位耗时热点，定期在从节点执行 --hotkeys 做全量巡检。