分布式缓存：缓存的三种读写模式及分类

文章目录

缓存全景图
Pre
缓存读写模式概述
1. Cache Aside（旁路缓存）
- 工作流程
- 优缺点
2. Read/Write Through（读写穿透）
- 工作流程
- 优缺点
- 典型场景
3. Write Behind Caching（异步写回）
- 工作流程
- 优缺点
- 典型场景
缓存分类及常用组件
- 1. 按宿主层次分类
- 2. 按存储介质分类
场景对比与权衡
小结

在这里插入图片描述

缓存全景图

在这里插入图片描述

Pre

每日一博 - 图解5种Cache策略

架构思维：缓存层场景实战_读缓存（下）

缓存读写模式概述

在业务系统中，引入缓存主要为了降低数据库压力、提升响应性能，但也带来了数据一致性和维护成本的挑战。

根据缓存和数据库的更新策略，常见有三种读写模式：

Cache Aside（旁路缓存）
Read/Write Through（读写穿透）
Write Behind Caching（异步缓存写入）

在这里插入图片描述

下面逐一详细介绍。

1. Cache Aside（旁路缓存）

工作流程

在这里插入图片描述

写操作：
1. 应用先更新数据库
2. 删除 Cache 中对应的 key
3. 由数据库变更日志或下游 Trigger 驱动重新计算并回写缓存
读操作：
1. 应用先查询 Cache
2. 若未命中，则加载数据库数据
3. 将结果写入 Cache，并返回给调用方

写 ➔ Update DB ➔ DEL cache[key] 
读 ➔ GET cache[key] ➔ Miss ➔ Query DB ➔ SET cache[key] ➔ Return

优缺点

优点
- 以数据库为准，强一致性风险低
- 缓存回写采用延迟（Lazy）计算，可灵活处理复杂业务
缺点
- 业务端需同时维护 Cache 和 DB 访问逻辑，代码复杂度高
- 触发缓存回写依赖日志或 Trigger，增加组件依赖

2. Read/Write Through（读写穿透）

工作流程

由缓存存储服务（Cache Service）统一代理读写，业务应用只与存储服务交互。

在这里插入图片描述

如上图，对于 Cache Aside 模式，业务应用需要同时维护 cache 和 DB 两个数据存储方，过于繁琐，于是就有了 Read/Write Through 模式。在这种模式下，业务应用只关注一个存储服务即可，业务方的读写 cache 和 DB 的操作，都由存储服务代理。存储服务收到业务应用的写请求时，会首先查 cache，如果数据在 cache 中不存在，则只更新 DB，如果数据在 cache 中存在，则先更新 cache，然后更新 DB。而存储服务收到读请求时，如果命中 cache 直接返回，否则先从 DB 加载，回种到 cache 后返回响应。

写操作：
1. 存储服务查 Cache
2. 若命中，先更新 Cache，再同步写入 DB
3. 若未命中，仅更新 DB
读操作：
1. 存储服务查 Cache
2. 命中则直接返回
3. 未命中则加载 DB，然后回写 Cache，再返回

写 ➔ 存储服务(GET cache) ➔ Hit: SET cache + Update DB➔ Miss: Update DB
读 ➔ 存储服务(GET cache) ➔ Miss ➔ Load DB ➔ SET cache ➔ Return

优缺点

优点
- 业务端代码只关注存储服务，隔离性好
- 仅为“热”数据更新缓存，内存利用率高
缺点
- 写路径较 Cache Aside 更同步，写延迟略高

典型场景

有明显“热”与“冷”数据区分的业务

3. Write Behind Caching（异步写回）

工作流程

由缓存存储服务（Cache Service）统一代理读写，业务应用只与存储服务交互。

在这里插入图片描述

Write Behind Caching 模式与 Read/Write Through 模式类似，也由数据存储服务来管理 cache 和 DB 的读写。不同点是，数据更新时，Read/write Through 是同步更新 cache 和 DB，而 Write Behind Caching 则是只更新缓存，不直接更新 DB，而是改为异步批量的方式来更新 DB。该模式的特点是，数据存储的写性能最高，非常适合一些变更特别频繁的业务，特别是可以合并写请求的业务，比如对一些计数业务，一条 Feed 被点赞 1万次，如果更新 1万次 DB 代价很大，而合并成一次请求直接加 1万，则是一个非常轻量的操作。但这种模型有个显著的缺点，即数据的一致性变差，甚至在一些极端场景下可能会丢失数据。比如系统 Crash、机器宕机时，如果有数据还没保存到 DB，则会存在丢失的风险。所以这种读写模式适合变更频率特别高，但对一致性要求不太高的业务，这样写操作可以异步批量写入 DB，减小 DB 压力。

与 Read/Write Through 相似，均由存储服务管理：

写操作：
1. 只更新 Cache
2. 存储服务后台异步批量合并写 DB
读操作：
同 Read/Write Through 模式

写 ➔ 存储服务(SET cache) ➔ Async Batch Write → DB
读 ➔ GET cache ➔ Miss ➔ Load DB ➔ SET cache ➔ Return

优缺点

优点
- 写性能最高，适合超高并发、可合并请求的场景
- 如计数类业务，将多次加操作合并为一次 DB 更新
缺点
- 数据一致性最差，且在崩溃/宕机时可能丢失未刷盘的数据

典型场景

对一致性要求不高，但写入频率极高的业务
如热点计数、流量统计等

我们可以看到缓存的三种读写模式各有优劣，不存在最佳模式。实际上，我们也不可能设计出一个最佳的完美模式出来，如同空间换时间、访问延迟换低成本一样，高性能和强一致性从来都是有冲突的，系统设计从来就是取舍，随处需要 trade-off。

如何根据业务场景，更好的做 trade-off，从而设计出更好的服务系统。

缓存分类及常用组件

1. 按宿主层次分类

本地 Cache（进程内）：
- 组件：Guava Cache、Ehcache（嵌入模式）
- 优势：极低延迟、零网络开销；
- 劣势：随进程重启丢失、容量受限。
进程间 Cache（同机独立进程）：
- 组件：独立部署的 Redis/Memcached 实例（与业务进程同机）
- 优势：重启不丢数据、减少部分网络延迟；
- 劣势：本机资源竞争，运维较复杂。
远程 Cache（跨机部署）：
- 组件：集群化的 Redis/Memcached/Pika
- 优势：容量与扩展性最佳；
- 劣势：网络延迟与带宽瓶颈。

2. 按存储介质分类

内存型缓存：
- 数据驻留内存，读写延迟微秒级；
- 重启或崩溃后数据丢失。
- 典型：Memcached、Redis（无 AOF/RDB 时）。
持久化型缓存：
- 数据写入 SSD/RocksDB 等介质，容量大一个量级；
- 重启不丢失，但读写延迟高出 1–2 个数量级。
- 典型：Pika、基于 RocksDB 的缓存方案。