1. 缓存基础与演进：从本地缓存到分布式缓存，缓存的核心价值与挑战
1.1 缓存的核心价值：为什么需要缓存？
缓存是后端系统中提升性能、降低延迟、保护下游资源的最有效手段之一。其核心价值体现在三个维度：
- 降低延迟：将热点数据存储在高速存储介质（内存）中，避免每次请求都穿透到磁盘数据库或远程服务，通常可将响应时间从毫秒级降至微秒级。
- 提升吞吐量：缓存层能承载远超后端数据库的并发请求量（如 Redis 单机可达 10 万+ QPS），有效放大系统处理能力。
- 保护后端资源：数据库连接池、下游微服务等资源有限，缓存作为“防洪堤”可防止突发流量冲垮核心服务。
关键指标参考： 未命中缓存时数据库查询耗时约 10-50ms，命中本地缓存可降至 <0.1ms，命中分布式缓存（如 Redis）可降至 1-5ms。缓存命中率每提升 10%，系统整体延迟通常可降低 30%-50%。
1.2 缓存架构演进：从单机到分布式
缓存架构经历了三个主要阶段，每个阶段解决不同规模下的核心矛盾。
| 阶段 | 代表技术 | 核心优势 | 主要局限 |
|---|---|---|---|
| 本地缓存 | HashMap、Guava Cache、Caffeine、Ehcache | 零网络开销，速度最快（纳秒级）；实现简单 | 容量受限于单机内存；多实例间数据不一致；无法共享 |
| 集中式缓存 | Memcached、Redis（单机/主从） | 独立部署，容量可扩展；多应用共享；数据一致性较好 | 单点瓶颈；网络开销增加；主从切换有短暂不可用 |
| 分布式缓存 | Redis Cluster、Codis、Tair、Aerospike | 水平扩展，无单点；自动分片与故障转移；支持海量数据 | 架构复杂；跨分片操作受限；网络延迟叠加 |
选型建议： 单机应用或微服务实例数 < 5 时，Caffeine 本地缓存 + Redis 集中式缓存的组合性价比最高；当节点数超过 20 或数据量超过 100GB 时，应优先考虑 Redis Cluster 或 Proxy 方案。
1.3 缓存架构演进示意图
下图展示了从本地缓存到分布式缓存的典型架构演进路径，以及各阶段的数据流与一致性挑战。
1.4 缓存面临的核心挑战
引入缓存并非银弹，架构师必须正视以下五大核心挑战：
- 缓存与数据库一致性：更新数据库后如何同步更新缓存？先更新缓存还是先更新数据库？双写场景下如何避免脏数据？
- 缓存穿透、击穿、雪崩：热点 key 失效、大量请求绕过缓存直达数据库，可能导致后端资源瞬间耗尽。
- 数据淘汰与过期策略：内存有限，如何选择 LRU/LFU/TTL 策略？过期数据如何优雅删除？
- 缓存路由与分片：分布式环境下，请求如何正确路由到对应分片？节点扩缩容时如何最小化数据迁移？
- 安全合规与数据保护：缓存中是否包含敏感信息？如何防止未授权访问？跨境场景下数据驻留如何满足合规要求？
常见误区： 很多团队在初期只关注缓存性能，忽略了一致性和安全合规。一旦缓存与数据库出现数据偏差，或缓存被恶意攻击导致敏感数据泄露，修复成本远高于前期设计投入。本课程后续章节将逐一给出闭环解决方案。
1.5 缓存一致性问题的根源
缓存一致性问题的本质是数据副本之间的时序冲突。当同一份数据在数据库和缓存中各存一份，且更新操作无法原子化时，就会产生不一致窗口。下表总结了常见场景及其风险等级：
| 场景 | 操作顺序 | 不一致窗口 | 风险等级 |
|---|---|---|---|
| 先更新数据库，后删除缓存 | DB更新 → 缓存删除 | DB更新后、缓存删除前，其他请求读到旧缓存 | 低（最终一致） |
| 先更新缓存，后更新数据库 | 缓存更新 → DB更新 | 缓存更新成功、DB更新失败，数据永久不一致 | 高（不可接受） |
| 先删除缓存，后更新数据库 | 缓存删除 → DB更新 | 缓存删除后、DB更新前，并发请求可能写入旧数据到缓存 | 中（需配合延迟双删） |
| 读写分离 + 缓存 | 主库写入 → 从库同步 → 缓存更新 | 主从同步延迟期间，缓存可能落后于主库 | 中（取决于同步延迟） |
业界最佳实践： 对于大多数业务场景，推荐采用“先更新数据库，后删除缓存”策略，配合消息队列或 binlog 监听做最终一致性兜底。对于强一致性要求场景（如库存、余额），应使用分布式锁或事务性消息确保缓存与数据库的原子更新。
1.6 缓存技术选型对比
下表从多个维度对比当前主流的缓存中间件，帮助你在架构设计初期做出合理选择：
| 维度 | Redis | Memcached | Caffeine (本地) | Tair |
|---|---|---|---|---|
| 数据结构 | 丰富（String/Hash/List/Set/Sorted Set/Stream） | 仅 Key-Value | Key-Value | 丰富（类似 Redis） |
| 持久化 | RDB/AOF 支持 | 不支持 | 不支持 | 支持 |
| 集群模式 | Redis Cluster / Codis / 哨兵 | 一致性哈希客户端分片 | 无（本地） | 自研分布式 |
| 单机 QPS | 8-10 万 | 10-12 万 | 百万级 | 8-10 万 |
| 一致性保证 | 最终一致（主从异步） | 最终一致 | 强一致（单机） | 可配置强一致 |
| 适用场景 | 复杂数据结构、排行榜、分布式锁、消息队列 | 简单 KV 缓存、Session 共享 | 热点数据本地缓存、二级缓存 | 阿里系大规模电商、强一致场景 |