应用层缓存对照

这一课你将能做到

1. 用一张表说清浏览器/CDN HTTP 缓存、Nginx proxy_cache、Redis 应用缓存各自的键、TTL 量级与失效方式
2. 画出 GET /api/tracks 从浏览器到 MySQL 的逐层决策图，并写出 cache-aside（旁路缓存）的读路径与写后失效代码
3. 遇到「后台改了课表但页面仍旧」时，按「浏览器 → Nginx → Redis → DB」的顺序定位该失效哪一层，而不是只让用户清浏览器

为什么要学

只学 HTTP 头，会以为「加了 max-age 就完事」；只加 Redis，浏览器还是每次都来打你。三层缓存职责完全不同：HTTP 缓存省的是重复传输，Nginx 挡的是打到应用前的流量，Redis 省的是数据库查询——而 MySQL 永远是权威数据源。

真实面试题「接口响应慢，你有哪些层次的优化手段」「如何保证缓存与数据库一致性」都建立在这张全景图上。本课是 HTTP 缓存课的延伸，也是 Redis/MySQL 学习路线的接口。

先建立图像

层级	谁决定	典型键	TTL 量级	失效方式
浏览器 / CDN	Cache-Control、ETag	URL（+ Vary 指定头）	秒 ～ 天	过期 / 304 校验 / 换 URL
Nginx	proxy_cache 配置	$request_uri 等	几十秒常见	TTL 过期 / 主动 purge
Redis	Java 业务代码	tracks:all 等	分钟级	写时 DEL / 版本号 bump
MySQL	—	行数据	—	权威源，无失效概念

一条 GET 的逐层决策：

GET /api/tracks
  ① 浏览器强缓存未过期？ → 不发请求，直接用（disk/memory cache）
  ② 请求发出，CDN / Nginx proxy_cache 命中？ → 不打 Java，返回 X-Cache-Status: HIT
  ③ 到了 Spring，Redis 有 tracks:all？ → 不打 MySQL
  ④ MySQL 查询 → 回填 Redis → 设置 HTTP 缓存头 → 响应逐层返回

每命中一层，就替下一层省一次工作；每层失效策略独立，所以「改了数据不生效」要按层排查。

跟着做

步骤 1：cache-aside 读路径（真实代码）

@Service
public class TrackService {

    private final StringRedisTemplate redis;
    private final TrackRepository trackRepository;   // → MySQL
    private final ObjectMapper objectMapper;

    public List<TrackDTO> listAll() throws Exception {
        String cached = redis.opsForValue().get("tracks:all");
        if (cached != null) {
            return objectMapper.readValue(cached, new TypeReference<>() {});
        }
        List<TrackDTO> list = trackRepository.findAllDto();     // 权威：查库
        redis.opsForValue().set("tracks:all", objectMapper.writeValueAsString(list),
                Duration.ofMinutes(5));                          // 回填 + TTL 兜底
        return list;
    }
}