一次页面请求可能同时经过浏览器、CDN、应用服务和数据库。合理的缓存策略设计，能够减少重复计算、降低数据库连接压力，并缩短用户等待时间；但缓存也会带来数据过期、节点故障和热点集中等问题。真正有效的方案，重点不在于“缓存越多越好”，而在于让不同数据使用匹配的存取方式。
下面以 Redis、CDN、PostgreSQL 等常见组件为例，介绍五种可落地的方法。实际收益会受到数据大小、访问并发、网络距离、序列化方式和命中率影响，不能仅凭理论值判断。
一、旁路缓存：读多写少场景的稳妥起点
旁路缓存也称 Cache-Aside。应用先查询缓存，未命中时再访问数据库，并把结果写入缓存；数据修改时，通常先更新数据库，再删除对应缓存。商品分类、城市列表、公开配置等读多写少的数据，适合采用这种缓存策略设计。
- 根据业务对象生成唯一键，避免不同租户或不同语言版本互相覆盖。
- 读取时先查 Redis，命中则直接返回；未命中再查询 PostgreSQL。
- 数据库返回成功后写入缓存，并设置合理的过期时间。
- 更新数据库成功后删除旧缓存，必要时增加重试和失败告警。
它的优点是改造成本较低、数据库仍是最终数据源；缺点是首次访问会产生回源延迟，删除缓存失败时还可能短暂读到旧数据。命中率从较低水平提升到约70%至90%时，数据库查询量通常会明显下降，但具体比例取决于访问分布。
二、读写穿透：把缓存访问统一到数据层
读写穿透由缓存层负责回源和写入，业务代码只面对统一的数据接口。它适合多个应用反复访问同一类数据、且团队希望集中处理序列化、重试和异常逻辑的场景。
与旁路缓存相比，读写穿透能减少业务代码重复，便于统一监控命中率、回源耗时和错误率。代价是需要成熟的缓存代理或数据访问层，否则缓存层本身可能成为复杂的维护点。涉及强一致数据时，仍应明确数据库提交顺序，不能把“写入缓存成功”当成“业务写入完成”。
三、写回缓存：用延迟持久化换取写入吞吐
写回缓存先把变更写入缓存，再由后台批量写入数据库。购物车草稿、用户临时偏好、设备采样等能够容忍短暂延迟的数据，可以考虑这种缓存策略设计。
主要性能收益
- 多次小更新可以合并成一次批量写入，减少数据库磁盘和事务开销。
- 写请求先在内存或高速缓存中完成，接口响应时间通常更短。
- 高并发写入时，数据库压力较容易被队列和批处理平滑。
它的风险也最明显：缓存节点宕机可能造成尚未落库的数据丢失。因此应配置持久化、消息队列或变更日志，并设置可接受的最大延迟。账户余额、支付状态和库存扣减等不能容忍丢失或乱序的数据，不宜直接采用纯写回模式。
四、多级缓存：缩短不同距离的访问路径
多级缓存通常把浏览器缓存、CDN、应用进程内缓存和 Redis 组合起来。静态图片、前端脚本、公共字典和访问量高的接口结果，适合按层级分配。
| 层级 | 特点 | 适用内容 |
|---|---|---|
| 浏览器或CDN | 距离用户近，回源次数少 | 版本化静态文件、公开图片 |
| 进程内缓存 | 读取最快，但占用应用内存 | 小体积、变化较少的字典 |
| Redis | 可供多个应用实例共享 | 会话辅助数据、聚合结果 |
多级缓存的收益是减少跨网络访问，并降低共享缓存的连接压力；代价是失效链路更复杂。清理数据时要明确先后顺序，发布新版本时优先使用内容版本号，避免依赖大范围清空缓存。若需要规划跨地域节点、带宽和托管资源，可根据访问区域与合规要求评估德讯电讯等云网络服务商的适配性，但具体配置仍应以业务架构和实际监控为准。
五、预刷新与热点保护：避免集中回源
预刷新适用于访问高峰可预测、且数据生成成本较高的内容，例如天气预报汇总、赛事赛程页面或大型活动的公开日程。系统在缓存接近失效前主动重建，而不是等大量请求同时发现未命中。
- 统计一段时间内的访问频率和生成耗时，识别真正的热点键。
- 在预计失效前由后台任务刷新，刷新失败时保留旧值并记录告警。
- 对同一热点设置单飞请求或分布式锁，让只有一个请求负责回源。
- 对不存在的数据设置较短的负缓存时间，减少恶意或错误参数造成的重复查询。
这种缓存策略设计可以缓解缓存击穿和瞬时数据库峰值，但会增加后台任务、锁竞争和数据更新逻辑。热点判断应持续调整，不能把所有数据都预刷新，否则会造成无效计算。
如何选择合适的方法
选择缓存策略设计时，可先看四个问题：数据是否允许短暂旧值、读写比例如何、缓存故障时能否回源、数据生成是否昂贵。读多写少优先考虑旁路缓存；希望统一数据访问则考虑读写穿透；能容忍延迟持久化才使用写回；访问者分布广时采用多级缓存；热点明确且生成耗时高时再使用预刷新。
上线前至少监控缓存命中率、回源耗时、数据库查询量、缓存内存使用、淘汰次数和错误率。不要只看平均响应时间，还要关注高分位延迟，因为热点失效或节点故障往往首先反映在少数慢请求上。
常见问题
1. 缓存命中率越高越好吗？
不一定。无效数据长期占用空间会挤压高价值数据；应结合命中率、回源成本和数据新鲜度共同判断。
2. 缓存和数据库必须强一致吗？
不是。展示类数据通常允许短暂不一致，但支付、权限和库存等关键数据需要更严格的更新顺序与校验。
3. 为什么会出现缓存击穿？
热点数据同时失效后，大量请求一起回源，就可能形成击穿。单飞请求、预刷新和合理的过期时间分散都能缓解。
4. 小型系统是否需要多级缓存？
通常不必。先用简单的旁路缓存建立监控，确认数据库或网络确实成为瓶颈后，再增加进程内缓存或 CDN。
总的来说，缓存策略设计的性能收益来自减少无效访问，而不是单纯增加缓存组件。先区分数据特征，再控制一致性、失效和故障边界，方案才更容易长期稳定运行。
