内容纲要
标签：Cache, 缓存策略, 读写策略, 系统设计, 架构设计, 性能优化, 数据一致性, 分布式系统
本文对缓存所有读写策略的系统化总结，会按缓存类型 → 写策略 → 读策略 → 场景优缺点的顺序，把常见的缓存读写策略全覆盖整理出来，方便做架构选型或优化。
引言
在高并发分布式系统中，缓存是性能优化的核心组件。合理的缓存读写策略不仅能降低数据库压力，还能平衡数据一致性与性能。然而，不同业务场景对缓存的读写模式、一致性要求、容错能力都各不相同，选择合适的策略尤为关键。
本文将系统化梳理缓存写策略、读策略、失效更新策略及其组合方式，并给出适用场景分析与架构建议。
缓存读写策略大全
1. 缓存写策略（Write Strategies）
| 策略 | 描述 | 优点 | 缺点 | 场景 |
|---|---|---|---|---|
| Write Through（写穿） | 数据先写缓存，再写数据库（同步写）。保证缓存和数据库一致。 | 数据一致性高；读缓存总是最新 | 写延迟高；写放大 | 适合强一致性场景（金融、订单） |
| Write Around（写绕过） | 数据直接写数据库，缓存不更新，等下次读取时再从数据库加载到缓存。 | 写性能高；减少缓存污染 | 首次读会慢；数据可能短期不在缓存 | 适合冷数据多、写频率高的场景 |
| Write Back（写回/延迟写） | 先写缓存，标记脏数据，异步批量写入数据库 | 写性能极高；减少数据库压力 | 容易丢数据（缓存挂掉）；实现复杂 | 适合高吞吐写入、不要求强一致性（日志、计数器） |
| Read-Through + Write-Through | 读、写都通过缓存层代理，缓存自己负责加载和写入数据库 | 应用代码简单；一致性可控 | 缓存层实现复杂 | 适合有专业缓存代理（Ehcache、Hazelcast） |
1.1 Write Through（写穿）
流程：应用写数据 → 缓存层 → 同步写数据库
优点：
- 数据一致性强
- 缓存命中总是最新数据
缺点： - 写延迟高
- 写放大效应明显
适用场景：金融交易、库存扣减、强一致性业务
1.2 Write Around（写绕过）
流程：应用直接写数据库 → 缓存不更新，下次读时再回填
优点：
- 写性能高
- 缓存避免冷数据污染
缺点： - 首次读取慢
- 数据短期不在缓存中
适用场景：写频率高、数据冷热不均（如日志系统、后台批量写入）
1.3 Write Back（写回）
流程：应用写缓存 → 标记脏数据 → 异步批量写数据库
优点：
- 写性能极高
- 数据库压力小
缺点： - 缓存宕机可能丢数据
- 实现复杂
适用场景：高写入吞吐、可接受一定数据丢失（如计数器、排行榜）
1.4 Read-Through + Write-Through
应用只与缓存交互，缓存代理层负责加载与写入数据库。
适用于统一缓存服务架构（如 Ehcache、Hazelcast、Memcached Proxy）
2. 缓存读策略（Read Strategies）
| 策略 | 描述 | 优点 | 缺点 | 场景 |
|---|---|---|---|---|
| Cache Aside（旁路缓存） | 读时先查缓存，没命中再查数据库并写入缓存（常见）。 | 简单易用；灵活 | 一致性依赖手动更新；可能读到旧数据 | 互联网大多数读多写少场景 |
| Read-Through | 应用只查缓存，由缓存负责从数据库加载。 | 应用无感知；一致性可控 | 缓存层需要代理能力 | 分布式缓存产品（Redis + 缓存代理） |
| Look Aside | 应用先查缓存，缓存未命中时应用自己查数据库并更新缓存 | 灵活 | 开发者维护逻辑；一致性需自己处理 | 大多数手写 Redis 缓存逻辑 |
| Refresh Ahead（提前刷新） | 缓存快过期时，后台线程提前异步刷新 | 避免缓存失效时的抖动 | 实现复杂；需预测访问 | 高频访问数据（首页、热点榜单） |
2.1 Cache Aside（旁路缓存）
流程：应用读缓存 → 未命中 → 读数据库 → 回填缓存
优点：
- 实现简单
- 灵活控制缓存逻辑
缺点： - 一致性需手动维护
适用场景：互联网常见读多写少业务（商品详情、用户资料）
2.2 Read-Through
流程：应用只读缓存，未命中时缓存层自动回源数据库
优点：
- 应用无感知
- 缓存与数据库交互透明化
缺点： - 缓存层实现复杂
2.3 Refresh Ahead（提前刷新）
在缓存快过期前，由后台异步刷新数据，避免访问高峰时命中失效。
适用场景：热点数据（首页推荐、排行榜）
3. 缓存更新与失效策略
| 策略 | 描述 | 优点 | 缺点 |
|---|---|---|---|
| 定时过期（TTL） | 每个键都有过期时间 | 简单；防缓存脏数据 | 热点数据可能频繁失效 |
| 主动更新（Cache Invalidation） | 数据库变更时主动删除或更新缓存 | 一致性高 | 增加写操作逻辑复杂度 |
| 双删策略（Double Delete） | 更新数据库前后分别删一次缓存 | 避免并发脏数据 | 写延迟变高 |
| 异步消息驱动更新 | DB 更新时发消息队列，由消费者刷新缓存 | 解耦；一致性可控 | 增加 MQ 成本与延迟 |
4. 组合型策略（常见搭配）
| 组合 | 说明 | 适用场景 |
|---|---|---|
| Cache Aside + TTL | 最常见组合，读多写少 | 大部分互联网业务、大多数读多写少系统 |
| Write Through + Read-Through | 缓存代理全托管 | 企业内存计算平台、企业统一缓存平台 |
| Write Back + Refresh Ahead | 写多读多，性能敏感 | 日志、排名统计、实时排行榜、计数器 |
| 双删策略 + Cache Aside | 高并发强一致 | 电商库存、支付系统 |
5. 图解（缓存读写流程全景）
[用户]
↓
(缓存) ←→ (数据库)
↑ ↑
写 读- Write Through: 写缓存 → 同步写 DB
- Write Around: 写 DB，不更新缓存
- Write Back: 写缓存 → 异步写 DB
- Cache Aside: 读缓存，miss → 查 DB → 回填缓存
6. 架构落地建议
- 优先明确一致性要求：强一致用 Write Through，最终一致可用 Cache Aside + TTL
- 热点数据提前刷新：结合 Refresh Ahead 避免缓存雪崩
- 更新策略优于过期策略：减少短期内大量缓存失效
- 分业务线选策略：读多业务和写多业务可用不同缓存模式
结语
缓存策略并非“一招鲜”，而是要结合业务访问模式、一致性需求、延迟容忍度来设计。在系统架构中提前规划缓存的读写模式，不仅能提升性能，还能降低维护成本。
