缓存与 CDN：无需增加服务器即可加速企业网站和应用

当企业网站或应用变慢时，许多人的第一反应是增加服务器容量。有时这是对的，但往往有一种便宜得多、也更有效的办法：不再反复做同样的事。同一个页面为每位访客重新生成，同一张图片从遥远的服务器下载，同一个数据库查询结果每秒重新计算。缓存（caching）就是把这些工作的结果保存起来以便复用，而 CDN（内容分发网络）则把内容副本放在靠近访客的多个位置。

本文介绍从浏览器到数据库的分层缓存、CDN 的工作方式、哪些内容可以安全缓存、哪些不可以、内容变化时如何精确清除缓存，以及如何衡量效果。目的是帮助企业主和技术团队做出合理的决策，而不承诺具体数字，因为实际结果在很大程度上取决于各自的架构和流量。

摘要

• 分层缓存（浏览器、CDN、应用、数据库）可减少服务器工作量，无需增加机器即可加快响应
• 图片、字体和脚本文件等静态资源，几乎总是可以配合带版本的文件名长期缓存
• 动态页面和个人数据必须谨慎处理，确保用户永远不会看到他人的数据
• 失效策略与存储策略同样重要；过期缓存是令人困惑的 bug 的来源
• Cache-Control 等 HTTP 头决定缓存行为，非技术人员也值得了解
• 使用真实用户指标和服务器指标在前后进行衡量，而不是凭感觉

什么是缓存，为什么有效

缓存是用于保存高成本工作结果的快速临时存储。原理很简单：如果某个结果被反复需要且很少变化，就存起来，而不是重新计算。好处是多层次的：

• **响应更快**，因为数据来自更近或更便宜的地方
• **服务器负载更轻**，流量高峰更容易消化
• **基础设施成本更可控**，尤其是大部分流量都在读取相同内容时
• **韧性更好**：源服务器出问题时，部分缓存仍可继续为访客提供服务

代价是数据过期的风险和额外的复杂性。编程界有句老话：最难的两件事是命名和缓存失效。这不是玩笑：许多生产事故都源于缓存保存了过久或范围过大的内容。

缓存的各个层次

访客的请求在到达数据库之前可能经过多个层次，每一层都是提前终止的机会。

1. 浏览器缓存

访客的浏览器会保留已下载的文件。访客打开第二个页面时，徽标、样式表和脚本不会再次下载。这是最快的一层，因为完全不涉及网络。其行为由您服务器的响应头控制。

2. CDN 与边缘缓存

CDN 是分布在许多城市和国家的服务器网络。内容被复制到离访客最近的服务器，数据传输距离更短。棉兰和望加锡的访客可以从靠近他们的位置获得服务，而不是从单一的中心服务器。CDN 还能吸收流量高峰，并通常提供针对攻击的基础防护、自动压缩和图片优化。对于面向国际访客的企业，CDN 有助于缩短服务器与读者之间的距离，这与国际 SEO：hreflang、URL 结构与内容本地化中的策略相关。

3. 页面或响应缓存

由模板和数据生成的页面，如博客文章或产品页，可以保存为现成的 HTML。服务器或 CDN 不必每次都重新组装页面，而是直接发送已有结果。现代 Web 框架提供多种模式：构建时生成的页面、后台定期刷新的页面，以及按请求生成后再保存的页面。

4. 应用与数据缓存

在应用内部，计算结果或对其他服务的调用可以保存在内存或 Redis 等快速存储中。例如产品类别列表、配置、计算后的价格，或第三方 API 的响应。这一层对业务 API 尤其有用，见业务 API 设计：版本管理、文档与限速。

5. 数据库缓存

数据库自身有针对数据页和查询计划的内部缓存。此外，汇总表或物化视图可以保存销售报表等繁重的聚合结果，使看板每次打开时不必计算数百万行。在添加缓存之前，索引和查询调优仍是基础，因为缓存无法修复糟糕的查询，只会把问题掩盖起来。

值得了解的 HTTP 头

浏览器和 CDN 的缓存行为很大程度上由响应头决定。以下是最常用的几个，尽量不用太多术语：

