架构师比较两种缓存写策略：方案甲在更新缓存时同步写入后端数据库，后端成功后才返回；方案乙先更新缓存并快速返回，再异步批量写入后端。两者分别更接近（）。
Write-through在写缓存的同时同步更新后端，写延迟较高但后端状态及时；Write-behind把后端写入异步化，可合并批量操作并降低前台延迟，但要处理队列积压、失败和数据丢失风险。
选项分析
正确。同步写后端是Write-through，异步批量落后端是Write-behind。
错误。甲不是异步写回；Cache Aside通常由应用显式管理缓存未命中和更新。
错误。Read-through描述读未命中时由缓存层加载，不是题干的写入流程。
错误。题干讨论应用缓存与后端数据库之间的写一致性。
本题为什么容易错
中文常把write-back和write-behind都译作写回，容易只背名字。考试更稳的办法是看后端数据库何时更新：返回前还是返回后。
简短答案
写缓存后同步落库和异步批量落库，主要差别是什么，正确答案是 A（Write-through；Write-behind）。Write-through在写缓存的同时同步更新后端，写延迟较高但后端状态及时；Write-behind把后端写入异步化，可合并批量操作并降低前台延迟，但要处理队列积压、失败和数据丢失风险。
易混淆概念对比表
| 概念 | 本题判断 | 区别要点 | 记忆提示 |
|---|---|---|---|
| Write-through；Write-behind | 本题正确答案 | 正确。同步写后端是Write-through，异步批量落后端是Write-behind。 | 看到题干核心场景时优先联想到它 |
| Write-behind；Cache Aside | 本题干扰项 | 错误。甲不是异步写回；Cache Aside通常由应用显式管理缓存未命中和更新。 | 看到该词不要急着选，先判断是否真正解决题干问题 |
| Read-through；Write-through | 本题干扰项 | 错误。Read-through描述读未命中时由缓存层加载，不是题干的写入流程。 | 看到该词不要急着选，先判断是否真正解决题干问题 |
| CDN回源；浏览器本地缓存 | 本题干扰项 | 错误。题干讨论应用缓存与后端数据库之间的写一致性。 | 看到该词不要急着选，先判断是否真正解决题干问题 |
本题易混淆选项怎么区分
- Write-behind；Cache Aside：错误。甲不是异步写回；Cache Aside通常由应用显式管理缓存未命中和更新。
- Read-through；Write-through：错误。Read-through描述读未命中时由缓存层加载，不是题干的写入流程。
- CDN回源；浏览器本地缓存：错误。题干讨论应用缓存与后端数据库之间的写一致性。
知识点详解
Write-through让缓存层或应用在响应前同步更新后端存储，通常更容易保证后端及时持久化，但写延迟和后端压力较高。Write-behind先接受缓存写入，再通过可靠队列或变更流异步批量写后端，可降低延迟并合并操作，但需要处理积压、顺序、重试、幂等、故障恢复和数据丢失窗口。
备考速记
穿透写：落库后再回；后台写：先回再落库，快但要防丢。
Write-through 在写策略场景中的作用
余额更新若返回成功却尚未持久化，缓存故障可能造成严重账实不符；浏览计数允许短时延迟且可批量合并，更适合评估Write-behind。业务语义决定策略，而不是缓存产品名称。
同类题怎么考
- 根据写入时序识别Write-through与Write-behind。
- 为不同业务选择缓存写策略并说明风险。
Write-through 在系统架构设计师软考中的考法
同步后端再返回，选Write-through；先返回、后批量刷库，选Write-behind。再根据数据可丢失性判断方案是否合理。
解题思路
题目已经把时序写出来了。甲要等数据库成功才返回，是“穿透缓存同步写到底”；乙先让前台结束，再由后台慢慢刷库，是写回。账户余额这类不能轻易丢的核心数据通常更谨慎，行为计数等可合并数据才更可能采用写回，答案 A。
考点定位
这两种策略没有绝对优劣。判断时先看后端写入是在响应前同步完成，还是在响应后异步完成。
易错提醒
- Write-behind没有持久队列，缓存节点故障后未落库数据丢失。
- 异步批量写失败后没有重试、死信和对账。
- Write-through只保证单次写路径，不自动解决绕过缓存直接改库的问题。
备考提示
- 画两条时间线，把客户端返回放在数据库写入之前或之后。
- 用余额和点赞计数比较对丢失、延迟和批量合并的容忍度。
你可能还想了解
- Write-behind为什么写入更快？
- 账户余额适合Write-behind吗？
- Write-through是否能保证所有缓存一致？
本文小结
Write-through在返回前同步更新数据库；Write-behind先更新缓存并返回，再异步批量落库。后者延迟低，但需要可靠队列、重试和对账。