2. 热点Key发现与监控：Redis慢查询日志、monitor命令、redis-cli --hotkeys、第三方监控工具（CacheCloud、RedisLive）的配置与使用

热点Key是Redis生产环境中最棘手的性能杀手之一。单个Key的QPS过高会导致Redis实例CPU飙升、网络带宽打满，甚至引发缓存雪崩。本章将系统讲解四种主流的热点Key发现手段，从内置命令到第三方平台，帮助你在不同场景下快速定位热点。

2.1 热点Key发现手段全景对比

不同的发现手段在实时性、性能开销、部署复杂度上各有优劣。下表列出了四种核心方案的对比，便于你在实际项目中按需选择。

手段 原理 实时性 性能开销 部署复杂度 适用场景
慢查询日志 记录执行时间超过阈值的命令 低（事后分析） 极低 低（内置） 排查慢操作、大Key
monitor命令 实时打印所有命令 高（实时） 极高（QPS下降50%+） 低（内置） 临时应急、短时抓包
redis-cli --hotkeys 基于object freq扫描 中（扫描间隔） 中（全库扫描） 低（内置） 离线分析、定期巡检
第三方监控 聚合指标+可视化 高（秒级） 低（代理/采样） 高（需部署） 生产长期监控
选型建议：生产环境推荐以第三方监控为主，配合慢查询日志做事后分析；monitor命令仅用于临时应急，严禁在高峰期长时间开启；redis-cli --hotkeys适合在低峰期做定期巡检。

2.2 慢查询日志：配置与解读

慢查询日志是Redis内置的轻量级诊断工具，记录执行时间超过 slowlog-log-slower-than 阈值的命令。它不会记录命令参数，只记录命令类型、耗时、时间戳等信息，因此性能开销极低。

2.2.1 配置参数

通过 redis.conf 或 CONFIG SET 动态调整以下两个参数：

# 命令执行时间阈值，单位微秒（10000微秒 = 10毫秒）
slowlog-log-slower-than 10000

# 慢查询日志最大条数，超出后淘汰最旧的记录
slowlog-max-len 128
生产建议：阈值建议设为 10ms（10000微秒），日志条数设为 256~1024。阈值过小会刷屏，过大会遗漏潜在热点。

2.2.2 常用命令

# 查看当前慢查询日志（默认最近10条）
SLOWLOG GET 10

# 查看慢查询日志长度
SLOWLOG LEN

# 清空慢查询日志
SLOWLOG RESET

2.2.3 日志字段解读

每条慢查询日志包含以下字段：

1) (integer) 0          # 日志唯一ID
2) (integer) 1735689600 # Unix时间戳
3) (integer) 15023      # 执行耗时（微秒）
4) (string) "GET"       # 命令名称
5) (string) "hotkey_001" # 命令参数（Key名）
6) (string) "127.0.0.1:6379" # 客户端地址
7) (string) "my-connection-id" # 连接ID

如果某个Key频繁出现在慢查询日志中，且耗时集中在同一命令上，说明该Key可能是热点Key或大Key。

2.3 monitor命令：实时抓包与风险

monitor 命令可以实时输出Redis服务器接收到的所有命令，是排查突发热点最直接的手段。但它的性能开销极大——官方文档明确指出，在QPS较高的实例上开启monitor，会导致吞吐量下降50%以上。

2.3.1 使用方式

# 在redis-cli中执行
127.0.0.1:6379> monitor
OK
1735689600.123456 [0 127.0.0.1:6379] "GET" "hotkey_001"
1735689600.123789 [0 127.0.0.1:6379] "SET" "user:1001" "data"
1735689600.124012 [0 127.0.0.1:6379] "GET" "hotkey_001"

2.3.2 配合脚本分析热点

将monitor输出重定向到文件，再用脚本统计Key的访问频率：

# 抓取10秒数据
timeout 10 redis-cli monitor > monitor.log

# 统计Top 10热点Key
cat monitor.log | grep -oP '"[A-Z]+"\s+"([^"]+)"' | \
awk '{print $2}' | sort | uniq -c | sort -rn | head -10
高危警告：monitor命令会消耗Redis单线程的CPU资源。在QPS超过1万的实例上，开启monitor超过30秒可能导致服务不可用。建议仅在低峰期或从节点上使用，且单次抓取不超过10秒。

2.4 redis-cli --hotkeys：基于LFU的离线扫描

