缓存设计

日调用量突破 10 万次

选了 302 重定向后，每次跳转都要查数据库。起初还好，但随着用户增多，问题开始显现。

某天早上，监控告警响了。数据库 CPU 使用率飙到 60%。

我打开日志，看到密密麻麻的查询：

数据设计要点

• 查询目标是用短码快速找到目标链接、状态或统计结果，避免在跳转路径上做大范围扫描。

短链接服务的访问特点，我总结了一下：

读取 vs 写入比例：1000:1

典型的访问模式：
- 创建短链接：1 次
- 重定向跳转：1000 次+

一个短链接被创建后，可能被访问成千上万次。如果每次都查数据库，数据库很快就扛不住。

我知道，不能再每次都查数据库了。

第一次接触 Redis

作为前端出身的开发者，这是我第一次接触 NoSQL。

我花了一天学习 Redis。它和 MySQL 完全不同：

MySQL（关系型数据库）：

• 数据存在磁盘上
• 查询需要解析 SQL、优化执行计划
• 单次查询耗时：10-50ms
• 适合复杂查询、事务

Redis（内存数据库）：

• 数据存在内存中
• 简单的 Key-Value 操作
• 单次查询耗时：0.1-2ms
• 适合高速读写

我在本地启动 Redis，尝试基本操作：

落地思路

• 这里省略具体语法，只保留设计层面的职责边界。
• 读这段时重点看：输入是什么、系统做哪些判断、状态如何变化、失败时如何兜底。

简单，直接，快速。

这就是我需要的。

缓存架构设计

最简单的方案：查询前先查 Redis，命中则直接返回，未命中则查数据库并回填缓存。

架构图：

                    用户请求
                       ↓
                ┌──────────────┐
                │  API 服务    │
                └──────────────┘
                       ↓
           ┌───────────┴───────────┐
           ↓                       ↓
    ┌──────────────┐        ┌──────────────┐
    │  Redis 缓存  │  ←───  │   MySQL      │
    │  (热数据)    │  回写   │  (全量数据)  │
    └──────────────┘        └──────────────┘

这种模式叫 Cache-Aside（旁路缓存）：

1. 先读缓存，命中直接返回
2. 未命中读数据库
3. 写入缓存，设置过期时间

这个流程拆开看：

落地思路

• 这里省略具体语法，只保留设计层面的职责边界。
• 读这段时重点看：输入是什么、系统做哪些判断、状态如何变化、失败时如何兜底。

为什么设置过期时间？

内存有限，不能无限存储。过期时间让不常用的数据自动清理。

落地思路

• 这里省略具体语法，只保留设计层面的职责边界。
• 读这段时重点看：输入是什么、系统做哪些判断、状态如何变化、失败时如何兜底。

缓存 Key 的设计：

落地思路

• 这里省略具体语法，只保留设计层面的职责边界。
• 读这段时重点看：输入是什么、系统做哪些判断、状态如何变化、失败时如何兜底。

效果验证

上线后，我盯了一天监控数据。

结果超出预期：

92% 的请求从缓存返回，只有 8% 需要查数据库。

我用压测结果验证这个判断：

落地思路

• 这里省略具体语法，只保留设计层面的职责边界。
• 读这段时重点看：输入是什么、系统做哪些判断、状态如何变化、失败时如何兜底。

数据库压力骤降，系统稳定了。

缓存一致性：新问题出现

但缓存带来了新问题。

某天用户反馈：“我修改了原始 URL，但跳转还是旧的地址。”

我检查数据库，确实是新地址。但 Redis 里还是旧的。

问题根源：用户修改了数据，但缓存没有同步更新。

时间线：
1. 短链接 a1b2c3 指向 https://old-url.com
2. 缓存存储：url:a1b2c3 = https://old-url.com（1 小时过期）
3. 用户修改：a1b2c3 改为指向 https://new-url.com
4. 数据库已更新，但缓存还是旧的
5. 1 小时内，所有请求都跳转到旧地址

