前言
在高并发系统中，热点数据如同交通高峰期的拥堵路段------少数几条路承载了绝大多数车流。如果这些热点数据不能在缓存中稳定停留，就会引发缓存击穿、雪崩，甚至拖垮数据库。
传统的固定TTL缓存策略僵化死板，无法适应流量的实时变化；而LRU/LFU等淘汰算法又难以在分布式环境中共享热度信息。那么，有没有一种轻量、实时、自适应的方案，能够让我们自主探测热点，并动态优化缓存行为？
本文将带你深入滑动窗口HotKey探测 的设计思路，从零讲解每一步为什么这么设计，让你能够理解并完成属于自己的热键探测机制。
一、总体设计思路
热键探测的核心目标很简单：实时识别访问频繁的Key，并给予它们更长的缓存生存时间。为了实现这一目标，我们需要解决三个关键问题：
- 如何统计热度？ 需要一个高效、准确的热度度量方法，能够反映最近一段时间内的访问频率。
- 如何动态调整？ 热度高的Key应当获得更长的TTL，热度下降后应自然恢复。
- 如何与现有缓存协同？ 探测机制不能侵入业务核心逻辑，要易于集成。
围绕这些问题，我们选择滑动窗口计数 作为热度的统计模型，配合分级TTL扩展实现动态调整。整体设计遵循以下原则：
- 轻量高效：纯内存计算，无网络开销，不影响业务性能。
- 实时自适：热度变化能快速反映，热点"上得快、下得也快"。
- 易于集成：只需在业务代码中埋点记录访问，即可获得热度并延长TTL。
二、为什么选择滑动窗口？
在讨论实现之前，先来比较几种常见的热度统计模型：
| 模型 | 原理 | 优点 | 缺点 |
|---|---|---|---|
| 固定窗口 | 每隔固定时间（如1分钟）统计一次总访问量 | 实现简单 | 无法反映实时热点，统计周期内数据是滞后的 |
| 滑动窗口 | 将时间窗口划分为多个片段，片段内独立计数，窗口整体滑动 | 实时、内存可控、自动衰减 | 需要处理窗口轮转的并发 |
滑动窗口的实时性 和自动衰减 特性完美契合热点探测的需求：热度由最近一段时间内的访问量决定，旧数据自然移出窗口，无需手动降级。同时，它的内存占用是固定的（每个Key仅需一个定长数组），计算开销极低（数组求和）。因此，我们选择滑动窗口作为核心统计模型。
三、滑动窗口的详细设计
3.1 数据结构设计
滑动窗口的本质是维护一个固定长度的时间窗口，将其划分为若干等长的片段（Segment），每个片段独立计数。
为什么用数组？
我们需要为每个Key存储每个片段的计数值，数组是最紧凑的数据结构。假设窗口总长度为60秒，划分为6个片段（每段10秒），那么每个Key只需要一个长度为6的int数组，占用24字节（Java中int[6]对象头+数据）。如果Key数量为100万，总内存约24MB，完全可接受。
并发访问如何处理？
在高并发下，多个线程可能同时更新同一个Key的计数。如果使用原子类（如AtomicIntegerArray），可以保证精确计数，但开销略大。实际上，热度统计允许少量误差（比如计数少了几次），因此可以直接使用普通数组配合ConcurrentHashMap的原子性保证数组初始化，然后通过arr[index]++非原子递增。在极端竞争下可能丢失几次计数，但总体误差在可接受范围内，且换来了极高的性能。
代码示意（伪代码）：
class HotKeyDetector {
ConcurrentHashMap<String, int[]> counters;
int segments;
AtomicInteger currentSegment = new AtomicInteger(0);
void record(String key) {
int[] arr = counters.computeIfAbsent(key, k -> new int[segments]);
int idx = currentSegment.get();
arr[idx]++; // 非原子递增，允许少量误差
}
}3.2 窗口滑动机制
窗口如何滑动？需要一个定时任务，周期性地将当前活跃片段下标向前推进，并清空新下标对应的计数（因为新片段开始计数）。
为什么用定时任务？
因为窗口滑动是基于时间的，自然需要定时器驱动。频率由片段长度决定，比如每10秒轮转一次。
清空计数的时机：
在轮转时，我们将所有Key的对应下标置零。这里有一个潜在的性能问题：如果Key数量极大，遍历所有Key清零可能会造成短暂的停顿。但实际上，内存遍历的速度极快（百万级Key只需几十毫秒），且定时任务周期较长（秒级），完全可以接受。如果仍担心性能，可以采用"惰性清零"策略：在record时，检查当前下标是否属于新窗口，若是则先清零再加一，但这样需要记录每个Key的最后更新时间，增加了复杂度，收益有限。
并发安全考虑：
轮转线程在清空某个Key的arr[next]时，可能恰好有业务线程正在对同一个下标执行arr[idx]++。这会导致两种后果：
- 业务线程的递增丢失（计数被清零后丢失）。
- 轮转清零后，业务线程又递增了新的值。
这种情况概率很低，且即使发生，也只是当前片段的计数略有偏差，不影响整体热度趋势。如果追求精确，可以使用AtomicIntegerArray配合CAS，但大多数业务场景下，允许少量误差更划算。
轮转代码示意：
@Scheduled(fixedDelay = segmentSeconds * 1000)
void rotate() {
int next = (currentSegment.get() + 1) % segments;
currentSegment.set(next);
for (int[] arr : counters.values()) {
arr[next] = 0; // 直接赋值清零
}
}3.3 热度计算
热度就是当前窗口内所有片段计数之和。遍历数组求和即可。
为什么直接求和？
因为每个片段的权重相同（都是窗口内的一部分），无需加权。如果希望更侧重近期数据，可以为不同片段设置权重，但会增加复杂度。一般情况下，直接求和已经能很好地反映热度趋势。
代码：
int heat(String key) {
int[] arr = counters.get(key);
if (arr == null) return 0;
int sum = 0;
for (int count : arr) sum += count;
return sum;
}3.4 动态TTL扩展
有了热度值，接下来就是如何用它指导TTL调整。通常采用分级策略：设定几个热度阈值，每个阈值对应一个TTL倍数。
为什么分级？
因为热点有程度之分。非常热的内容可以享受更长TTL，而只是稍热的可以适当延长但不宜过长。分级策略简单直观，易于调参。
如何设定阈值？
阈值需要根据业务流量统计来定。可以先观察系统正常时的QPS分布，比如平均每个Key每秒访问1次，窗口60秒则热度60；突发热点可能达到每秒100次，热度6000。那么可以设定"热"阈值1000，"温"阈值100。这些值可以通过配置中心动态调整，以适应业务变化。
TTL上限考虑：
延长TTL不能无限长，否则数据更新后缓存迟迟不失效，导致一致性问题。一般建议最长不超过窗口总时长的2倍。例如窗口60秒，基础TTL 30秒，则最长可延长到120秒。这样既让热点停留更久，又保证了最终一致性。
代码示意：
int ttlForPublic(int baseTtl, String key) {
int h = heat(key);
if (h > 1000) return baseTtl * 4; // 超热
if (h > 100) return baseTtl * 2; // 热
return baseTtl; // 普通
}3.5 与应用集成
要让热键探测发挥作用，需要在业务代码中埋点。当请求访问某个Key时，调用record(key)；在写入缓存时，调用ttlForPublic(baseTtl, key)获取建议TTL，然后设置到Redis等缓存中。
集成要点：
record应在缓存命中或未命中时都调用，因为热度统计基于所有访问，而不仅仅是回源。- 延长TTL的操作应放在每次访问时（或定期），可以检查当前TTL是否小于建议值，若是则更新。这样可以动态适应热度变化。
- 需要配合缓存更新事件（如数据变更）及时淘汰缓存，避免因TTL过长导致数据不一致。
四、方案的优缺点与适用场景
优点
- 实时性高：热度统计以秒级延迟更新，能快速响应突发流量。
- 资源消耗低：纯内存计算，无网络交互，内存占用可控。
- 自动衰减：旧数据自然移出窗口，无需手动降级。
- 实现简单：核心代码不足百行，易于定制和维护。
缺点
- 热度不共享：每个节点独立统计，无法感知全局热点。但对于大多数业务，本地热度已足够指导缓存优化。
- 阈值依赖经验：需要根据业务数据调整阈值和倍数，初期可能需要观察。
- 计数误差：非原子递增可能丢失极少量计数，但不影响整体趋势。
适用场景
- Feed流、商品详情页、新闻资讯等读多写少的场景。
- 缓存层为Redis或本地缓存，需要动态调整TTL。
- 希望以极低成本提升缓存命中率的系统。
五、总结
滑动窗口热键探测是一种轻量、高效的热点识别方案。本文从设计思路出发，讲解了为什么选择滑动窗口、如何设计数据结构、如何处理并发、如何动态调整TTL，以及如何与应用集成。每一步的决策都基于性能、实时性和简洁性的权衡，让读者能够理解背后的原理，从而独立开发出适合自己业务的热键探测机制。
在实际落地时，你可以根据业务流量调整窗口大小、片段长度、阈值和TTL倍数，甚至结合事件驱动机制保证数据一致性。最重要的是，这套机制能够让你对缓存行为有更精细的控制，让热点数据"热得持久，冷得自然" ，从而有效提升系统稳定性与响应速度。