建站 > 前端 > 正文

Cache Aside Pattern(缓存模式)解析

开发者盛宴来袭!7月28日51CTO首届开发者大赛决赛带来技术创新分享 技术沙龙 | 6月30日与多位专家探讨技术高速发展下如何应对运维新挑战!-->

在《究竟先操作缓存,还是数据库?》,有同学在评论提出,相关方案违背了“Cache Aside Pattern”的原则,故今天聊一聊Cache Aside Pattern。

另外,在讨论技术方案时,尽量不说:

  • “你是错的,应该怎么样”
  • “facebook不是这样,所以你是错的”
  • 画外音:凭什么facebook就是真理?它的方案只是适合它的业务而已。

    说明适用场景,说明来龙去脉,说明前因后果,比具体使用什么方案更重要。

    什么是“Cache Aside Pattern”?

    答:旁路缓存方案的经验实践,这个实践又分读实践,写实践。

    对于读请求

  • 先读cache,再读db
  • 如果,cache hit,则直接返回数据
  • 如果,cache miss,则访问db,并将数据set回缓存
  • 如上图:

  • 先从cache中尝试get数据,结果miss了
  • 再从db中读取数据,从库,读写分离
  • 最后把数据set回cache,方便下次读命中
  • 画外音:这一点上,与《究竟先操作缓存,还是数据库?》说的是一致的。

    对于写请求

  • 淘汰缓存,而不是更新缓存
  • 先操作数据库,再淘汰缓存
  • 如上图:

    (1)第一步要操作数据库,第二步操作缓存

    画外音:这一点上,与《究竟先操作缓存,还是数据库?》说的不一致,也是评论反驳比较激烈的地方。

    (2)缓存,采用delete淘汰,而不是set更新

    画外音:这一点上,与《缓存,究竟是淘汰,还是修改?》说的是一致的。

    Cache Aside Pattern为什么建议淘汰缓存,而不是更新缓存?

    答:如果更新缓存,在并发写时,可能出现数据不一致。

    如上图所示,如果采用set缓存。

    在1和2两个并发写发生时,由于无法保证时序,此时不管先操作缓存还是先操作数据库,都可能出现:

  • 请求1先操作数据库,请求2后操作数据库
  • 请求2先set了缓存,请求1后set了缓存
  • 导致,数据库与缓存之间的数据不一致。

    所以,Cache Aside Pattern建议,delete缓存,而不是set缓存。

    Cache Aside Pattern为什么建议先操作数据库,再操作缓存?

    答:如果先操作缓存,在读写并发时,可能出现数据不一致。

    如上图所示,如果先操作缓存。

    在1和2并发读写发生时,由于无法保证时序,可能出现:

  • 写请求淘汰了缓存
  • 写请求操作了数据库(主从同步没有完成)
  • 读请求读了缓存(cache miss)
  • 读请求读了从库(读了一个旧数据)
  • 读请求set回缓存(set了一个旧数据)
  • 数据库主从同步完成
  • 导致,数据库与缓存的数据不一致。

    所以,Cache Aside Pattern建议,先操作数据库,再操作缓存。

    Cache Aside Pattern方案存在什么问题?

    答:如果先操作数据库,再淘汰缓存,在原子性被破坏时:

  • 修改数据库成功了
  • 淘汰缓存失败了
  • 导致,数据库与缓存的数据不一致。

    如何解决这类问题呢?

    答:详见《究竟先操作缓存,还是数据库?》。

    【本文为51CTO专栏作者“58沈剑”原创稿件,转载请联系原作者】

    戳这里,看该作者更多好文

    声明:本文内容由互联网用户自发贡献自行上传,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任。如果您发现有涉嫌版权的内容,欢迎发送邮件至:2782622003@qq.com 进行举报,并提供相关证据,工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。