登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  数据库 >  Redis

Redis 8.6 HOTKEYS 怎么定位热键:采样窗口、CPU/网络指标与集群槽位验收

来源:17golang原创

时间:2026-08-17 09:45:18 456浏览 收藏

缓存接口的平均耗时没变,P99 却突然抬头,先别急着把整个 Redis 集群扩容。很多时候只有一个商品详情键、配置键或租户热点键被反复访问,单个分片的 CPU 和网络已经被它顶住了。Redis 8.6 提供的 HOTKEYS 可以在限定采样窗口内按 CPU 或网络占用找出这类键,再决定是拆分、加本地缓存,还是调整访问路径。

要点速览
  • HOTKEYS START 只负责开启一段采样,不会直接返回热键结果。
  • CPU 和 NET 是两套指标,排查计算瓶颈与大值传输时不要混为一谈。
  • COUNT、DURATION、SAMPLE 决定结果的观察窗口,数值越大不一定越准确。
  • 集群排查应先用 SLOTS 缩小范围,再结合客户端、分片和业务访问量复核,不能把榜首键直接当成故障根因。

先把“Redis 变慢”拆成一个可观察的问题

假设订单详情接口在 10 秒内出现一批慢请求,应用监控只告诉你 Redis P99 从 8 毫秒升到 35 毫秒。这个数字说明请求变慢,却没有说明是哪个 key、哪个分片、哪种资源在消耗时间。

Redis 8.6 的 HOTKEYS 适合补上这一步证据:让服务器在短窗口内统计访问频繁键的 CPU 或网络占比,然后用结果回到业务日志核对。它不是永久排行榜,也不是对每次命令做完整审计,因此先定义观察窗口,再读结果更重要。

Redis 8.6 HOTKEYS 从请求进入采样窗口到按 CPU 或网络指标返回热键结果的路径

最小用法:START、GET、STOP 三步完成一次采样

在 Redis 8.6 或更高版本上,可以先用 HELP 确认服务器支持的子命令:

redis-cli HOTKEYS HELP

确认版本后,开启一次 30 秒、采样比例为 10% 的 CPU 观察。COUNT 20 表示最多保留前 20 个结果:

redis-cli HOTKEYS START METRICS 20 CPU COUNT 20 DURATION 30 SAMPLE 10
sleep 30
redis-cli HOTKEYS GET
redis-cli HOTKEYS STOP

START 成功只代表采样已开启;结果要等观察窗口结束后通过 GET 读取。最后调用 STOP 关闭追踪,避免把一次临时排查误留成长期开销。

CPU 和 NET 要按症状选择

CPU 指标适合确认某些键的访问路径正在消耗服务器计算资源,例如单个大 Hash 频繁读取、复杂数据结构被高频操作,或热点集中到一个槽位。NET 指标更适合发现返回值过大、同一个键被大量拉取等网络压力。

现象优先指标复核证据不要直接下的结论
单分片 CPU 抬高CPU命令延迟、分片 CPU、业务访问量榜首键一定是根因
出口流量突然增加NET响应大小、客户端读取频率、网络监控所有大值都需要删除
只有一个槽位异常CPU 或 NET槽位、客户端和 key 设计马上迁移槽位

如果一次只填写 CPU,结果就围绕 CPU 维度统计;要看网络维度,应另开一次采样。把两种指标混在同一次实验里,会让排查结果失去明确的解释口径。

COUNT、DURATION、SAMPLE 怎么调才不误导

COUNT 是结果数量上限,DURATION 是观察时长,SAMPLE 是采样比例。生产排障可以从短窗口开始,先降低对在线实例的影响:

redis-cli HOTKEYS START METRICS 10 NET COUNT 10 DURATION 15 SAMPLE 5
sleep 15
redis-cli HOTKEYS GET
redis-cli HOTKEYS STOP

15 秒里没有抓到稳定热点,不等于系统没有热点,可能只是流量周期还没覆盖。可以在低峰和高峰各做一次同长度采样,再比对是否出现相同的 key。相反,单纯把窗口拉到几分钟,也可能把短时突发平均掉。

结果出来后至少核对三件事:热键是否和慢请求时间重合,key 对应的值大小是否异常,榜首结果是否只集中在一个分片。没有这三步,HOTKEYS 只能给出线索,不能替代容量判断。

Redis 集群使用 HOTKEYS 的 SLOTS 范围缩小热点分片并结合客户端日志决定治理动作

集群环境先锁槽位,再决定治理动作

Redis 官方文档支持在 START 时指定一个或多个槽位。已知问题集中在 10923 槽附近时,可以把采样范围缩小:

redis-cli -h redis-node-2 HOTKEYS START METRICS 20 CPU COUNT 20 DURATION 30 SAMPLE 10 SLOTS 1 10923
sleep 30
redis-cli -h redis-node-2 HOTKEYS GET
redis-cli -h redis-node-2 HOTKEYS STOP

SLOTS 是缩小观察范围,不是把一个 key 从集群迁走。即使某个 key 排在前面,也要先查它的 hash tag、所属分片、访问客户端和业务流量。如果热点是一个本来就应该高频读取的小值,本地缓存或请求合并可能比迁移槽位更合适;如果是大值反复返回,应该先检查字段裁剪和响应缓存。

常见误区与上线前验收

  • 把 START 的成功回复当成热键结果:真正的排名要通过观察窗口后的 GET 获取。
  • 没有记录 Redis 版本就照抄命令:HOTKEYS 是 Redis 8.6 引入的能力,旧实例应先做兼容检查。
  • 只看单次榜首就改 key 结构:至少在两个相同窗口复测,并和应用慢日志、分片资源及响应大小交叉核对。
  • 忘记停止追踪:一次排查结束后执行 HOTKEYS STOP,并把开始时间、持续时间、指标和槽位范围写入故障记录。

常见问题

HOTKEYS 会持续记录所有访问过的 key 吗?

不会。它按 START 设置的窗口和采样规则临时追踪,结果应理解为一段时间内的热点线索,而不是永久访问明细。

CPU 热键和网络热键可以同时查询吗?

更建议分两次采样。一次实验只保留一个主要指标,结果更容易和 CPU、带宽或响应大小对应。

Redis 7.x 能直接使用 HOTKEYS 吗?

不能按 Redis 8.6 的命令语义直接假设可用。先用目标实例的 COMMAND INFO HOTKEYS 或 HOTKEYS HELP 检查,再决定是否采用客户端兼容方案。

发现热键后应该马上删除或迁移吗?

不应该。先确认它是访问频繁、值过大、槽位倾斜还是业务突发,再选择本地缓存、请求合并、拆分值或调整 key 设计。

HOTKEYS 的价值在于把“某个 Redis 分片可能被热点拖慢”变成可复查的 key、指标和时间窗口。把一次采样和慢日志、槽位、响应大小放在同一份记录里,才能判断治理动作是否真的降低了 P99,而不是只换了一个看起来更高的榜单。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>