这是典型的缓存一致性问题。

解决方案 1：主动失效

修改数据时，主动删除缓存：

落地思路

• 这里省略具体语法，只保留设计层面的职责边界。
• 读这段时重点看：输入是什么、系统做哪些判断、状态如何变化、失败时如何兜底。

下次查询时，缓存未命中，从数据库加载最新数据。

解决方案 2：双写

修改数据时，同时更新缓存：

落地思路

• 这里省略具体语法，只保留设计层面的职责边界。
• 读这段时重点看：输入是什么、系统做哪些判断、状态如何变化、失败时如何兜底。

我选择主动失效

原因：

1. 更简单：不用考虑新旧值
2. 更安全：数据库是唯一真相
3. 更灵活：修改后可能不会立即访问，删除缓存节省内存

删除操作也有个问题：如果删除失败怎么办？

我加了重试：

落地思路

• 这里省略具体语法，只保留设计层面的职责边界。
• 读这段时重点看：输入是什么、系统做哪些判断、状态如何变化、失败时如何兜底。

缓存穿透：恶意攻击

解决了缓存一致性，又出现了新问题。

监控显示大量短链接码不存在：

访问不存在的短链接：
- url:xyz123 → 缓存没有 → 查数据库 → 也没有
- url:abc999 → 缓存没有 → 查数据库 → 也没有
- url:random → 缓存没有 → 查数据库 → 也没有

有人用随机短链接码恶意攻击。

每次都穿透缓存，打到数据库。这就是缓存穿透。

解决方案：缓存空值

落地思路

• 这里省略具体语法，只保留设计层面的职责边界。
• 读这段时重点看：输入是什么、系统做哪些判断、状态如何变化、失败时如何兜底。

效果：

空值缓存过期时间设置为 5 分钟：既能防护，又不会太久影响正常创建。

缓存雪崩：集体过期

还有一个隐患：大量缓存同时过期。

场景：
- 10:00 批量创建 1000 个短链接，缓存过期时间都是 1 小时
- 11:00 这 1000 个缓存同时过期
- 11:00:01 突然 1000 个请求打到数据库
- 数据库崩溃

这就是缓存雪崩。

解决方案：随机过期时间

落地思路

• 这里省略具体语法，只保留设计层面的职责边界。
• 读这段时重点看：输入是什么、系统做哪些判断、状态如何变化、失败时如何兜底。

每个缓存的过期时间都有差异，避免同时失效。

完整方案

我把所有方案整合到一起：

落地思路

• 这里省略具体语法，只保留设计层面的职责边界。
• 读这段时重点看：输入是什么、系统做哪些判断、状态如何变化、失败时如何兜底。

这套方案覆盖了：

1. Cache-Aside 模式：先查缓存，未命中查数据库
2. 缓存空值：防止穿透
3. 随机过期：防止雪崩
4. 主动失效：保证一致性

小结

核心要点：

1. Cache-Aside 模式最常用
2. 缓存空值防止穿透
3. 随机过期时间防止雪崩
4. 修改数据时主动删除缓存

缓存解决了大部分性能问题。数据库 CPU 从 60% 降到 15%，响应时间从 50ms 降到 8ms。

但 301 和 302 的选择，在有了缓存后，又有了新的考量……

练习题

练习 1

为什么缓存空值可以防止缓存穿透？空值缓存的过期时间应该设置多久？

攻击场景：
- 攻击者访问不存在的 short_code: "xyz123"
- 缓存中没有 → 查数据库 → 也没有
- 每次都打到数据库

防御方案：
- 第 1 次查询后，缓存空值：redis.setex("url:xyz123", 300, "__NULL__")
- 第 2-100 次查询：直接从缓存返回 NULL
- 300 秒后空值过期，下次查询才会再次访问数据库

练习 2

设计一个支持热点数据自动识别的缓存策略。