回写模式（Write Back Pattern），又称“写后写入（Write Behind）”，是性能最极致但一致性风险最高的缓存更新模式。
其核心思想是：写操作只更新缓存，不立即更新数据库。缓存层会在后台异步、批量地将变更的数据同步到数据库中。
核心操作流程
一、写操作 (Write Path)
sequenceDiagram participant App as 应用程序 participant Cache as 缓存 participant DB as 数据库 App->>Cache: 1. 发起写请求 Cache->>Cache: 2. 更新内存数据 Cache-->>App: 3. 立即返回成功 Note over Cache, DB: 异步/批量同步 Cache->>DB: 4. 后台刷入数据库 (Flush)
- 立即响应：应用程序将数据写入缓存后，缓存层立即返回成功，无需等待数据库 IO。
- 变更标记：缓存通常会将该数据标记为“脏（Dirty）”，表示其尚未同步到数据库。
- 异步刷盘：满足特定条件（如时间间隔、脏数据量达到阈值、缓存淘汰前）时，缓存层异步地将变更写入数据库。
二、读操作 (配套模式)
由于 Write Back 模式下数据可能尚未进入数据库，读操作必须通过 直读模式 (Read Through) 来确保一致性：
- 读请求先访问缓存。
- 如果缓存命中，拿到的就是最新的“脏数据”，这保证了即使 DB 还没更新，应用读到的也是对的。
关键考量：极致性能与数据丢失风险
一、极致的写入性能
这是 Write Back 的最大优势。由于它将数据库的随机、频繁写入转变为顺序、批量的异步写入，极大地减轻了数据库的 IO 压力，并将应用层的写延迟（Latency）降低到了纳秒级。
二、数据丢失风险
这是该模式最致命的缺点。如果缓存层（如 Redis 或操作系统 Page Cache）在数据刷入数据库之前发生宕机、掉电或重启，由于数据仅存在于内存中，所有尚未刷盘的变更都将永久丢失。
三、一致性复杂性
由于数据库中的数据在很长一段时间内都是“旧值”，任何直接访问数据库的操作（如报表统计、旧系统读取）都会拿到错误的数据。因此，该模式要求整个系统的读写路径必须高度统一在缓存层。
适用场景
- 高频写场景：如直播间热点数据的点赞数、游戏中的瞬时状态变更、操作系统的文件系统写入缓存。
- 数据库 IO 瓶颈严重：当写压力远超数据库承载能力时，利用
Write Back进行“削峰填谷”。 - 对丢失有一定容忍度：如非核心业务的监控指标、日志统计等。
总结
- 优点：写性能极佳（接近内存速度）；有效合并写请求（多次修改合并为一次入库），减轻 DB 压力。
- 缺点：存在数据丢失风险；实现复杂度高；数据库数据存在明显滞后。
- 适用场景：对性能要求极高、写负载巨大且能通过其他手段补偿或容忍少量数据丢失的业务。