您好,登录后才能下订单哦!
这篇文章主要讲解了“缓存系统设计有哪些性质”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“缓存系统设计有哪些性质”吧!
缓存系统涉及的问题和知识点是比较多的,我主要分为以下几个方面来跟大家探讨:
稳定性
正确性
可观测性
规范落地和工具建设
首先,我们讲数据一致性的前提是我们DB的更新和缓存的删除不会当成一个原子操作来看待,因为在高并发的场景下,我们不可能引入一个分布式锁来把这两者绑定为一个原子操作,如果绑定的话就会很大程度上影响并发性能,而且增加系统复杂度,所以我们只会追求数据的最终一致性,且本文只针对非追求强一致性要求的高并发场景,金融支付等同学自行判断。
常见数据更新方式有两大类,其余基本都是这两类的变种:
先删缓存,再更新数据库
这种做法是遇到数据更新,我们先去删除缓存,然后再去更新DB,如左图。让我们来看一下整个操作的流程:
A请求需要更新数据,先删除对应的缓存,还未更新DB
B请求来读取数据
B请求看到缓存里没有,就去读取DB并将旧数据写入缓存(脏数据)
A请求更新DB
可以看到B请求将脏数据写入了缓存,如果这是一个读多写少的数据,可能脏数据会存在比较长的时间(要么有后续更新,要么等待缓存过期),这是业务上不能接受的。
先更新数据库,再删除缓存
上图的右侧部分可以看到在A更新DB和删除缓存之间B请求会读取到老数据,因为此时A操作还没有完成,并且这种读到老数据的时间是非常短的,可以满足数据最终一致性要求。
上图可以看到我们用的是删除缓存,而不是更新缓存,原因如下图:
上图我用操作代替了删除或更新,当我们做删除操作时,A先删还是B先删没有关系,因为后续读取请求都会从DB加载出最新数据;但是当我们对缓存做的是更新操作时,就会对A先更新缓存还是B先更新缓存敏感了,如果A后更新,那么缓存里就又存在脏数据了,所以 go-zero 只使用删除缓存的方式。
我们来一起看看完整的请求处理流程:
注意:不同颜色代表不同请求。
请求1更新DB
请求2查询同一个数据,返回了老的数据,这个短时间内返回旧数据是可以接受的,满足最终一致性
请求1删除缓存
请求3再来请求时缓存里没有,就会查询数据库,并回写缓存再返回结果
后续的请求就会直接读取缓存了
另外留一个问题大家可以思考下,对于下图的场景,我们该怎么应对?
感谢各位的阅读,以上就是“缓存系统设计有哪些性质”的内容了,经过本文的学习后,相信大家对缓存系统设计有哪些性质这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是亿速云,小编将为大家推送更多相关知识点的文章,欢迎关注!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。