系统设计 014：缓存深度实战：如何用 Cache 优雅优化数据库读写？

系统设计 014：缓存深度实战：如何用 Cache 优雅优化数据库读写？

• Bilibili 同步视频
• 一、Cache 的能力边界：能优化读，但写不动！
• • 1.1 读场景的优化原理
  • 1.2 写场景的挑战
• 二、两大缓存架构：选对架构，少走 90% 弯路
• • 2.1 Cache Aside 架构：业界通用的"万金油"
  • 2.2 Cache Through 架构：一体化的"专属方案"
  • 2.3 架构选择指南
• 三、写多读少场景：小厂的破局之道
• • 3.1 水平扩展策略
  • 3.2 数据库分片实战
  • 3.3 写优化补充方案
• 四、缓存实战：避坑指南与最佳实践
• • 4.1 常见缓存问题与解决方案
  • • 缓存穿透
    • 缓存雪崩
    • 缓存击穿
  • 4.2 缓存监控与调优
• 五、总结：Cache 优化的核心心法
• • 5.1 进阶思考
  • 5.2 工具推荐

Bilibili 同步视频

系统设计 014：缓存深度实战：如何用 Cache 优雅优化数据库读写？

在高并发系统设计里，数据库性能永远是绕不开的核心命题。而 Cache 作为性能优化的"神兵利器"，常常被我们用来应对海量请求、缓解数据库压力。但很多开发者都会陷入一个误区：Cache 真的能优化一切吗？ 今天我们就从读写场景、架构选型、落地实践三个维度，把 Cache 优化这件事讲透 ✨。

一、Cache 的能力边界：能优化读，但写不动！

先抛出一个直击本质的结论：Cache 可以极致优化数据库读操作，却对写操作"束手无策"。

为什么会有这样的差异？我们拆解底层逻辑：

• 读多场景下，请求直接从 Cache 读取，跳过数据库查询链路，响应速度呈指数级提升，系统瓶颈瞬间被打破 ⚡；

• 写多场景下，每次数据修改都必须同步更新数据库，Cache 不仅帮不上忙，还需要主动删除缓存数据，直接导致 Cache Miss，读取效率大幅下降。

更关键的是，多线程、多进程场景下，若强行同步更新 Cache 与数据库，极易出现 数据不一致：线程 A 刚更新完数据库，还未同步 Cache，线程 B 就写入新数据，最终 Cache 会存入旧数据，形成脏读，直接影响系统稳定性。

本质原因很简单：写操作的瓶颈在数据库本身，而非读取链路，Cache 无法绕过数据库完成写入，自然没有优化空间。

1.1 读场景的优化原理

当读请求到达时，系统会先检查缓存中是否存在所需数据：

// 伪代码示例：读缓存逻辑
public Object getData(String key) {
// 1. 先查缓存
Object data = cache.get(key);
if (data != null) {
return data; // 缓存命中
}

// 2. 缓存未命中，查数据库
data = database.query(key);

// 3. 写入缓存，设置过期时间
if (data != null) {
cache.set(key, data, 300); // 缓存5分钟
}

return data;
}

1.2 写场景的挑战

写操作必须保证数据一致性，常见的缓存更新策略有：

• 先更新数据库，再删除缓存（Cache-Aside）
• 先删除缓存，再更新数据库
• 双写策略（同时更新缓存和数据库）

无论哪种策略，写操作都无法避免数据库的IO瓶颈。

二、两大缓存架构：选对架构，少走 90% 弯路

既然 Cache 有明确边界，想要用好它，必须先吃透 两大主流缓存架构，根据业务场景精准选型 📌。

2.1 Cache Aside 架构：业界通用的"万金油"

这是目前互联网行业最常用的架构，核心逻辑是 分离管控、自由组合：

• 由 Web Server 统一调度，分别与 Cache、数据库通信；
• Cache 和数据库互不直接交互，各自独立运作；
• 典型代表：Memcache、Redis + MySQL，适配绝大多数业务场景。

优势明显：兼容性极强，Cache 和数据库可自由搭配，无论是传统关系型数据库，还是新型 NoSQL，都能无缝对接，小厂、大厂都能轻松落地。

适用场景：

• 电商商品详情页
• 用户个人信息
• 新闻资讯内容
• 社交动态信息

// Cache Aside 模式实现示例
public class CacheAsideService {
private Cache cache;
private Database database;

public Object read(String key) {
// 1. 先读缓存
Object value = cache.get(key);
if (value != null) {
return value;
}

// 2. 读数据库
value = database.select(key);

// 3. 写入缓存
if (value != null) {
cache.set(key, value, 300);
}

return value;
}

public void write(String key, Object value) {
// 1. 先更新数据库
database.update(key, value);

// 2. 删除缓存（而不是更新）
cache.delete(key);
}
}

