热点 Key 探测、隔离与本地缓存

热点 Key 是在短窗口内承受远高于其他 Key 流量的键。它可能耗尽单个 Redis 节点的 CPU、网络或连接，也可能在过期时把流量集中打向数据库；先实时发现，再按数据语义隔离。

Table of contents

热点不能只看全局 QPS

实例每秒 10 万次请求可能分布均匀，也可能 80% 集中在一个商品。监控要保留 Key 维度或可聚合标签，但直接记录所有完整 Key 会增加高基数成本和敏感信息风险。

常见信号可以组合：

1. 在客户端按低比例采样命令、Key 模板和耗时。
2. 在代理或网关按短窗口做 Top-K 近似统计。
3. 使用 Redis 的 LFU 频率、HOTKEYS/诊断能力和节点 CPU 信号。
4. 结合秒杀、直播、热搜等业务事件提前预热。

HotKeyDetector.java查看下载展示精确本地计数；生产高基数流量更适合 Count-Min Sketch、Top-K 等有误差但内存有界的结构。

本地缓存的收益和代价

Caffeine 等进程内缓存可以把极热只读数据挡在 Redis 之前，延迟更低且不占网络。但每个实例都有副本，更新传播和总内存更难控制。

本地缓存应设置短 TTL、最大条目/权重和失效广播。它适合可容忍短暂旧值的小对象，不适合权限撤销、余额等要求严格新鲜的数据。部署 100 个实例缓存 100MB，就是约 10GB 重复数据。

四种治理动作

• 复制只读热点到多节点或本地缓存，并明确陈旧窗口。
• 拆分可累加写热点，例如分桶计数后异步汇总。
• 对单 Key 请求合并、限流和降级，保护回源。
• 修复 BigKey：按业务边界拆分成员，限制单次读取和删除。

验证时要模拟热点突然出现、Key 过期、节点切换和失效消息丢失，观察 Redis、应用和数据库三层指标。

下一步

继续阅读07-10 Redis Stack：搜索、JSON、时序与概率结构，判断专用数据结构是否能简化业务，以及会增加什么边界。