Java API接口缓存策略有哪些

Java API接口缓存策略全览

一 缓存层级与典型实现

• 本地内存缓存：将数据放在应用 JVM 内存中，代表库有 Caffeine、Guava Cache。特点是访问延迟极低、无网络开销，适合单体或读多写少场景；缺点是重启丢失、集群不一致。示例：Caffeine 的 expireAfterWrite、maximumSize；Guava 的 CacheBuilder 配置。
• 分布式缓存：以 Redis 等为中心，所有实例共享同一份缓存，支持高可用/持久化/大容量，适合微服务/集群与热点共享；代价是网络与序列化开销。
• 多级缓存：组合“本地缓存 → 分布式缓存 → 数据源”，优先命中本地，未命中再查远程，极致性能且兼顾共享，但一致性管理更复杂。
• 声明式缓存：在 Spring 中用 @EnableCaching、@Cacheable、@CachePut、@CacheEvict 将缓存逻辑与业务解耦，底层可对接 Caffeine/Redis/Ehcache 等实现。
• API层统一缓存：通过自定义注解 + AOP 在接口层透明加缓存，减少侵入性，适合统一策略管理与横切关注点。

二 过期与淘汰策略

• TTL（Time To Live）/TTI（Time To Idle）：按写入或最近访问时间过期，典型如 Caffeine 的 expireAfterWrite/expireAfterAccess，Guava 的 expireAfterWrite/expireAfterAccess，用于保证数据新鲜度。
• 容量淘汰：基于大小限制触发淘汰，如 maximumSize（近似 LRU/LFU 等策略由实现决定），防止内存无限增长。
• 主动失效/刷新：业务变更时通过 @CacheEvict/@CachePut 或消息驱动主动清除/更新缓存，配合 TTL 形成“时间 + 事件”双重保障。
• 缓存预热：系统启动或低峰期将热点数据提前加载到缓存，降低冷启动抖动与突发穿透风险。

三 读写与一致性策略

• Cache-Aside（旁路缓存）：读先查缓存，未命中回源并回填；写先写数据源，再删除缓存（推荐做法，配合重试/异步删除提升稳健性）。
• Write-Through/Write-Behind：写同时写入缓存与数据源（Write-Through），或先写缓存、异步落库（Write-Behind），适合写密集且容忍最终一致性的场景。
• 先更库后删缓存 + 消息队列：数据库更新成功后发 MQ，各服务实例消费并删除本地/远程缓存，实现解耦与最终一致性。
• 延时双删：更新库后先删缓存，等待50–100ms（覆盖主从同步窗口）再删一次，降低不一致窗口（折衷方案）。
• 版本号/时间戳：缓存值携带版本/时间戳，读取时校验，过期则回源，减少脏读。

四 典型问题与应对

• 缓存穿透：查询不存在的数据导致每次回源。应对：布隆过滤器/空值缓存（设置较短 TTL）。
• 缓存击穿：热点 key 失效瞬间大量并发回源。应对：分布式锁（如 Redisson）只允许一个回源，其余等待回填。
• 缓存雪崩：大量 key 同时过期或缓存集群故障。应对：差异化 TTL、高可用集群、降级/熔断、限流。
• 监控与治理：持续观测命中率、QPS、延迟、容量等指标，结合告警与灰度变更降低风险。

五 选型建议与落地路径

• 单体/低并发/数据量小：优先 Caffeine/Guava 本地缓存，配置 TTL + maximumSize，必要时加 @Cacheable。
• 微服务/高并发/共享数据：使用 Redis 分布式缓存，Spring Cache 声明式接入，写操作采用“先更库后删缓存 + MQ”。
• 极致性能 + 热点明显：采用多级缓存（本地 → Redis → 数据源），热点数据启动预热，并配合熔断/限流。
• 统一治理与低侵入：通过自定义注解 + AOP 在 API 层实施缓存策略，便于集中配置与演进。