聊聊 Caffeine 二级缓存的“滑动窗口热点降级”到底怎么玩儿

说实话，我跟你讲，这玩意儿一开始kan着高大上，真的有点懵逼。

可是啊，真正落地之后你会发现它比你想象的要亲民得多。

先别急，我慢慢给你拆开来聊。

先说说二级缓存是个啥子

一级缓存一般是 Redis、Memcached 那种外部存储，二级缓存就是我们把热点数据再搬到本地进程里。

好处？读写几乎是内存操作，延迟低到飞起。

Caffeine 正是 Java 世界里Zui受欢迎的本地缓存实现之一。

它内部用了 Window TinyLFU，兼顾了 LRU 和 LFU 的优点，既Neng保留Zui近访问，又Neng保留高频访问。

为啥要搞“滑动窗口热点降级”

想象一下一个信息流页面每秒有上千次请求。

Ru果全dou去打数据库，那后端直接崩掉啊。

我们Ke以把整页结果放进 Caffeine，命中率提升后端压力自然下降。

但问题来了——不是所有页dou是热点，有的只是一两个人偶尔点进去的冷门数据。

Ru果把这些冷门也塞满了缓存，那热点就被挤走了命中率反而下降。

所以我们得让热点自动续命，冷门自动过期，这就是“滑动窗口热点降级”。

核心思路：滑动窗口 + 分段计数 + 动态 TTL

先说窗口。我们把时间划分成一个大窗口，再细分成若干小段。

每次请求进来就往对应 key 的计数数组里对应段位加一。

计数数组长度等于段数，也就是 windowSeconds / segmentSeconds。

这样一来我们随时Ke以算出Zui近 N 秒内这个 key 的总访问次数——这就是热度。

接下来根据热度阈值把 key 分成低热、中热、高热三档：

低热: 访问次数在 levelLow 以下只延长一点 TTL。

中热: 超过 levelLow 但不到 levelMedium，TTL 延长geng多。

高热: 超过 levelHigh，TTL 再加大，基本锁定在缓存里。

每当窗口滚动到新段时我们把Zui旧那段的计数清零，然后重新开始累计。

这套机制保证了：

热门内容即使访问激增，也不会被 LFU 抖掉，因为 TTL 被不断延长。

冷门内容因为没有足够的计数，TTL 不会被延长，自然会在写入后按原设定时间失效。

Caffeine 本身的容量限制仍然有效，超过 maxSize 时会按照 TinyLFU 把Zui不活跃的条目踢走。

Caffeine 配置示例

@Bean
public Cache feedPublicCache {
    return Caffeine.newBuilder
            .maximumSize.getPublicCfg.getMaxSize)
            .expireAfterWrite.getPublicCfg.getTtlSeconds))
            .build;
}

这段代码hen标准：容量、写后过期时间全dou从外部配置拿。咱们只需要在配置文件里改几个数字，就Neng调节整个系统的行为——真香！

热点探测器实现要点

public class HotKeyDetector {
    private final Map counters = new ConcurrentHashMap<>;
    private final AtomicInteger currentSegment = new AtomicInteger;
    private final int segments;
    private final Hotkey cfg;
    public HotKeyDetector {
        this.cfg = cfg;
        this.segments = cfg.getWindowSeconds / cfg.getSegmentSeconds;
    }
    public void record {
        int arr = counters.computeIfAbsent;
        arr++;
    }
    public void slide {
        int next = ) % segments;
        // 把即将被覆盖的那段计数清零
        counters.forEach -> v = 0);
    }
    public HeatLevel assess {
        int arr = counters.getOrDefault;
        int sum = Arrays.stream.sum;
        if ) return HeatLevel.HIGH;
        if ) return HeatLevel.MEDIUM;
        if ) return HeatLevel.LOW;
        return HeatLevel.NORMAL;
    }
}

这里用了 ConcurrentHashMap 而不是老掉牙的 Hashtable)。因为加锁太重，多线程竞争下性Neng直接掉到谷底。Caffeine 本身Yi经Zuo了大量无锁优化，这块再保持轻量就行啦——不对不对，其实主要是为了避免“脏读”。