• **Cache-Control**：主要的头。“public”表示共享缓存（CDN）可以存储，“private”表示仅限用户浏览器，“no-store”完全禁止存储，“max-age”设定结果被视为新鲜的秒数
• **s-maxage**：类似 max-age，但专用于 CDN 等共享缓存。有助于让 CDN 保存的时间长于浏览器
• **stale-while-revalidate**：允许缓存在后台获取新版本的同时提供旧版本。访客得到快速响应，内容稍后即被更新
• **ETag 与 Last-Modified**：版本标记，让浏览器询问“这个文件变了吗？”，未变时只收到简短回答
• **Vary**：告诉缓存响应会因某些头（如语言或压缩类型）而不同。Vary 配置错误可能让访客看到错误的语言版本
• **Set-Cookie**：设置 Cookie 的响应通常默认不会被 CDN 缓存；要留意不要波及公开页面

不必全部背下来。重要的是团队有一份书面政策：哪类内容采用哪种设置，以及原因。

哪些可以缓存，哪些不可以

下面的实用划分有助于按内容类型确定策略。

可长期缓存

图片、图标、字体、样式表和脚本等静态资源。诀窍：让文件名包含版本或内容哈希（例如 app.3f9a1c.js）。文件变化时名称也变化，旧缓存自动不再被使用，无需手动清除。这类文件可保存一年而没有过期风险。图片也应优化尺寸和格式，见核心网页指标：LCP、INP、CLS。

可短期缓存

每天或每周变化几次的公开内容页面，如文章、服务页面和目录。使用较短的新鲜期并在后台刷新，或在内容被编辑时使其失效。

需要谨慎

• **包含用户数据的页面**：看板、购物车、个人资料和订单历史。没有区分每个用户的缓存键，绝不要把它们存入共享缓存。把个人页面存在 CDN 上，是用户之间数据泄露的典型原因
• **价格、库存和促销**：如果变化很快，旧缓存可能显示错误价格。把展示（可缓存）与关键数字（结账时实时获取）分开
• **搜索结果与筛选**：变化极多，缓存命中率低。另见[语义搜索与向量搜索](/blog/pencarian-semantik-dan-vector-search-untuk-website-dan-aplikasi-bisnis)
• **带安全令牌的响应**：含 CSRF 令牌或一次性随机数的表单不得放入共享缓存

不要缓存

写入类交易（支付、创建订单）、认证响应，以及因法律或财务原因必须始终保持最新的数据。这些情况下使用“no-store”，并确保 CDN 遵守。

失效：精确清除缓存

存储容易，在恰当的时刻删除才难。有几种策略，常常组合使用：

• **按时间过期（TTL）**：缓存在若干分钟或小时后自动视为过期。简单，但数据在 TTL 期间可能是旧的
• **资源使用带版本的名称**：如上所述，名称变化，无需失效操作
• **基于事件的失效**：编辑保存文章时，系统清除该页面及文章列表、站点地图等相关页面的缓存
• **标签或替代键**：部分 CDN 允许给响应打标签（例如“product-123”），然后按标签一次性清除
• **后台刷新**：在准备新版本的同时展示旧版本，如 stale-while-revalidate

还要设计失效失败时会发生什么。过期页面会保留一小时吗？一天吗？设定业务可以接受的上限，并提供手动清除缓存的紧急按钮。确保价格更正或删除有法律问题的内容等重要变更能够快速传播。

对 SEO 与用户体验的影响

速度影响访客满意度，也是搜索引擎评估的页面体验的一部分。需要记住几点：

• 服务器慢会损害首字节时间（TTFB），而它是其他指标的基础。页面缓存和 CDN 是改善它的最直接方式
• 确保提供给搜索引擎的版本与用户所见一致，不要提供内容已被删除的过期页面
• 确保从缓存提供正确的状态码：已移动或删除的页面必须给出重定向或合适的状态码，而不是继续从旧缓存显示 200。这在[网站改版与迁移](/blog/redesign-dan-migrasi-website-tanpa-kehilangan-peringkat-seo)时很重要
• 站点地图、robots.txt 和其他重要文件应设置较短的缓存期，使变更能迅速生效
• 对多语言网站，确保各语言版本有独立的缓存键，且基于浏览器语言的自动跳转不会缓存错误结果

安全与可靠性

