典型网络堆栈中的缓存层有哪些？

Question

典型网络堆栈中的缓存层有哪些？

Accepted Answer

请求通过**多个缓存层**，每一层都更靠近用户，速度更快但容量较小。这个想法是尽可能地从外部（靠近客户端）响应，只有当上游没有任何层可以提供响应时才回退到源。

## 这些层，从外到内

```text
Browser → CDN → Reverse proxy → App/object cache → OPcache → Database
(closest to user, fastest)                            (closest to data)
```

- **浏览器缓存** — 在用户设备上存储静态资源（JS、CSS、图像）和可缓存的响应。TTL 由 `Cache-Control`/`ETag` 控制；资源通常获得很长的 TTL（天–年），并使用哈希文件名。
- **CDN**（CloudFront、Cloudflare）— 在靠近用户的边缘节点缓存静态内容，有时也缓存动态内容。TTL 从分钟（HTML）到一年（不可变资源）。
- **反向代理**（Varnish、nginx）— 在应用前缓存完整页面或片段。热页面的 TTL 为秒到分钟；支持按需清除。
- **应用/对象缓存**（Redis、Memcached）— 缓存计算结果、数据库查询结果、会话、渲染的片段。TTL 为秒到小时，加上显式失效。
- **OPcache** — 在内存中缓存**编译的 PHP 字节码**，以便脚本不会在每次请求时重新解析。有效期持续到代码部署。
- **数据库查询/缓冲区缓存** — 数据库在内存中保存热页面和（在某些引擎中）查询结果，避免磁盘读取。

## 如何思考它们

```text
for each layer outward → inward:
  if layer has fresh copy → return it (stop here)   // a hit; cheapest possible
  else → ask the next layer in                      // a miss; falls through
origin (app + DB) → does the real work, fills caches on the way back out
```

每一层都在**新鲜度和速度之间权衡**：外层最快但最可能过时，所以对真正的静态内容放长 TTL + 内容哈希，对动态内容放短 TTL + 失效。

## 为什么这很重要

网络堆栈中的大部分延迟和负载减少来自于在正确的层进行缓存。了解每一层保存的内容及其典型 TTL 让你能够在真正有帮助的地方放置缓存、避免提供陈旧数据、以及推理为什么某项更改没有出现（哪一层仍在提供旧副本）。