1. 缓存基础概念:什么是缓存、缓存的作用与价值、缓存与数据库的典型协作模式

1.1 什么是缓存

缓存(Cache)是一种将数据临时存储在高速存储介质中的技术,目的是让后续对相同数据的访问能够更快地获取结果。在数据库场景下,缓存通常位于应用层与持久化数据库之间,充当“短期记忆”的角色。

缓存的核心思想是 空间换时间:用额外的存储空间(通常是内存)来减少对慢速存储(如磁盘)的访问次数。缓存中的数据是原始数据的一个子集或副本,当原始数据发生变化时,缓存需要同步更新或失效。

关键认知: 缓存不是数据库的替代品,而是数据库的加速层。缓存的数据天然具有“最终一致性”特征,不能保证与数据库的实时强一致。

1.2 缓存的作用与价值

缓存的价值可以从三个维度衡量:性能、吞吐、成本。

维度 说明 典型指标
性能 降低数据访问延迟,提升用户体验 内存访问延迟 ~0.1ms,磁盘访问延迟 ~10ms(相差 100 倍)
吞吐 减轻数据库负载,支撑更高并发 单机 Redis 可达 10 万 QPS,单机 MySQL 约 1 万 QPS
成本 减少数据库扩容需求,降低基础设施投入 缓存命中率每提升 10%,数据库 CPU 使用率可降低 15%~20%

缓存带来的具体收益包括:

  • 热数据加速:将高频访问的数据(如用户会话、商品详情)放入缓存,响应时间从秒级降至毫秒级。
  • 数据库保护:缓存层吸收大部分读请求,避免数据库被突发流量打垮。
  • 系统弹性:在流量尖峰时,缓存可以作为缓冲层,防止数据库过载。
  • 降低网络开销:缓存数据通常与应用部署在同一机房或同一进程内,减少跨网络调用。
行业经验: 在互联网高并发系统中,缓存命中率通常要求达到 95% 以上。低于 90% 的命中率意味着缓存策略需要重新设计。

1.3 缓存与数据库的典型协作模式

缓存与数据库的协作模式决定了系统的数据一致性级别和性能表现。以下是四种最常用的模式:

模式一:Cache-Aside(旁路缓存)

这是最广泛使用的模式。应用代码同时感知缓存和数据库,由应用逻辑控制数据的读写路径。

  • 读流程:先查缓存 → 命中则返回 → 未命中则查数据库 → 将数据写入缓存 → 返回结果。
  • 写流程:先更新数据库 → 然后删除缓存(或更新缓存)。
常见陷阱: 写流程中“先更新数据库再删除缓存”比“先删除缓存再更新数据库”更安全。后者在并发场景下容易导致缓存与数据库数据不一致。

模式二:Read-Through(穿透读)

缓存层封装了数据库的读取逻辑。应用只与缓存交互,缓存未命中时由缓存组件自动加载数据库数据。

  • 应用调用缓存 API → 缓存检查是否存在 → 不存在则缓存组件加载数据库 → 缓存数据并返回。
  • 对应用透明,简化了业务代码。

模式三:Write-Through(穿透写)

写操作先经过缓存,由缓存同步写入数据库。保证缓存与数据库的强一致性,但写延迟较高。

  • 应用写缓存 → 缓存同步写数据库 → 两者都成功才返回成功。
  • 适用于对数据一致性要求极高的场景(如金融交易)。

模式四:Write-Behind(异步写回)

写操作只更新缓存,由后台异步任务批量将数据写入数据库。性能最高,但存在数据丢失风险。

  • 应用写缓存 → 立即返回成功 → 后台线程合并写入数据库。
  • 适用于写操作频繁、允许少量数据丢失的场景(如用户行为日志、点赞计数)。
模式 一致性 读性能 写性能 实现复杂度 典型场景
Cache-Aside 最终一致 高 中 低 通用 Web 应用、商品详情
Read-Through 最终一致 高 中 中 配置中心、元数据缓存
Write-Through 强一致 中 低 中 账户余额、库存扣减
Write-Behind 弱一致 高 极高 高 日志聚合、计数器
缓存与数据库典型协作模式(Cache-Aside 流程) 应用层 缓存层(Redis) 数据库层(MySQL) ① 读缓存 ② 未命中,回源数据库 ③ 返回数据 ④ 写数据库 ⑤ 删除缓存 关键说明: • 读流程:缓存命中直接返回,未命中则查库并回填缓存。 • 写流程:先更新数据库,再删除缓存(推荐),避免并发脏读。 • 缓存失效策略:设置 TTL(过期时间)作为兜底,防止缓存与数据库长期不一致。 • 适用场景:读多写少、对一致性要求不苛刻的业务系统。

1.4 缓存的核心术语与衡量指标

理解以下术语是掌握缓存技术的基础:

术语 定义 计算公式 / 典型值
命中率 缓存成功返回数据的请求占比 命中次数 / 总请求次数;目标 > 95%
穿透 请求的数据既不在缓存也不在数据库 导致缓存层和数据库层都做无用功
击穿 热点 key 过期瞬间,大量请求直接打到数据库 常见于高并发场景下的单个热点 key
雪崩 大量缓存 key 同时过期,导致数据库瞬间过载 通常由统一过期时间或缓存宕机引发
TTL 缓存数据的存活时间(Time To Live) 根据业务容忍度设置,通常 1~30 分钟
预热 系统启动时主动将热点数据加载到缓存 避免冷启动导致大量穿透
实践建议: 缓存命中率是衡量缓存系统健康度的首要指标。建议在监控面板上实时展示命中率曲线,当命中率低于 90% 时触发告警。

1.5 缓存选型对比

当前主流的缓存技术选型对比:

特性 Redis Memcached 本地缓存(Caffeine)
数据结构 丰富(String、Hash、List、Set、ZSet) 仅 Key-Value Key-Value + 对象引用
持久化 支持(RDB / AOF) 不支持 不支持
集群模式 原生集群、哨兵、分片 客户端分片 单机
延迟 ~0.1ms(网络调用) ~0.1ms(网络调用) ~0.01ms(进程内)
适用场景 复杂数据结构、需要持久化、分布式 简单 KV 缓存、高吞吐 单机高频访问、元数据缓存
选型建议: 分布式系统首选 Redis,利用其丰富的数据结构和持久化能力;纯 KV 缓存场景可选 Memcached 以降低内存开销;本地缓存适合缓存不变量(如配置、字典),但要注意多实例间的数据一致性问题。