缓存架构设计细节二三事

本文主要讨论这么几个问题:(1)“缓存与数据库”需求缘起(2)“淘汰缓存”还是“更新缓存”(3)缓存和数据库的操作时序(4)缓存和数据库架构简析一、需求缘起场景介绍缓存是一种提高系统读性能的常见技术,对于读多写少的应用场景,我们经常使用缓存来进行优化。

由于大部分的请求是查询,我们在缓存中建立uid到money的键值对,能够极大降低数据库的压力。

假设先写数据库,再淘汰缓存:第一步写数据库操作成功,第二步淘汰缓存失败,则会出现DB中是新数据,Cache中是旧数据,数据不一致。

假设先淘汰缓存,再写数据库:第一步淘汰缓存成功,第二步写数据库失败,则只会引发一次Cachemiss。结论:数据和缓存的操作时序,结论是清楚的:先淘汰缓存,再写数据库。四、缓存架构优化

上述缓存架构有一个缺点:业务方需要同时关注缓存与DB,有没有进一步的优化空间呢?有两种常见的方案,一种主流方案,一种非主流方案(一家之言,勿拍)。

主流优化方案是服务化:加入一个服务层,向上游提供帅气的数据访问接口,向上游屏蔽底层数据存储的细节,这样业务线不需要关注数据是来自于cache还是DB。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181024A14P2A00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券