3. 热点数据识别方法

热点数据治理的第一步不是“加缓存”，而是“找到谁在热”。如果只凭经验猜测，很容易把冷 Key 当成热点扩容，却把真正的高频 Key 留在单节点上持续打爆。本节围绕四条互补的识别通道展开：业务埋点、Redis 监控、代理层日志与慢查询，并给出可落地的识别指标与采样方案。

一、四条识别通道各自能回答什么问题

不同通道的观测位置不同，能看到的“热度”也不同。业务埋点站在调用方，能回答“哪个业务动作触发了访问”；Redis 监控站在实例内部，能回答“哪个 Key 的 QPS、带宽、CPU 消耗最高”；代理层日志站在客户端与 Redis 之间，能回答“哪个 Key 被哪些客户端、以什么命令、在什么时间访问”；慢查询则回答“哪些命令执行时间长、可能阻塞其他请求”。四者不是替代关系，而是交叉验证关系。

二、业务埋点：从调用方定位“谁在热”

业务埋点是最贴近业务语义的通道。做法是在缓存客户端封装层统一拦截，对每次 Redis 调用记录：业务场景标识、Key 前缀、完整 Key 的哈希、命令类型、调用耗时、调用结果（命中/未命中/异常）。这里不建议直接记录完整 Key，因为 Key 中常含用户 ID、订单号等敏感信息，且基数极大；推荐记录“Key 前缀 + Key 的哈希值”，既能聚合统计，又能避免泄露。

埋点指标建议至少包含：调用次数（按前缀聚合，用于发现高频前缀）、未命中率（用于识别穿透风险）、P99 耗时（用于识别慢调用）、来源服务（用于定位是哪个上游在打）。采样上，高频 Key 本身调用量大，1% 抽样即可稳定估算；但对未命中和异常应全量记录，因为它们是治理的重点信号。

三、Redis 监控：从实例内部看资源消耗

Redis 自身提供了多种观测手段。INFO commandstats 可以按命令类型统计调用次数与耗时，但它不区分具体 Key；MONITOR 能打印所有命令，但生产环境高 QPS 下开销极大，只能短时间采样使用；SLOWLOG 记录超过阈值的命令，适合定位慢操作；redis-cli --hotkeys 基于 LFU 淘汰策略统计访问频率，能直接给出热点 Key 排名，但要求实例使用 allkeys-lfu 或 volatile-lfu 策略。

监控指标应重点关注：单实例 QPS 是否显著高于集群均值、带宽是否被少数 Key 拉高、CPU 是否集中在某几个分片、Key 空间是否存在明显倾斜。判断依据是：如果某个分片的 QPS 或带宽持续高于其他分片 3 倍以上，且该分片上存在少数 Key 的访问占比超过 20%，即可判定为热点倾斜。

四、代理层日志：还原访问路径与客户端来源

代理层（如 Twemproxy、Codis、Redis Cluster Proxy 或自研代理）位于客户端与 Redis 之间，能记录完整的请求上下文。典型日志字段包括：时间戳、客户端 IP、命令、Key、响应字节数、耗时。通过代理层日志可以回答：某个热点 Key 是被哪个服务、哪个 IP、在什么时间集中访问的；是读多还是写多；响应体是否异常大。

代理层日志的采样方案建议采用“分层采样”：对普通请求按 1% 抽样，对耗时超过 10ms 的请求全量记录，对响应字节数超过 10KB 的请求全量记录。这样既能控制日志量，又能保证慢请求和大 Value 不丢失。聚合时按“Key 前缀 + 客户端 IP”分组，可以快速定位是单客户端热点还是全局热点。

五、慢查询：定位阻塞型热点

慢查询与高频访问是两个不同维度。一个 Key 可能访问频率不高，但单次操作耗时很长（如对大 Hash 执行 HGETALL、对大 List 执行 LRANGE 全量、对大 Set 执行 SMEMBERS），同样会阻塞 Redis 单线程。慢查询的识别方式是设置 slowlog-log-slower-than 阈值（例如 10000 微秒，即 10ms），并用 SLOWLOG GET 100 查看最近 100 条慢命令。

慢查询日志中要重点观察：命令类型、Key 名、参数规模、执行耗时。如果发现某类命令反复出现且 Key 名集中，说明该 Key 的数据结构或访问方式需要优化，例如把大 Hash 拆分为多个小 Hash，或用 HSCAN 替代 HGETALL。

六、识别指标与采样方案汇总

综合四条通道，可以形成一套可执行的热点识别流程：先用 Redis 监控发现分片倾斜，再用代理层日志定位具体 Key 和客户端，接着用业务埋点确认业务来源，最后用慢查询判断是否存在阻塞型操作。四者交叉验证后，才能准确判定热点 Key 并制定针对性的治理策略。