2.2 Cache Through 架构：一体化的"专属方案"

与 Cache Aside 完全不同，它将 Cache 和数据库 封装为一个整体：

• 系统自动完成数据从 Cache 到数据库的同步；
• 典型代表：Redis（持久化模式）、一些云数据库的缓存层。

但它有明显短板：仅支持 Key-Value 存储，面对范围查询、复杂关联查询等场景，直接"力不从心"。这种架构通常只有大厂有能力自研定制，小厂很难承担研发与维护成本。

适用场景：

• 简单的配置信息存储
• 会话（Session）管理
• 排行榜数据
• 计数器功能

2.3 架构选择指南

综上，日常开发优先选 Cache Aside，简单通用、容错率高，是性价比最高的选择 ✅。

三、写多读少场景：小厂的破局之道

最棘手的问题来了：业务写多读少，Cache 失效，该如何优化？

答案很直白，却最实用：堆机器 + 数据库分片（Sharding）。

3.1 水平扩展策略

这不是"笨办法"，而是小厂 成本最低、风险最小、落地最快 的务实选择，后续结合 Sharding 精细化设计，性能还能再上一个台阶 📈。

3.2 数据库分片实战

// 简单的分片策略示例
public class ShardingStrategy {
// 基于用户ID的分片
public String getShardKey(String userId) {
int hash = userId.hashCode();
int shardCount = 4; // 假设有4个分片
int shardIndex = Math.abs(hash % shardCount);
return "shard_" + shardIndex;
}

// 获取对应的数据库连接
public Connection getShardConnection(String userId) {
String shardKey = getShardKey(userId);
return connectionPool.get(shardKey);
}
}

3.3 写优化补充方案

除了分片，还可以考虑：

• 批量写入：将多次写操作合并为一次批量操作
• 异步写入：非实时性要求的数据可以异步处理
• 消息队列缓冲：用消息队列承接写请求，平滑写入压力
• 冷热数据分离：将历史数据归档，减少主表压力

四、缓存实战：避坑指南与最佳实践

4.1 常见缓存问题与解决方案

缓存穿透

问题：查询不存在的数据，每次都打到数据库 解决方案：

• 布隆过滤器（Bloom Filter）预判
• 缓存空值（设置较短过期时间）

缓存雪崩

问题：大量缓存同时失效，请求直接打到数据库 解决方案：

• 设置不同的过期时间（加随机值）
• 热点数据永不过期
• 熔断降级机制

缓存击穿

问题：热点key过期，大量并发请求打到数据库 解决方案：

• 互斥锁（Mutex Lock）
• 逻辑过期（不设置物理过期时间）

// 解决缓存击穿的互斥锁实现
public Object getDataWithLock(String key) {
Object data = cache.get(key);
if (data != null) {
return data;
}

// 获取分布式锁
String lockKey = "lock:" + key;
if (tryLock(lockKey)) {
try {
// 双重检查
data = cache.get(key);
if (data != null) {
return data;
}

// 查询数据库
data = database.query(key);

if (data != null) {
cache.set(key, data, 300);
} else {
// 缓存空值，防止穿透
cache.set(key, EMPTY_VALUE, 60);
}

return data;
} finally {
releaseLock(lockKey);
}
} else {
// 等待其他线程加载
Thread.sleep(50);
return getDataWithLock(key);
}
}

4.2 缓存监控与调优

五、总结：Cache 优化的核心心法

最后用三句话总结今天的核心知识点，方便大家快速记忆：

5.1 进阶思考

缓存优化不是一劳永逸的，需要根据业务发展持续调整：

• 初期：简单Cache Aside，快速上线
• 成长期：引入读写分离，监控缓存命中率
• 成熟期：精细化分片，多级缓存架构
• 大规模期：定制化缓存方案，结合CDN等

5.2 工具推荐

• 本地缓存：Caffeine、Guava Cache
• 分布式缓存：Redis、Memcached
• 监控工具：Prometheus + Grafana
• 压测工具：JMeter、wrk

系统优化没有银弹，只有贴合业务、吃透原理，才能让 Cache 真正发挥价值，撑起高并发系统的性能天花板 🌌。

扩展阅读：

• Redis 官方文档
• 缓存设计模式
• 数据库分片实战

下期预告：我们将深入探讨「分布式锁的七种实现方式」，敬请期待！。