我是靠谱客的博主 勤劳大雁,最近开发中收集的这篇文章主要介绍【成为架构师3-16】缓存:互联网缓存的最佳实践Cache Aside Pattern,觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

系列文章是博主对沈剑的《架构师训练营》分享内容的个人笔记总结,原内容公众号“成为架构师”。

目录

        • 缓存里面存储的数据
        • Cache Aside Pattern的读实践
        • Cache Aside Pattern的写实践

缓存里面存储的数据

  1. 朴素类型的数据:如int
  2. 序列化的对象:如User对象
  3. 文本数据:如json,xml

Cache Aside Pattern的读实践

访问缓存,如果miss则读库,并将结果写入缓存
在这里插入图片描述

Cache Aside Pattern的写实践

缓存失效和修改有什么区别

  1. 缓存失效,下一次读缓存会cache miss
  2. 缓存修改,下一次读缓存会cache hit,但是修改步骤可能会较为复杂

不同类型存储数据的修改:

  1. 朴素类型直接修改
  2. 对象类型需要反序列化为对象再修改对应的属性,再序列化存储起来
  3. 文本类型需要读取文本,之后解析为dom树,修改之后再转化为文本存储

修改的代价过高

写实践的两点原则:

  1. 使用淘汰缓存而不是修改缓存
  2. 先操作数据库再操作缓存在这里插入图片描述

为什么是淘汰缓存而不是修改缓存,除了上面提到的修改成本高之外,修改缓存还可能会造成数据不一致的情况:
在这里插入图片描述
上面两个并发的写请求,请求1比请求2先修改数据库,但是请求2比请求1先修改了缓存,这就造成了缓存与数据库的不一致,而且这个不一致直到下次修改或者自动过期都会一直存在,是长时间的不一致。

为什么是先操作数据库而不是先操作缓存
在这里插入图片描述
假设数据操作存在上述异常时序,写请求先删除缓存,也就是设置其为失效状态,再写数据库,这个时候主从同步存在延时,在延时的时间窗口内,有一个读请求读了从库,此时读到的从库里的数据是旧数据,而且读完之后会被写入缓存,这样缓存里面就变成了一个旧数据。

这一不一致的情况,其实先操作数据库之后再淘汰缓存也是因为会有旧数据入缓存的情况,根本原因是因为主从同步的延时,这一问题会在下一篇文章中给出解决方案。

Cache Aside Pattern是一个成熟的缓存操作实践,也上升到了模式的程度,所以,大部分缓存操作,我们不必进行创新。


上一篇回顾:【成为架构师3-15】缓存:常见误用与实践
下一篇更精彩:【成为架构师3-17】缓存:数据一致性优化二次淘汰法

在这里插入图片描述

最后

以上就是勤劳大雁为你收集整理的【成为架构师3-16】缓存:互联网缓存的最佳实践Cache Aside Pattern的全部内容,希望文章能够帮你解决【成为架构师3-16】缓存:互联网缓存的最佳实践Cache Aside Pattern所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(31)

评论列表共有 0 条评论

立即
投稿
返回
顶部