1. 缓存基础理论
1.1 缓存的定义
缓存（Cache）是一种将数据存储在临时存储介质中的技术，使得后续对相同数据的请求能够以更快的速度被响应。在计算机系统中，缓存位于数据源（如数据库、磁盘）与请求方（如应用服务、用户）之间，充当高速数据中转层。
核心定义：缓存是空间换时间的经典策略——用额外的存储空间换取数据访问的低延迟。
1.2 缓存的核心价值
缓存的价值体现在两个关键维度：
| 价值维度 | 说明 | 典型指标 |
|---|---|---|
| 降低延迟 | 内存访问延迟通常在微秒级（<1ms），而数据库磁盘I/O延迟在毫秒级（10~50ms），缓存可将响应时间降低1~2个数量级 | P99延迟从50ms降至2ms |
| 减轻数据库压力 | 缓存命中率每提升10%，数据库查询量可减少对应比例，避免数据库成为系统瓶颈 | QPS从1000降至200（命中率80%） |
实践案例：某电商商品详情页，引入Redis缓存后，页面加载时间从1.2s降至80ms，数据库查询量减少92%。
1.3 缓存与数据库的差异
缓存与数据库在多个维度存在本质差异，理解这些差异是设计缓存策略的基础：
| 对比维度 | 缓存（如Redis） | 数据库（如MySQL） |
|---|---|---|
| 存储介质 | 内存（DRAM） | 磁盘（SSD/HDD） |
| 数据持久性 | 弱（宕机可能丢失） | 强（ACID事务保证） |
| 访问速度 | 微秒级（0.1~1ms） | 毫秒级（10~100ms） |
| 存储容量 | GB级（成本高） | TB~PB级（成本低） |
| 查询能力 | 简单KV/结构化查询 | 复杂SQL/关联查询 |
| 一致性模型 | 最终一致性为主 | 强一致性为主 |
1.4 缓存失效场景概述
缓存并非万能，在实际系统中存在多种失效场景，直接影响缓存一致性和系统可用性：
- 数据更新失效：数据库数据被修改后，缓存中的旧数据未同步更新，导致脏读。
- 缓存过期失效：TTL（Time To Live）到期后缓存自动删除，此时大量请求同时穿透到数据库。
- 缓存雪崩：大量缓存同时过期或缓存节点宕机，请求全部落到数据库，引发连锁故障。
- 缓存穿透：请求查询不存在的数据（如恶意攻击），缓存和数据库都未命中，直接打穿到数据库。
- 缓存击穿：热点Key在失效瞬间，高并发请求同时访问该Key，导致数据库压力骤增。
- 内存淘汰失效：缓存容量达到上限时，按淘汰策略（LRU/LFU等）移除数据，导致部分缓存失效。
| 失效场景 | 触发条件 | 影响范围 | 典型后果 |
|---|---|---|---|
| 数据更新失效 | 数据库写操作后未更新缓存 | 单条数据 | 数据不一致、脏读 |
| 缓存过期失效 | TTL到期 | 单条数据 | 短暂数据库压力上升 |
| 缓存雪崩 | 大量Key同时过期/节点宕机 | 全局 | 数据库被打垮、服务不可用 |
| 缓存穿透 | 查询不存在的数据 | 单条数据 | 数据库无效查询增加 |
| 缓存击穿 | 热点Key失效+高并发 | 单条热点数据 | 数据库瞬时压力峰值 |
| 内存淘汰失效 | 缓存容量满 | 部分数据 | 非热点数据被移除 |
常见误区：很多团队在引入缓存时只关注性能提升，忽略了失效场景的治理。实际上，缓存失效导致的数据库雪崩是生产环境中最常见的中级故障之一。建议在缓存设计初期就将失效场景纳入架构考量。
1.5 缓存一致性基本概念
缓存一致性是指缓存中的数据与数据库中的数据保持同步的程度。根据业务场景的不同，一致性要求可分为三个级别：
- 强一致性：每次读操作都能读到最新的写操作结果，实现难度高、性能损失大。
- 最终一致性：允许短暂的不一致窗口，经过一段时间后数据最终达到一致，是大多数缓存系统的默认模型。
- 弱一致性：不保证后续读操作能读到最新写入，适用于对实时性要求极低的场景。