Redis 4.0+ 提供了 redis-cli --hotkeys 选项，利用LFU（Least Frequently Used）淘汰策略中的访问频率字段，扫描整个实例并输出访问频率最高的Key。该命令不需要修改配置，但会触发全库scan，对性能有一定影响。

2.4.1 使用前提

需要确保Redis实例的淘汰策略支持LFU：

# 检查当前淘汰策略
CONFIG GET maxmemory-policy

# 如果策略不是allkeys-lfu或volatile-lfu，需要临时修改
CONFIG SET maxmemory-policy allkeys-lfu

2.4.2 执行命令

redis-cli --hotkeys

# 输出示例：
# Scanning the entire keyspace to find hot keys...
# 12345678.90% complete
# 
# -------- summary -------
# 
# Hot keys found: 3
# 
# 1) "hotkey_001" - frequency: 15234
# 2) "hotkey_002" - frequency: 9876
# 3) "hotkey_003" - frequency: 5432

2.4.3 注意事项

  • 性能影响：全库scan会占用CPU和内存，建议在低峰期执行，或使用 --sleep 参数控制扫描间隔。
  • 频率精度：LFU频率是近似值，不是精确计数，但足以识别热点。
  • Key数量限制：默认只输出前10个热点Key，可通过 --count 参数调整。
# 控制扫描间隔（每扫描1000个Key休眠0.1秒）
redis-cli --hotkeys --sleep 0.1

# 输出前20个热点Key
redis-cli --hotkeys --count 20

2.5 第三方监控工具：CacheCloud与RedisLive

内置工具适合临时排查，但生产环境需要持续、可视化的热点监控。CacheCloud和RedisLive是两款成熟的开源方案，下面分别介绍它们的部署与使用。

2.5.1 CacheCloud：美团开源的Redis运维平台

CacheCloud提供应用管理、实例监控、慢查询分析、热点Key统计等一站式功能。其热点发现基于代理层（Twemproxy/Codis）或客户端SDK上报的访问统计。

部署架构：

CacheCloud 热点监控架构 应用客户端 应用客户端 应用客户端 代理层（Twemproxy/Codis） Redis 节点1 Redis 节点2 Redis 节点3 CacheCloud 监控展示 代理层统计每个Key的访问次数，定时上报给CacheCloud，实现热点Key的准实时发现

CacheCloud热点Key配置步骤：

  1. 部署CacheCloud服务：下载源码，配置MySQL数据库，启动Web服务。
  2. 接入Redis实例：在CacheCloud控制台添加应用，填写Redis实例地址和密码。
  3. 开启热点统计：在应用配置中启用“热点Key统计”，设置采样周期（默认10秒）。
  4. 查看热点：进入“监控” -> “热点Key”页面，按访问频率排序查看Top N热点。

2.5.2 RedisLive：轻量级实时监控

RedisLive基于Python开发，通过INFO命令和monitor采样获取指标，提供Web可视化界面。它部署简单，适合中小规模集群。

安装与配置：

# 1. 克隆项目
git clone https://github.com/nickpoorman/redis-live.git
cd redis-live

# 2. 安装依赖
pip install -r requirements.txt

# 3. 配置redis-live.conf
{
    "RedisServers": [
        {
            "server": "127.0.0.1",
            "port": 6379,
            "password": "your_password"
        }
    ],
    "DataStoreType": "sqlite",
    "RedisStatsServer": {
        "server": "127.0.0.1",
        "port": 6380
    }
}

# 4. 启动监控服务
python redis-live.py

热点Key发现机制：RedisLive通过monitor采样（默认每5秒采样1000条命令）统计Key的访问频率，在Web界面以热力图或列表形式展示。由于采用采样而非全量统计，性能开销可控。

对比总结：CacheCloud功能全面，适合大规模集群和团队协作；RedisLive轻量易用，适合个人开发者或小团队快速搭建监控。两者都支持热点Key的准实时发现，但CacheCloud的代理层方案对业务代码无侵入，而RedisLive需要额外的监控Redis实例存储统计数据。

2.6 本章小结

热点Key的发现是Redis性能调优的第一步。本章介绍的四种手段各有适用场景：

  • 慢查询日志用于事后分析，定位耗时操作。
  • monitor命令用于临时应急抓包，但必须严格控制使用时长。
  • redis-cli --hotkeys用于低峰期离线扫描，快速定位高频Key。
  • 第三方监控工具（CacheCloud/RedisLive）用于生产环境持续监控，实现热点Key的准实时发现。
← 上一章 📖 返回目录 下一章 →