1. 缓存与大流量系统：缓存解决的核心问题、引入缓存的代价、多级缓存的出现背景
在高并发、大流量系统中，数据库直接面对海量请求是架构设计中最大的风险点。本章从系统边界出发，分析缓存解决的核心矛盾，明确引入缓存必须付出的代价，并阐述多级缓存架构出现的必然性。
1.1 系统边界与问题定义
大流量系统的典型特征是瞬时并发高、数据读取频繁、写操作相对较少（通常符合二八定律：20% 的数据承担 80% 的访问量）。系统面临的核心矛盾是：后端存储（数据库）的处理速度远低于前端请求的到达速度。
核心指标参考：单机 MySQL 在 OLTP 场景下 QPS 通常为 5k~10k（良好配置），而单体应用网关入口可能承受数十万乃至百万级别 QPS。数量级上的不匹配是缓存引入的根本驱动。
下表展示了大流量系统中各组件典型延迟与吞吐能力，直观体现系统瓶颈所在：
| 系统组件 | 典型延迟（单次请求） | 理想单机 QPS | 瓶颈等级 |
|---|---|---|---|
| 本地内存缓存（LRU Map） | 0.1 - 0.5 µs | > 10,000,000 | 极低 |
| 远程分布式缓存（Redis） | 1 - 5 ms | 50,000 - 100,000 | 低 |
| 本地磁盘（SSD） | 0.1 - 0.5 ms | 20,000 - 50,000 | 中 |
| 关系型数据库（MySQL） | 10 - 50 ms | 2,000 - 10,000 | 高 |
从延迟和 QPS 维度看，内存缓存的性能比数据库高出 2~3 个数量级。因此，缓存解决的核心问题就是：通过空间换时间，用读写速度更快的中间层，挡住大部分读请求对数据库的直接冲击。
1.2 核心收益：缓存解决了什么
- 降低响应延迟：热数据缓存在内存中，读取时间从几十毫秒降至微秒级。
- 保护后端数据库：减少数据连接数、慢查询和 IO 压力，延缓数据库扩容需求。
- 提升系统吞吐量：缓存层的高并发能力可承接数倍于 DB 的用户流量。
- 平滑突发流量：配合限流机制，缓存可以缓冲瞬时峰值，避免系统雪崩。
一句话总结：缓存是系统在大流量冲击下的第一道也是最重要的防线，没有缓存的系统在流量毛刺面前极其脆弱。
1.3 引入缓存的代价
缓存并非银弹。引入缓存意味着在系统架构中额外增加了一个有状态、有治理成本的中间层，必须正视以下代价：
| 代价维度 | 具体表现 | 典型风险等级 |
|---|---|---|
| 一致性问题 | 数据库更新后未同步清理缓存，导致读到脏数据；或 Cache Aside 模式中超时窗口内的不一致。 | 高 |
| 缓存击穿 / 穿透 | 热 Key 过期后瞬间大量请求落到数据库，或恶意请求针对不存在 Key 绕过缓存。 | 高 |
| 雪崩效应 | 大面积缓存同时失效，引发数据库流量洪峰导致宕机。 | 极高 |
| 运维复杂度 | 增加缓存集群部署、监控、容量规划（如 Redis 内存管理与淘汰策略）成本。 | 中 |
| 资源开销 | 缓存需要占用大量内存，内存价格远高于磁盘。 | 低 |
| 业务逻辑耦合 | 代码须侵入式处理缓存清理、失效策略与序列化协议。 | 中 |
常见误区：团队往往只看到缓存带来的 QPS 提升，却忽略了一致性治理与故障转移的设计。没有完整兜底机制的缓存，是线上事故的主要诱因之一。
1.4 多级缓存的出现背景
单层缓存架构（如只依赖于一个 Redis 集群）存在明显的系统边界缺陷：
- 远程网络开销无法消除：即使 Redis 再快，每次读取仍需一次 TCP 通信，延迟普遍在 1~5ms 之间。
- 单点热点问题放大：单个热 Key 造成单节点高负载，甚至引发集群带宽瓶颈。
- 缓存层本身成为瓶颈：当整体 QPS 超过 Redis 集群上限时，系统依然会回源到数据库。
因此，架构演进的必然方向是：将缓存按照访问频率与延迟要求分层部署，形成多级缓存体系。
架构逻辑：将热数据尽可能推进到最贴近计算节点的位置。L1（本地堆内缓存）处理超高频请求，L2（分布式缓存）处理次高频请求，L3（数据库）作为最终一致性底座。每向下一层，成本更低、容量更大、延迟更高。
典型的多级缓存链路具备以下分层结构：
1.5 多级缓存分层模型与职责
1.6 选型权衡与落地原则
| 决策维度 | 选项 | 适用场景 |
|---|---|---|
| L1 本地缓存选型 | Caffeine / Guava / 自实现 LRU | 追求极低延迟，数据一致性要求可放宽（容忍秒级延迟） |
| L2 分布式缓存选型 | Redis Cluster / 自建 Memcached | 需要大容量共享缓存，跨进程跨实例统一失效 |
| 失效策略 | TTL / 主动清除 / 版本号对比 | 读多写少用 TTL；写频繁用主动清除 + 消息队列解耦 |
| 序列化协议 | ProtoBuf / JSON / MessagePack | 追求性能选 ProtoBuf；调试友好可选 JSON |
落地原则：
1. 每层缓存必须有合适的淘汰策略（LRU / TTL），避免内存无限增长。
2. 必须提前设计缓存预热（Warmup）方案，系统上线后先冷启动打满缓存再开放流量。
3. 必须实现熔断降级：当某一级缓存不可达（如 Redis 宕机）时，自动穿透到下一层，而不是阻塞等待超时。
1. 每层缓存必须有合适的淘汰策略（LRU / TTL），避免内存无限增长。
2. 必须提前设计缓存预热（Warmup）方案，系统上线后先冷启动打满缓存再开放流量。
3. 必须实现熔断降级：当某一级缓存不可达（如 Redis 宕机）时，自动穿透到下一层，而不是阻塞等待超时。
1.7 验收标准（第1章交付检查清单）
- ✅ 团队能够清晰解释“缓存解决的核心矛盾”——解决延迟差与吞吐差。
- ✅ 团队已识至少 3 项缓存引入的主要代价（一致性、击穿、雪崩）。
- ✅ 已完成系统现状测绘：评估现有系统 QPS、DB 极限、热点 Key 分布。
- ✅ 确定采用多级缓存架构（L1+L2+L3 最少三层）并初步决策 L1 与 L2 组件选型。
- ✅ 输出一份简明的缓存治理策略文档（包括失效机制、降级方案、预热计划）。
逐章警告：如果尚未建立明确的缓存分层边界与故障降级流程，不建议直接在生产环境部署多级缓存。先在小范围灰度验证后再全量推广。