很多网站做性能优化时，会先盯着单个插件、单条 SQL 或某个服务器参数，但真正能长期解决访问慢的问题，往往是多级缓存架构。本文会用一个从浏览器到数据库的链路，说明如何把缓存放在合适位置、为什么不能只缓存一个层级，以及上线后怎样验证命中率和回源压力是否真的下降。读完后，你可以把它当作一次网站加速改造的检查框架，而不是零散技巧清单。
先判断瓶颈：缓存不是越多越好
多级缓存架构的目标不是把所有内容都塞进缓存，而是在“用户请求最可能重复发生”的位置提前保存结果。一个典型页面请求会经过浏览器、网络入口、Web 服务、应用逻辑和数据库。每一层都能缓存，但每一层的成本、刷新难度和风险不同。静态图片适合靠近用户保存，购物车价格、库存状态这类动态数据则需要更谨慎的失效策略。
落地前建议先做 24 小时基线记录，至少包含首页 TTFB（首字节时间）、P95 响应时间、数据库 QPS、缓存命中率和错误率。若一个 WordPress 站点的首页 TTFB（首字节时间）从 900ms 波动到 2s，数据库慢查询占比又超过 10%，问题通常不只在前端资源，而是动态页面和数据库层都在重复计算。Hostease 用户在选择 VPS（虚拟专用服务器）主机 或更高规格环境时，也应先确认缓存策略是否合理，否则单纯升级资源只能短期缓解压力。
浏览器与边缘层：优先拦住可重复下载的资源
第一层缓存应该放在离用户最近的位置。浏览器缓存适合处理 CSS、JavaScript、图片、字体等静态资源，因为这些文件通常在多次访问中不会变化。常见做法是在 Web 服务中为带版本号的静态文件设置较长的 Cache-Control，例如 30 天或 1 年；而 HTML 页面可以设置更短时间，避免内容更新后用户长时间看到旧页面。
一个可执行的 Nginx 示例是：
location ~* \.(css|js|png|jpg|jpeg|webp|svg|woff2)$ {
expires 30d;
add_header Cache-Control "public, max-age=2592000, immutable";
}
如果站点面向跨地区访问，还可以在入口前增加 CDN（内容分发网络）或反向代理缓存。这里要注意，CDN（内容分发网络）适合缓存图片、下载文件、公开文章页等可复用内容，不适合直接缓存后台、结账页、用户中心这类与登录状态相关的页面。若缓存规则过宽，可能出现用户看到他人页面状态的严重问题。
检查这一层是否有效，可以用浏览器开发者工具或 curl -I 查看响应头。静态资源应能看到 Cache-Control、ETag 或 Last-Modified，重复访问时状态通常为 304 或直接从本地缓存读取。对于内容运营站点，建议把这一层与 网站性能优化指南 一起看，因为 TTFB（首字节时间）和静态资源加载时间分别对应不同优化动作。
应用层缓存：减少重复渲染和重复查询
当请求已经到达应用，缓存重点就从“文件下载”变成“计算结果复用”。例如首页文章列表、分类页摘要、热门文章模块、商品筛选结果，都可能在 1 分钟内被大量重复访问。如果每次都重新执行模板渲染和多条数据库查询，服务器会把 CPU 与数据库连接浪费在相同结果上。
常见应用层缓存可以分为 3 类：页面缓存、对象缓存和片段缓存。页面缓存直接保存完整 HTML，命中时最快；对象缓存保存数据库查询结果，适合登录用户或局部动态页面；片段缓存只保存某个模块，例如侧边栏热门文章。WordPress 站点可以结合页面缓存插件与对象缓存服务，但启用前要确认登录态、评论提交、购物车等路径已经排除。更多 WordPress 场景可参考 WordPress 相关优化内容。
一个实用判断标准是缓存 TTL（生存时间）是否匹配业务变化频率。新闻列表可以设置 60 秒到 300 秒，产品价格可能只适合 30 秒或通过发布事件主动刷新，后台预览页则应完全绕过缓存。若你无法确定失效策略，宁可先缩短 TTL（生存时间），再观察命中率，而不是一开始把所有动态页面缓存 1 小时。
数据库层缓存：保护最昂贵的查询
多级缓存架构的最后一道防线通常在数据库附近。数据库层不是让你忽略索引和 SQL 质量，而是把高频、低变化、成本高的查询结果保存起来。比如首页统计、热门商品、文章阅读排行、权限配置读取，都适合通过对象缓存或独立缓存服务降低数据库压力。
设计数据库缓存时，建议先从慢查询日志里挑出 P95 耗时超过 200ms、每天调用超过 1000 次、结果变化频率低于每 5 分钟 1 次的查询。这样的查询缓存收益明显，也比较容易控制一致性。相反，订单状态、支付结果、库存扣减这类强一致数据，不能只依赖缓存返回结果，应以数据库事务和实时校验为准。
为了避免缓存雪崩和击穿，可以采用 3 个简单规则。第一，给不同 key 加 5% 到 10% 的随机过期时间，避免同一秒大量失效。第二，对热点 key 设置互斥重建，只有一个请求回源刷新，其余请求短暂等待或读取旧值。第三，给缓存服务设置内存上限和淘汰策略，例如 LRU（最近最少使用）或 LFU（最不常使用），防止冷数据挤掉真正有价值的热点数据。
服务器侧还要配合基础资源规划。数据库缓存能降低查询次数，但如果磁盘 I/O 长期接近上限，或连接池经常打满，仍需要从 服务器优化与配置 角度检查 CPU、内存、磁盘和网络路径，而不是把所有问题归因于缓存没开。
失效策略：决定缓存架构能不能长期稳定
缓存真正难的地方不是“存进去”，而是“什么时候删掉或更新”。如果失效策略混乱，短期看页面变快，长期会出现价格不一致、文章更新不生效、用户状态错乱等问题。我们建议按数据类型制定不同规则，而不是全站使用同一个过期时间。
可以把站点内容分成 4 类来处理：
- 静态资源：文件名带版本号，TTL（生存时间）可设为 30 天以上，发布新版本时换文件名。
- 公开内容页：文章详情页可设 5 到 30 分钟，发布或编辑文章时主动清理对应 URL。
- 半动态列表：分类页、搜索页建议 1 到 5 分钟，并限制搜索结果缓存数量。
- 用户相关页面：后台、账户、购物车、结账页默认不缓存，只缓存其中可复用的小模块。
上线时还要准备回滚方案。最简单的方式是保留一条全站清理命令、一条按 URL 清理命令和一份缓存旁路配置。比如应用层可以增加 CACHE_BYPASS=true 环境变量，出现异常时先绕过缓存，再排查 key 设计或过期规则。这样做比直接重启所有服务更可控，也能减少故障影响范围。
上线验证：用数据证明缓存真的生效
多级缓存架构上线后，不要只凭“体感更快”判断成功。至少要对比上线前后 24 小时数据，重点看 5 个指标：缓存命中率、数据库 QPS、P95 响应时间、5xx 错误率、源站 CPU 使用率。理想情况下，静态资源命中率应接近 90% 以上，公开页面命中率可以逐步提升到 60% 到 80%，数据库 QPS 在高峰期应有明显下降。
也要检查反向指标。若命中率升高但 5xx 错误率增加，可能是缓存服务连接池过小；若 TTFB（首字节时间）下降但用户仍反馈慢，可能是图片体积、第三方脚本或前端阻塞问题；若数据库 QPS 没降，说明应用层仍有未缓存的高频查询。对使用 VPS（虚拟专用服务器）主机 的中小团队来说，建议先完成这些验证，再判断是否需要扩容或拆分服务。
总结：从最安全的层开始，逐步扩大缓存范围
总结来看，多级缓存架构应按“浏览器与边缘层优先、应用层精细控制、数据库层保护热点查询”的顺序推进。这样做的好处是风险从低到高逐步释放，每一步都能通过响应头、命中率和数据库负载验证效果。如果你需要为现有网站做加速改造，建议先记录 24 小时基线，再从静态资源缓存和公开页面缓存开始，最后处理对象缓存与数据库热点查询。对于业务增长较快、访问来源分散的网站，可以考虑把缓存策略与主机资源规划一起评估，避免只优化代码却忽略运行环境承载能力。