启动预热的适用场景启动预热适合以下情况数据主要来自第三方接口无法直接从本地数据库读取。第三方接口响应较慢首次访问容易超时。一个页面需要调用多个第三方接口或逐项查询。数据读取频繁但变化不频繁。希望服务启动后用户第一次访问也能快速返回准确数据。允许服务启动阶段承担一定的数据加载成本。典型场景包括项目成员、组织人员等低频变化数据。字典、配置、产品目录等基础数据。第三方系统的状态或摘要信息。计算成本较高但结果相对稳定的统计数据。不适合的场景已经完整同步到本地数据库的数据。强实时数据如库存、余额、实时设备状态。数据量很大预热可能拖慢应用启动。第三方接口有严格限流。多实例同时启动会造成请求风暴。缓存内容包含大量用户级、权限级差异。实现思路整体流程应用启动完成→ 查询需要预热的数据范围→ 优先检查缓存→ 对缺失或过期的数据调用第三方接口→ 写入Redis→ 用户请求直接读取缓存Spring Boot 可以使用ApplicationRunnerService RequiredArgsConstructor public class ProjectMemberCacheService implements ApplicationRunner { Override public void run(ApplicationArguments args) { warmUpMissingCaches(); } }核心是实现Application类并重写其方法run预热时建议仅补齐缺失缓存for (Project project : projects) { String cacheKey buildCacheKey(project.getProjectCode()); if (!redisService.hasKey(cacheKey)) { ListString members thirdPartyService.queryProjectMembers(project.getProjectCode()); redisService.setCacheObject( cacheKey, members, 24, TimeUnit.HOURS); } }不要每次启动都无条件刷新全部数据否则服务频繁重启时容易给第三方造成压力。推荐的完整策略预热通常与以下机制组合使用启动预热保证首次访问速度。缓存懒加载预热遗漏的数据在访问时补齐。定时刷新周期性更新低频变化数据。手动刷新处理单条数据需要立即更新的情况。缓存降级Redis异常时允许直接调用第三方。过期时间防止缓存永久陈旧。分布式锁防止多实例同时预热同一批数据。推荐的数据读取顺序读取缓存├─ 命中直接返回└─ 未命中→ 获取短时分布式锁→ 再次检查缓存→ 调用第三方→ 写入缓存→ 返回结果这里的“再次检查缓存”可以避免多个请求等待锁期间重复调用第三方。多实例注意事项如果部署多个服务实例不能让每个实例同时全量预热。可以使用Redis锁plm:cache:warmup:lock只有获取锁的实例执行预热其他实例跳过。锁必须设置超时时间并使用唯一令牌安全释放。还可以加入随机延迟避免所有实例在同一时间刷新基础刷新时间 05分钟随机抖动可靠性设计预热属于性能优化不应影响核心服务启动。推荐做到单条预热失败只记录日志继续处理其他数据。第三方整体不可用时停止本轮预热但不阻止应用启动。设置连接、读取和整体任务超时。控制并发数量例如24个线程。对瞬时网络异常进行有限重试。记录预热总数、成功数、失败数和耗时。不在日志中输出凭证、Cookie等敏感信息。缓存时间建议缓存时间应根据数据变化频率确定几乎不变化1224小时。每天变化几次16小时。需要较新数据1030分钟。强实时数据通常不建议使用普通启动预热。为避免同一时间大量缓存同时失效可以加入随机过期时间TTL 24小时 随机060分钟退出条件出现以下变化时应考虑取消启动预热第三方数据已经定时同步到本地数据库。本地表可以准确、快速地满足查询。缓存和本地表开始产生一致性问题。预热明显拖慢服务启动。第三方接口调用量或限流压力增大。总结启动预热适用于“数据必须从慢速外部来源获取、变化不频繁、但首次访问必须快速”的场景一旦数据已经可靠落入本地数据库应优先读取本地不再维护重复缓存。