面试官:你怎么发现 Redis 热 Key 的?

📅 2026/8/19 16:15:59
面试官:你怎么发现 Redis 热 Key 的?
面试官微微一笑端起水杯用一种“终于问到这道题了”的表情看着你“你们生产环境 Redis 遇到过热 Key 吗怎么发现的”你心里一紧。这题说简单也简单说难也难。要是只说“我们采样 TopK”大概率会被追问到哑口无言。今天咱们就把这道题彻底讲透让你下次面试能从容应对顺便还能展示一下“工程经验”。先搞清楚热 Key 到底热在哪很多人一听到“热 Key”第一反应就是“QPS 高的 Key”。但在真实生产环境里热 Key 其实分三种访问热点某个 Key 被疯狂 GET比如明星出轨时的微博热搜 KeyCPU 热点命令本身特别重比如SMEMBERS一个百万级的 Set网络热点Key 的 Value 特别大每次传输几十 MB网卡先扛不住一个GET请求 5 万 QPS 和一个SMEMBERS请求 2000 QPS后者对 Redis 的压力可能更大。所以“热”不只是看次数还得看“重量”。错误示范直接在 Redis 里统计有人可能会说“我用MONITOR命令看看。”面试官眼睛一亮“然后呢”然后……就没有然后了。因为MONITOR会输出所有请求在高 QPS 下本身就是灾难——它会把 Redis 拖得更慢而且日志量大到你根本处理不过来。至于--hotkeys它依赖 LFU 策略生产环境不一定开启而且只能告诉你“哪些 Key 访问频繁”拿不到上下文信息。正确姿势在 Client 层采样 TopK正确的方案是在 Redis Client 层做采样只统计一小部分请求然后在内存里用 TopK 算法保留最热的那些 Key。为什么一定要采样假设 Redis 有 100 万 QPS如果每次都把 Key 记下来你的 Go 服务会先被自己的监控逻辑干趴下。更糟的是Redis Key 可能有几千万个全量统计会导致内存爆炸。所以100 万 QPS → 采样 1% → 1 万 QPS → TopK 统计。这样就轻量多了。具体怎么实现第一步Client 中间件拦截请求以go-redis为例在外面包一层typeRedisMonitorstruct{client*redis.Client topK*TopK}func(m*RedisMonitor)Get(ctx context.Context,keystring)(string,error){result,err:m.client.Get(ctx,key).Result()// 只对部分请求采样ifshouldSample(){m.topK.Add(key)}returnresult,err}注意统计逻辑不能阻塞业务请求。如果统计系统卡住了不能把正常 Redis 请求也拖下水。第二步采样率怎么定最简单的采样实现funcshouldSample()bool{returnrand.Intn(1000)0// 0.1% 采样}对于 100 万 QPS0.1% 采样后大约是 1000 QPS 进入统计压力小很多。更高级的做法是动态采样正常情况用低采样率发现异常后提高采样率精准定位。第三步TopK 算法而不是全量 Map如果采样后用map[string]int64统计仍然可能保存几十万个 Key。我们其实只需要 Top 100。这里可以用Space-Saving 算法。它的核心思想很简单只维护一个固定大小的候选集合比如 100 个。新 Key 来了如果已经在集合里就加一如果不在就看看它有没有资格挤掉当前集合里最小的那个。举个例子假设我们只维护 Top 3当前候选A:100B:80C:70来了 D:75 → 大于最小项 C:70 → 淘汰 C加入 D来了 E:60 → 小于最小项 D:75 → 忽略这样就能用很小的内存流式地算出 Top 100不需要保存全部 Key也不需要最后排序。实际实现里可以用小顶堆快速找到最小值复杂度是 O(log K)K 就是 Top 100 里的 100。如何避免 Prometheus 被撑爆千万别把 Key 直接作为 Prometheus Label如果 Key 有几十万个Prometheus 会直接 OOM。正确做法是Prometheus 只记录整体指标热 Key 数量、估算总 QPS真正的 Top 100 Key 记录到日志、Elasticsearch 或 ClickHouse在 Dashboard 上展示即可最后的杀手锏不仅仅看 Key还要看上下文在 Client 层还有一个额外的好处你能拿到业务上下文。比如你不仅能看到product:10001 → 50K QPS还能知道是哪个服务、哪个接口在访问它/api/product/detail → product:10001 → 50K QPS这样就能从“发现热 Key”变成“定位问题接口”对线上治理价值更大。面试官你说完了你点头。面试官沉思片刻“那你们当时有没有遇到过采样率太低导致漏掉热 Key 的情况”你可以自信地回答“所以我们用了动态采样并且把采样率作为一个配置项。正常情况下 0.1%发现异常后可以在线调整。另外热 Key 的定义本身也是多维度的不只看 QPS还会结合命令复杂度和响应大小综合判断。”面试官放下水杯点了点头。