题目重点：比较同步写后端与延迟刷盘的延迟、可靠性、写放大和失效语义。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练版有 cache 与 durable backend 两层，讨论写成功给客户端的确认条件。若实际场景是 CPU cache，协议、内存屏障和一致性细节不同。
- 需明确故障模型：仅 cache 进程崩溃，还是节点/机房掉电；‘durable’也取决于 backend 的持久化承诺。
解题路线
- Write-through：每次写同时更新缓存与后端，通常等后端确认才回成功；读缓存可快，写受后端延迟影响。失败时不能在后端未成功却对客户端声称已持久化，需处理缓存回滚/失效。
- Write-back：先改缓存并标 dirty，稍后异步刷后端；写响应低延迟、可合并多次覆盖，但在落盘前缓存故障会丢已确认数据，除非有 WAL/复制/电池保护等可靠缓冲。
- 要定义读取一致性：dirty 数据应优先从缓存读；后端或其他节点读可能暂时看到旧值。刷写按 key 版本/顺序，失败重试和 backpressure 需要防无限 dirty 堆积。
- Write-through 并不自动解决多缓存失效：另一节点 cache 可能仍有旧值，需失效消息、版本或 TTL。选择策略以写延迟、持久性 SLA、写比率和故障恢复成本决定。
手动走一遍
用户把 key 从 A 改为 B：write-through 等后端 B 写成后确认；write-back 可先在 cache 返回 B，后端暂仍是 A。若此刻 cache 丢电且无可靠日志，已向用户确认的 B 会丢失。
规模与取舍
单次写本地缓存操作近似 O(1)；write-through 响应延迟包含后端 RTT，write-back 响应更短但累积 dirty key 占 O(D) 内存/可靠缓冲，后台刷写吞吐必须覆盖平均写入率。无题目 QPS 数值。
易错点与追问
容易失分的边界
- 把 write-back 说成完全不写后端。
- 后端未成功仍把 write-through 回成功。
- write-back 无 WAL/复制却承诺崩溃不丢已确认写。
- 忽略其它节点的旧缓存。
- CPU 缓存术语与应用缓存语义不区分。
继续深挖
- 后端暂时不可用时两策略怎么处理？
- dirty 缓存达到内存上限怎么办？
- 多节点写同一 key 如何保证顺序？
- write-around 与 write-behind 有何联系？
