缓存的读写模式有哪些？Cache Aside、Read/Write Through、Write Behind 的区别？
简化版
常见缓存模式有 Cache Aside、Read Through、Write Through、Write Behind。Cache Aside 最常用，由业务代码自己读写缓存：读缓存未命中查库回填，写数据库后删除缓存。Read/Write Through 把缓存当代理，由缓存层负责读写数据库。Write Behind 先写缓存再异步刷库，性能高但数据可靠性风险更大。
详细版
| 模式 | 读流程 | 写流程 | 特点 |
|---|---|---|---|
| Cache Aside | 应用读缓存，未命中查库回填 | 应用更库后删缓存 | 最常用，控制灵活 |
| Read Through | 应用只读缓存，缓存未命中自己加载 DB | 通常配合 Write Through | 应用简单，缓存层复杂 |
| Write Through | 应用写缓存，缓存同步写 DB | 写缓存成功才算成功 | 一致性较好，写延迟高 |
| Write Behind | 应用写缓存，缓存异步刷 DB | 先返回，后台批量写库 | 性能高，宕机可能丢数据 |
互联网业务中最常见的是 Cache Aside，因为它简单、灵活、容易落地。Write Behind 适合能容忍丢失或有日志兜底的高吞吐场景，不适合资金、库存这类强约束数据。
完整版教学
一、为什么要区分缓存模式
缓存不是只有“先查 Redis”这么简单。读的时候谁负责加载数据库？写的时候先写数据库还是先写缓存？缓存和数据库的同步由业务做，还是由缓存组件做？这些问题组合起来，就形成不同缓存模式。
模式没有绝对优劣，只有适用场景。面试里要讲清每种模式的数据流和取舍。
二、Cache Aside 为什么最常见
Cache Aside 也叫旁路缓存。应用先读缓存，没命中再查数据库并写回缓存。写操作时，应用先更新数据库，再删除缓存。缓存只是旁路加速层，数据库仍然是权威数据源。
它的优势是简单，任何 Redis + DB 系统都能做；业务可以精确控制 key、TTL、删除时机和异常处理。缺点是应用代码要处理缓存逻辑，并且缓存一致性要靠删除、双删、binlog、TTL 等机制治理。
三、Read Through 和 Write Through
Read Through 中，应用只和缓存层交互。缓存未命中时，缓存层自己去数据库加载数据并返回。Write Through 中，应用写缓存，缓存同步把数据写到数据库，两个都成功才返回。
这类模式把复杂性放进缓存层或数据访问层，应用更干净。一致性也更集中。但它要求缓存层知道如何访问数据库、如何序列化、如何处理失败，工程组件复杂度更高。
四、Write Behind 的性能和风险
Write Behind 也叫 Write Back。应用写缓存后立即返回，缓存层异步、批量把变更刷到数据库。它性能很好，因为写请求不等待数据库，而且可以合并多次写。
风险也明显：如果缓存还没刷库就宕机，数据可能丢失。要降低风险，需要 WAL 日志、消息队列、持久化、重放机制。它适合计数、日志、行为数据、可重放数据，不适合扣款和强一致库存。
五、怎么在项目里选择
大多数业务系统默认选 Cache Aside。它让数据库保持权威，缓存作为可删除、可重建的加速层，故障时更容易降级。读多写少、缓存逻辑统一的平台型系统，可以考虑 Read Through。写吞吐极高且能容忍异步落库的场景，可以考虑 Write Behind，但必须有可靠日志兜底。
六、面试追问与工程边界
面试官常会问“为什么国内业务更常见 Cache Aside”。因为它对基础设施要求低，Redis 和数据库不需要深度耦合，业务方能清楚控制缓存 key、TTL、删除策略和异常兜底。缺点是每个业务都要写缓存逻辑，所以大公司会沉淀统一缓存组件。
Write Behind 的回答要特别谨慎。它不是普通业务写库的万能优化，而是把可靠性压力转移到异步刷盘链路。只有当变更可重放、有日志兜底、允许延迟落库时才适合，否则缓存宕机可能造成真实数据丢失。
七、常见误区与追问
这道题不能只背概念，要把「缓存读写模式」放回真实分布式系统里解释：参与方是谁、状态怎么流转、失败后怎么恢复，以及它在一致性、性能、可用性之间做了什么取舍。
| 回答层次 | 要讲清的内容 | 容易漏掉的边界 |
|---|---|---|
| 核心结论 | Cache Aside 由应用读写缓存，Read/Write Through 由缓存层代理加载写入，Write Behind 异步落库吞吐高但风险大 | 不要停在名词解释 |
| 流程机制 | 读缓存 -> 未命中查数据库 -> 回填缓存 -> 写请求更新数据库 -> 删除或更新缓存 | 说明触发方、存储方、确认点和兜底 |
| 工程取舍 | Cache Aside 读取流程是先查缓存，未命中查库再回填；写入通常先写库再删缓存 | 缓存提升吞吐但会引入旧值、热点、内存和失效风暴问题 |
缓存读写模式 面试拆解：
1. 读缓存
2. 未命中查数据库
3. 回填缓存
4. 写请求更新数据库
5. 删除或更新缓存记忆钩子：先说明缓存承担的读写压力，再拆穿透、击穿、雪崩、热点、一致性和淘汰策略；回答时要紧扣「缓存读写模式」这道题，不要把相邻概念混成一段泛泛的分布式套话。
- 误区：所有缓存模式写法一样。 不同模式对一致性、延迟和复杂度的责任边界不同。
- 误区：Write Behind 一定更好。 异步落库吞吐高，但宕机可能丢数据，适合可重放场景。
- 误区：Cache Aside 不需要处理并发。 缓存击穿、旧值回填和删除失败都要处理。
- 追问：最常用模式是什么？ 业务系统常用 Cache Aside，因为简单可控。
- 追问：Read Through 优点是什么？ 应用不关心加载细节，由缓存层统一加载。
- 追问：写模式怎么选？ 看一致性要求、写入吞吐和数据丢失容忍度。
八、加强记忆
Cache Aside 是应用自己管缓存，读未命中查库回填，写更库后删缓存，最常用。Read/Write Through 是缓存层代理数据库，应用更简单但缓存层更复杂。Write Behind 是先写缓存异步刷库，性能最高但可靠性风险最大。选择时看谁是权威数据源、能否接受异步落库、失败后能不能重放。