热点 Key 探测与加长缓存 TTL 实战适用读多写少的详情类接口商品、内容、图书等关键词热点 Key · 滑动窗口 · Cache Aside · TTL 抖动 · 缓存击穿写在前面详情接口往往符合二八分布少数 ID 被反复访问绝大多数很少被点开。若所有缓存共用同一档物理 TTL例如 30 分钟热点 Key 会更频繁地「到期 → miss → 打库」在高并发下放大成缓存击穿。常见解法包括互斥重建、逻辑过期。还有一条更轻的路径先识别谁是热点再给热点更长的 TTL从概率上降低它刚好过期的次数。本文讲清问题、探测思路、加长 TTL 的写路径以及和其它手段怎么组合。一、问题统一 TTL 对热点不公平1.1 缓存击穿热点 detail:{id} 物理 TTL 到期 ↓ 同一时刻大量请求 miss ↓ 全部打到数据库连接池可能被打满手段思路代价互斥锁重建miss 时只有一人查库过期瞬间首批请求变慢逻辑过期先返回旧值异步刷新短暂脏读热点加长 TTL本文热 Key 更晚过期热数据可能更久偏旧靠写后删收敛写路径若在更新 / 下架时主动删除缓存加长 TTL 主要服务读多写少写后仍以删除为准而不是无限脏读。1.2 为什么还要 TTL 抖动即使同一资源 TTL 都是 7200 秒若大量不同 Key 在同一秒写入仍可能在同一秒集体过期形成缓存雪崩。常见写法实际 TTL base random(0, jitter) 普通1800 [0, 300) 热点7200 [0, 600)二、方案总览读详情 →可选布隆 / 空值缓存防穿透 → Cache Aside本地缓存 / Redis / DB → 每次成功返回recordAccess(id) → 回源写入 Redis 时resolveTtl(id) ├─ isHot(id) true → 长 TTL 抖动 └─ 否则 → 普通 TTL 抖动要点探测与加长 TTL解耦读路径只计数写缓存时再问「是不是热点」单机探测实现简单多实例要全局热度需上 Redis 计数等与逻辑过期互补加长 TTL 降低过期频率过期瞬间仍可用互斥 / 逻辑过期止血三、热点探测分桶近似滑动窗口3.1 为什么不用一个累加计数器若每个 ID 只维护一个累计次数无法表达「最近 60 秒」曾经火过的冷数据会一直被当成热点需要滑动窗口只统计最近一段时间的访问。3.2 分桶近似示例参数参数示例含义windowSeconds60窗口长度bucketSeconds10每个时间桶宽度threshold50窗口内次数 ≥ 此值视为热点maxTrackedKeys5000最多跟踪多少个 ID时间轴切成宽度 10 秒的桶| b0 | b1 | b2 | b3 | b4 | b5 | ← 约 6 个桶覆盖 60 秒 ↑ 丢掉过期桶只对当前窗口内桶求和示意代码// 记录访问当前桶 1并删掉窗口外的旧桶longcurrentBucketnowSec/bucketSeconds;longminBucketcurrentBucket-(windowSeconds/bucketSeconds)1;buckets.merge(currentBucket,1L,Long::sum);buckets.entrySet().removeIf(e-e.getKey()minBucket);// 判定热点窗口内求和 ≥ thresholdbooleanhotsumInWindow(id)threshold;这是近似滑动窗口桶内不区分先后边界误差约一个bucketSeconds实现简单、开销可控。3.3 用本地 LRU / Caffeine 包住计数器CacheLong,ConcurrentHashMapLong,LongcountersCaffeine.newBuilder().maximumSize(maxTrackedKeys).expireAfterAccess(Duration.ofSeconds(windowSeconds*2)).build();作用防止恶意扫描海量 ID 把内存撑爆冷 Key 自动淘汰3.4 在哪里计数建议在「用户真正看到详情」的成功路径计数缓存命中返回 → recordAccess DB 回源成功返回 → recordAccess 直接 404 / 鉴权失败 / 异常 → 不计数这样热点反映真实读流量而不是穿透或刷接口噪声。四、加长 TTL写缓存时分流privateDurationresolveTtl(Longid){if(isHot(id)){returnttlWithJitter(hotTtlSeconds,hotJitterSeconds);// 例如 7200 [0, 600)}returnttlWithJitter(normalTtlSeconds,normalJitterSeconds);// 例如 1800 [0, 300)}privateDurationttlWithJitter(longbaseSeconds,longjitterSeconds){longbaseMath.max(1,baseSeconds);longjitterMath.max(0,jitterSeconds);longttlbase(jitter0?ThreadLocalRandom.current().nextLong(0,jitter):0);returnDuration.ofSeconds(ttl);}4.1 时序直觉冷数据 写入 → 约 30min 过期 → 再 miss 回源 热数据窗口内 ≥ 阈值 再次 put 时识别为热点 写入 → 约 2h 过期 → miss 频率下降 期间若发生更新 → 主动删缓存不靠等 TTL4.2 为什么常常是「下次写入」才变长第一次打爆款时计数器可能还没到阈值仍用普通 TTL持续访问后isHottrue下一次回源或刷新写入才用长 TTL。这样可避免偶发尖刺把冷 Key 立刻按热点策略处理。扩展判定热点后在缓存命中时主动EXPIRE续命按业务需要可选。五、推荐配置与自测cache:hot-key-enabled:truehot-window-seconds:60hot-bucket-seconds:10hot-threshold:50hot-detail-ttl-seconds:7200hot-detail-ttl-jitter-seconds:600detail-ttl-seconds:1800detail-ttl-jitter-seconds:300自测思路把hot-threshold临时改小方便压测对同一 ID 连续请求超过阈值清掉该 Key 或等 miss 后再写入观察 RedisTTL是否进入「长 TTL」量级六、局限与组合拳局限说明可选升级本机热度多实例流量不均时判断不一致RedisINCR 窗口、中心统计近似窗口桶边界有误差更细的桶或精确滑动窗口只加长 TTL不解决「已过期瞬间」的并发击穿再叠互斥锁或逻辑过期热数据更久读多写少依赖写后删除强一致字段不要只靠长 TTL和其它手段怎么叠穿透 → 布隆过滤器 / 空值短 TTL 雪崩 → TTL 抖动 击穿 → 热点长 TTL降频 互斥 / 逻辑过期过期瞬间 多级 → 本地缓存 Redis七、面试口述约 1 分钟详情接口有明显热点。统一短 TTL 时爆款 Key 过期更频繁容易打穿数据库。读路径用本机分桶滑动窗口统计最近一分钟访问次数超过阈值就认定热点写 Redis 时热点用更长的 TTL并加随机抖动防雪崩。更新下架仍走删缓存。多实例热度不共享时可改成 Redis 计数对可接受短暂脏读的超级热点还可以再上逻辑过期。八、小结热点加长 TTL 解决的是「热 Key 过期太勤」带来的击穿压力实现成本低适合挂在现有 Cache Aside 上。它替代不了布隆穿透、也替代不了逻辑过期 / 互斥过期瞬间但作为第一层优化往往性价比很高。