刷题系统的缓存预热策略热点题目预加载与冷启动优化一、新版本部署后用户总是抱怨前十秒特别慢这是一条来自运维群的消息每次发版后几乎都会出现。问题的根因很清楚新版本上线时应用内的所有本地缓存都是空的。用户的头几批判题请求大量落到下游模型服务导致响应延迟飙升。等缓存逐渐被用户流量热起来之后延迟才回落到正常水平。这个现象就叫冷启动问题。缓存的意义是减少对慢速数据源的访问但缓存本身也需要被预热——在系统正式对外服务之前提前把热点数据加载到缓存中让系统一启动就处于热状态。这对于刷题系统这类以读取为主的场景尤其重要题目数据、历史判题结果、用户能力画像——这些都是高读低频写的典型数据。flowchart TD A[服务启动] -- B[缓存预热阶段] B -- C[从预热配置中读取热点题目 ID 列表] C -- D[分批加载数据到本地缓存] D -- E{预热完成检查} E --|未完成| F[继续加载下一批次] F -- D E --|全部完成| G[注册到服务发现] G -- H[开始接收流量] H -- I[运行时缓存惰性加载 定期刷新] subgraph 预热数据来源 J[离线分析过去 7 天访问频次 Top N] -- C K[运营配置手动指定的必加载题目] -- C end subgraph 运行时策略 L[访问频率计数器] -- M[动态热点检测] M -- N[自动提升为热点缓存] N -- I end二、热点题目的识别谁值得提前加载预热的前提是知道哪些数据是热的。热点题目的识别通常有两种方式。离线分析从访问日志中统计过去一段时间比如 7 天内各道题目的被访问频次取出 Top NN 的取值根据缓存容量决定。这个方式相对准确但有一定的滞后性——今天刚上线的新题不在统计数据中自然不会被预热。运营配置手动指定某些必须预热的题目比如本周的周赛题、公司内部的面试真题库。这种方式灵活可控但依赖人工维护题目多了容易遗漏。生产环境中通常是两者结合离线分析给一个基础的预热列表运营配置做补充和修正。预热列表定期如每天凌晨离线更新一次新上线的题由运营手动加入。缓存预热的另一个容易忽略的问题预热过程本身也会对下游产生压力。如果预热的题目有 500 道每道题都需要调用模型获取判题结果那预热阶段的请求量可能相当于正常流量的一小波高峰。解决方案是分批预热每批之间间隔几秒并且控制并发线程数。三、多级缓存的协同与预热策略刷题系统通常采用 L1本地内存 L2Redis 分布式缓存 L3数据库/模型服务的多级缓存架构。每一级的预热策略不同。L1 本地缓存如 Caffeine速度最快但容量最小适合放极热数据。预热时把 Top 100 的热点题解加载到本地。L2 Redis 缓存在本地缓存的下面做一层兜底预热时加载更多的题目数据如 Top 1000。L3 是真正的地面数据源不做预热——它的访问会被 L1 和 L2 大量拦截。/** * 多级缓存预热管理器 * * 设计要点 * 1. 分批加载防止下游压力过大 * 2. L1 和 L2 各取所需数据量不同 * 3. 预热超时保护不能在预热阶段卡死 */ Component public class CacheWarmUpManager { // L1 本地缓存热点数据量少 private final CacheLong, JudgeResult localCache; // L2 Redis 缓存温数据量大 private final RedisTemplateString, Object redisCache; // 下游数据源 private final JudgeDataLoader dataLoader; // 预热批次大小每批加载 50 道题 private static final int BATCH_SIZE 50; // 批次间隔每批之间暂停 500ms避免下游过载 private static final long BATCH_INTERVAL_MS 500; // 预热总超时最长 120 秒 private static final long WARM_UP_TIMEOUT_MS 120_000; /** * 服务启动时执行预热 * * 在 PostConstruct 中调用或在 ApplicationRunner 中触发 */ public void warmUp() { long startTime System.currentTimeMillis(); // 第一步获取预热题目列表 ListLong hotProblemIds getHotProblemIds(); log.info(开始预热共 {} 道热点题目, hotProblemIds.size()); // 第二步分批加载到 L2 Redis 缓存 ListListLong batches partition(hotProblemIds, BATCH_SIZE); for (int i 0; i batches.size(); i) { // 超时保护 if (System.currentTimeMillis() - startTime WARM_UP_TIMEOUT_MS) { log.warn(预热超时已加载 {}/{} 批, i, batches.size()); break; } ListLong batch batches.get(i); // 并发加载当前批次提高效率 loadBatchToRedis(batch); log.info(L2 预热进度: {}/{} 批, i 1, batches.size()); // 批次间暂停给下游喘息空间 if (i batches.size() - 1) { try { Thread.sleep(BATCH_INTERVAL_MS); } catch (InterruptedException e) { Thread.currentThread().interrupt(); break; } } } // 第三步将 Top 100 热点加载到 L1 本地缓存 ListLong topHotProblems hotProblemIds.subList( 0, Math.min(100, hotProblemIds.size())); for (Long problemId : topHotProblems) { String redisKey judge:result: problemId; JudgeResult result (JudgeResult) redisCache.opsForValue() .get(redisKey); if (result ! null) { localCache.put(problemId, result); } } log.info(预热完成L1 加载 {} 条总耗时 {}ms, topHotProblems.size(), System.currentTimeMillis() - startTime); } /** * 并发加载一批题目到 Redis */ private void loadBatchToRedis(ListLong batch) { // 使用线程池并行加载但控制并发数防止下游打满 ExecutorService executor Executors.newFixedThreadPool(10); ListFuture? futures new ArrayList(); for (Long problemId : batch) { futures.add(executor.submit(() - { String redisKey judge:result: problemId; // 只有缓存未命中时才去下游加载 if (Boolean.FALSE.equals(redisCache.hasKey(redisKey))) { JudgeResult result dataLoader.loadResult(problemId); // 设置过期时间1 小时 redisCache.opsForValue() .set(redisKey, result, 1, TimeUnit.HOURS); } })); } // 等待批次内所有任务完成 for (Future? future : futures) { try { future.get(30, TimeUnit.SECONDS); } catch (Exception e) { log.error(预热单题加载失败, e); } } executor.shutdown(); } private ListListLong partition(ListLong list, int size) { /* 省略 */ return null; } private ListLong getHotProblemIds() { /* 离线分析 运营配置 */ return null; } }预热逻辑有一个不太显眼但很重要的设计点Redis 缓存键的存在性检查。redisCache.hasKey(redisKey)这一步的作用是防止重复加载——如果 Redis 中已经有这道题的数据可能是上次运行的缓存还没过期就不再触发下游请求。如果跳过这一步每次重启预热都会重新请求下游造成无谓的开销。四、预热的边际成本与过预热的陷阱预热虽然能解决冷启动问题但也要避免过度预热。如果把 Top 1000 的题目全部加载到本地缓存本地缓存的 JVM 堆内存占用会显著增加可能触发 GC 压力反而让系统在预热完成后处于不稳定的状态。一个合理的原则是L1 本地缓存只预热访量最高的题目如 Top 50~100确保它们的响应延迟在毫秒级。L2 Redis 预热范围可以更大但数据本身有合理的过期时间内存占用是可控的。另一个需要警惕的场景是预热的泳道效应。如果预热列表和实际用户需求偏差很大比如预热了大量 LeetCode 国外区的题目但用户主要刷的是国内题库预热非但没发挥作用还白消耗了下游资源。因此预热列表的数据来源必须和实际用户流量的题目分布保持一致。五、总结缓存预热让刷题系统在服务启动的瞬间就具备了热数据的访问能力消除了冷启动带来的首波请求延迟飙升。热点识别靠离线分析加运营配置双管齐下预热执行靠分批加载和控制并发数来保护下游。预热本身也有成本需要根据缓存容量和实际热点分布来定范围——预热不足解决不了问题预热过度反而引入新的负担。找到这个平衡点比实现预热逻辑本身更难。
