21 | 赫赫有名的双刃剑：缓存（上）
该思维导图由 AI 生成，仅供参考
缓存的本质
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
缓存在全栈开发中扮演着重要角色，既是性能提升的利器，也可能成为系统运行的双刃剑。本文深入浅出地介绍了缓存的工作原理和应用场景，涵盖了常见的缓存应用模式，如Cache-Aside、Read-Through、Write-Through和Write-Back。其中，Cache-Aside模式是最为常用的，而Write-Back模式则在分布式系统中较为常见。文章重点讲解了Cache-Aside模式的数据获取和更新策略，以及关键的避坑要点，如数据库更新后需令缓存失效，而非直接更新缓存为数据库最新值。此外，还提到了Write-Back模式的优势在于高请求吞吐量和稳定的更新效率，但也存在一致性问题和数据丢失风险。总之，本文对缓存的应用模式进行了深入比较和思考，为全栈开发者提供了宝贵的参考价值。
《全栈工程师修炼指南》，新⼈⾸单¥59
全部留言(6)
- 最新
- 精选
四喜请问下，Cache-Aside部分中，那个极小概率出现，设计中一般忽略的情形是怎样的？作者回复: R1 是读请求，R2 是更新请求： 1. R1 读缓存，发现已失效，就从数据库里读出旧值 Va； 2. R2 更新请求，将数据库里的值从 Va 更新为新值 Vb，并将缓存标记为失效； 3. R1 将 Va 写回缓存，于是缓存中就有了一个过期值 Va，而数据库中是 Vb。 我说这个情况极小概率出现的原因有这样几个： 1. 需要缓存自身过期和数据更新几乎同时发生； 2. 需要 R1 在读出旧值以后，R2 的更新操作全部完成，R1 才将旧值写入缓存，而众所周知从数据库中读数据并写入缓存的操作速度，通常情况下要远高于数据库更新并将缓存标记为失效的操作，因为写操作需要的要求更高，比如需要使用事务等等。当然，这说的是“通常情况”，并不是 说“一定”，不过出问题的概率是非常非常小的。
2019-11-1022
丁丁历险记1. Write-Back 的稳定性是靠中间件来处理的，kafka 是个不错的选择。 2 读缓存还是数据库，还有个常用套路就是先查依赖(通常依赖的消耗更小，例如只在存储引擎层就可以搞定) 3 画图工具不错。作者回复: 你好，能否进一步解释一下第 2 条？
2019-11-2721
💢 星星💢老师，我对这几种缓存模式，还有点疑问。 1.Read-Through读模式老师分析了，那更新呢？是否跟Cache-Aside的一样，先更新数据库在另缓存失效？ 2.同样write-Through也是，您也只说了更新，没说查询。在更新的时候如果有查询操作，是查询到缓存就直接返回？ 3.同样write-back也是在查询的时候有缓存就直接返回么？ 4.以上几点是不是只针对于莫种场景采用的方式比如read-through只是读取的才用这样的，更新需要另外设计？不像cache-aside那样既有查询策略又有更新策略。 5.老师能否针对几种模式。举几个具体的例子呢，老师虽然说过应用场景。但是想知道具体应用。 感谢老师。作者回复: #1、#2，这是read-through，所以只有读模式，更新的话你看下面的write-through；反之亦然。 #3，write-back也是只描述了写的模式。 #4，实际情况下，读写的不同策略是可以组合的，比如read-through用于读，write-through用于写。cache-aside的策略既包括读也包括写。 #5，例子的话，简单说说： （1）Cache-Aside，比如多数Web网站的数据/资源访问缓存，要查询的数据如果在内存（缓存）中存在，就不去数据库执行查询操作； （2）Read-Through、Write-Through，有一些持久层的框架就是如此，对框架的使用者来说，并不需要关心缓存和数据库之间的一致性是怎么维护的； （3）Write-Through，适合某些写吞吐量比较大且一致性要求不高的情况，比如日志持久化。
2020-03-13
Geek_ef0311不知道自己想的对不对，高并发的时候会考虑用wirte-back（例如游戏中的某时刻抽奖） ，批量的时候用write/read through 等比较好作者回复: 就是 trade-off，write-back 带来高吞吐量的同事，会牺牲一定的一致性（数据库和缓存可能不一致）和持久性（可能存在掉电数据丢失），你说的“高并发的时候”，如果可以做出这样的牺牲，那么就可以考虑这个方法
2019-11-25- pyhhou1. 在接下来的项目中会考虑用到 cache-aside 这种模式设计，cache 用的是 Redis，DB 用的是 MongoDB，感觉这种模式比较常见，相对来说不会那么复杂 2. 根据文中的分析，cache-aside 比较稳健些，导致数据不一致的风险也相对较低，但是对于更新和写操作来说的话，相对较慢，原因也很好解释，这里面涉及了 cache 的访问、DB 的更新、以及 cache 的更新；write-back 的话对于更新和写操作来说效率会更高，吞吐量也更大，但是数据不一致的风险较大。效率和安全，这里又是一个权衡的话题（有点类似 HTTP 和 HTTPS）。个人觉得这两种模式差别主要在更新和写操作上，这就需要根据业务来分析了，如果业务中 95% 以上都是读请求，并且也没有那么高的性能要求，那么其实 cache-aside 就完全够用了，但是对于某些写高于读的系统（比如日志系统），而且要求高性能，那么可以考虑使用 write-back 这种模式2019-11-06
leslie数据写入缓存故而这就是日志的问题啊：现在其实许多数据库模型同样宕机就OVER，纠其根本原因还是许多的不严谨；日志是灾难恢复的主要手段。 数据库内部查询同样是先看缓存是否有，没有再去重新查找；毕竟缓存速度>内存>磁盘。异步最大的难题是是事务性：这块非关系型数据库处理的都不好。2019-10-283
