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 | 弱一致 | 高 | 极高 | 高 | 日志聚合、计数器 |
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 以降低内存开销;本地缓存适合缓存不变量(如配置、字典),但要注意多实例间的数据一致性问题。