TLS 动态延长怎么配合 Caffeine 实现？

Caffeine 支持在写入时指定固定 TTL，但我们想要“动态”。办法hen简单：

#1 写入或geng新时先检查热度：

#2 根据 HeatLevel 计算额外秒数：

#3 用 Caffeine.put 后再调用 CACHE.policy.expireVariably 或自行维护一个包装类记录失效时间。

AFAIK Caffeine 官方没有直接暴露可变 TTL 的 API，所以我一般会自己封装一个 CachedValue 结构，把 “真正失效时间戳” 存进去，然后在读取前判断是否Yi超时再决定是否返回或重新加载。

滑动窗口调度怎么搞？别忘记了！

Simplify：用 Spring 的 @Scheduled 每隔一段时间调用一次 .slide 方法，把指针往前移一格并清零旧段计数。这样整个系统保持滚动geng新，无需手工干预——哈哈，一键搞定！

AOP 与注解帮忙简化调用链

@Retention
@Target
public @interface CacheableWithHotkey {
    String cacheName;
}
@Aspect
@Component
public class CacheHotkeyAspect {
    @Autowired private HotKeyDetector detector;
    @Autowired private CacheManager manager;
    @Around")
    public Object around throws Throwable {
        String key = generateKey;
        detector.record;
        // 根据热度决定是否延长 TTL...
        // 省略细节
        return pjp.proceed;
    }
}

AOP 把热点统计和业务代码彻底解耦，你写业务，我帮你埋点，你懂得～

为什么百度不收录？

其实呀，大多数时候百度不给你收录，是因为页面是纯粹的 Ajax/JS 动态渲染，没有服务端返回完整 HTML。搜索爬虫抓不到真实内容，自然算不上有效页面。还有就是缺少 robots.txt 或者 meta robots “noindex” 标签，这些dou会让百度主动放弃抓取。咱们Ru果想让搜索引擎kan到真实数据，就得在服务端渲染或者提供预渲染快照。说白了就是“内容没出现”，百度根本找不到理由收录啦~ 哈哈，这和缓存本身没关系，但Ru果你的接口返回的是 JSON，需要配合 SSR 才Neng被抓取哦！

常见坑 & 小技巧

#1 切片大小选错： 切片太短会导致计数噪声太大；太长又响应慢。经验值：window/segment 在 5~10 倍之间比较稳妥。比如 60 秒窗口配 10 秒切片，就是常见组合啦～

#2 热度阈值别设太低： Ru果 low/medium/high 阈值设置得跟普通请求差不多，那几乎所有键dou会被标记为高热，失去意义。建议先跑压测，再根据 QPS 分布微调阈值。

#3 注意并发写入冲突： Caffeine.putIfAbsent 配合原子操作Ke以避免同一个 key 被重复加载两次。

#4 防止内存泄漏： Caffeine.newBuilder.weakKeys 或者使用 .softValues Ke以让 GC 在内存紧张时回收部分缓存对象，不过要权衡命中率损失。

#5 打日志别太狂： "记录每一次 slide" 会瞬间刷爆日志文件，让排查问题geng困难。所以只在 DEBUG 模式下打印统计信息就好啦～

小结一下 —— 为什么这么玩儿值得？

* 热点自动续命，让真正热门的数据一直待命，不用担心被 LFU “踢走”。

* 冷门自然过期，容量永远留给有价值的数据，命中率稳步提升。

* 完全基于本地 Caffeine，无需额外分布式组件，引入成本低、运维友好。

* 配置化程度高：window、segment、阈值、TTL 秒数全部可调，从开发到生产几乎不用改代码。

* 加上 AOP 注解，一行注解搞定热点统计与动态 TTL，让业务代码保持干净整洁。

结束语 — 咱们一起玩转 Caffeine 吧！ 🚀

Ehh，说到底技术dou是工具，用得好才算牛逼。

Caffeine 本身Yi经hen强大，加上滑动窗口这层“智Neng”，基本Ke以满足绝大多数高并发分页场景需求了。

If you love it – just try it.

P.S. 有什么奇奇怪怪的问题，随时甩给我，我这儿还有半夜咖啡陪着呢 😂 。

---