CDN 在安全和韧性方面也发挥作用。作为最前端的一层，它可以吸收过量流量、过滤恶意请求并隐藏源服务器地址。相关做法见防范机器人、爬取和自动化攻击。但也有需要留意的地方：

• 缓存配置错误可能泄露私人页面，因此要用不同账号和匿名会话测试
• 确保 HTTPS 证书和安全设置延伸到源服务器，而不是止步于 CDN
• 限制对源服务器的直接访问，使流量必须经过 CDN
• 准备 CDN 发生故障时的预案，包括如何改道流量，如[灾难恢复与业务连续性计划](/blog/rencana-pemulihan-bencana-dan-kesinambungan-bisnis)所述
• 考虑对单一供应商的依赖，以及必要时如何退出，见[供应商锁定与退出策略](/blog/vendor-lock-in-di-cloud-dan-software-bisnis-strategi-keluar)

衡量效果

不要根据在自己笔记本上的一次测试来判断缓存是否成功。使用组合度量：

• CDN 和应用中的**缓存命中率**。命中率低表示规则过严或缓存键过于多样
• 前后对比的**服务器响应时间和 TTFB**，来自多个地点
• **真实用户体验指标**，如来自实际访客的核心网页指标，而不仅仅是实验室测试
• **源站负载**：CPU 使用率、数据库查询次数以及到达源站的请求数
• **错误率**以及关于内容过期的投诉
• **成本**：比较 CDN 和存储成本与服务器节省的费用

在大型促销之前，结合负载测试来检验缓存是否真能挡住流量高峰，见大促与旺季前的负载测试。也要测试冷缓存场景，即发布或清除后缓存为空的时候，因为那是源服务器最脆弱的时刻。

开始的实用步骤

这个顺序很少出错：

• **初步审计**：列出网站上的内容类型，判断各自是公开、半公开还是私密
• **先处理静态资源**：采用带版本的名称和较长的缓存期，并配合压缩和现代图片格式
• **在网站前部署 CDN**，并验证发送的头符合计划
• **缓存公开页面**，采用较短的新鲜期或分阶段刷新，并把失效操作连接到内容编辑流程
• **在性能分析显示缓慢的地方添加数据缓存**，而不是凭猜测
• **记录缓存政策**以及谁有权修改
• **定期监控和调整**；需求会随内容和流量增长而变化

对缓存规则的重大变更采用分阶段发布，便于回滚，遵循功能开关与分阶段发布的模式。如果您的应用也希望在网络较差时保持可用，请参阅企业渐进式 Web 应用中如何利用设备端缓存。

常见错误

• 把包含用户数据的页面存入共享缓存
• 为没有带版本名称的文件设置很长的缓存期，导致用户看不到更新
• 出现内容错误时没有快速清除缓存的办法
• 为掩盖没有索引的数据库查询而增加缓存
• 只在快速的办公室网络和靠近服务器的地点测量
• 在多语言网站上忽略 Vary 头
• 发布后忘记测试冷缓存状态

常见问题

小型企业网站需要 CDN 吗？

不一定，但通常有益。许多现代托管服务已经包含 CDN。当访客分布广泛或页面加载大量图片时，好处最明显。

为什么我网站上的改动没有立刻显示？

很可能旧内容仍保存在浏览器或 CDN 缓存中。检查所设置的缓存期，清除缓存，并确保失效流程与内容编辑流程相连。

缓存会降低安全性吗？

正确配置时不会。风险来自配置错误，尤其是把私人内容存入共享缓存。用多个账号测试，并对用户页面使用“private”或“no-store”。

缓存期应该多长？

取决于内容类型。带版本的资源可以非常长，公开内容页面需要几分钟到几小时并配合后台刷新，关键数据则不缓存。依据业务能接受内容过期多久来设定。

缓存能取代代码和数据库优化吗？

不能。缓存是对优化的补充，而不是替代。先修复慢查询和沉重的资源，再用缓存在流量上升时保持速度。

结论

缓存和 CDN 是让企业网站和应用感觉快速的最经济方式，因为它们减少不必要的工作，而不是增加机器。关键在于理解各个层次、按性质对内容分类、从一开始就设计失效机制，并用真实数据衡量结果。从静态资源和公开页面开始，再谨慎扩展到动态数据。