缓存层设计套路(一)

简介: 对于传统的后端业务场景或者单机应用中访问量以及对响应时间的要求均不高通常只使用DB即可满足要求。这种架构简单便于快速部署很多网站发展初期均考虑使用这种架构。但是随着访问量的上升以及对响应时间的要求提升单DB无法再满足要求。

一、背景

对于传统的后端业务场景(或者单机应用)中,访问量以及对响应时间的要求均不高,通常只使用DB即可满足要求。这种架构简单,便于快速部署,很多网站发展初期均考虑使用这种架构。但是随着访问量的上升,以及对响应时间的要求提升,单DB无法再满足要求。这时候通常会考虑DB拆分(sharding)、读写分离、甚至硬件升级(SSD)等以满足新的业务需求。但是这种方式仍然会面临很多问题,主要体现在:

 

1、性能提升有限,很难达到数量级上的提升,尤其在互联网业务场景下,随着网站的发展,访问量经常会面临十倍、百倍的上涨。

2、成本高昂,为了承载N倍的访问量,通常需要挂载更多的只读库,或者升级数据库实例的规格。

 

在计算机科学领域中有一句话:任何问题都可以通过增加一个间接的中间层来解决。本次的分享正是介绍解决以上问题的一个中间层——缓存层设计。

        

二、前言

鉴于缓存层的设计异常的复杂,需要考虑的问题很多,诸如:更新策略,缓存穿透,缓存一致性,缓存并发,缓存雪崩等。

本次只涉及到缓存的更新策略部分。

 

三、缓存层鸟瞰图



 28f8d98a4f9758077773a57f8f6b830d9a6ca8da

 

如上图所示,为了解决数据库性能瓶颈问题,对于读多写少的数据查询,可以通过多架设一层缓存层来减少对DB的直接访问。由于一般缓存中间件(redis、memcached)的key-value对都是常驻内存的,所以如果能直接命中缓存,一来可以极大的提高网站的响应速度,二来也可以大幅地减少直接对数据库的操作。

缓存层的工作原理一般分为以下两步:

1、  当应用发起查询请求时,可以先通过查询缓存中的数据,如果命中缓存结果即可马上响应请求。

2、  如果没有命中缓存,或者缓存已经失效了,则需要直接查询数据库,再次将结果缓存起来,如果响应请求,返回数据。

 

 

四、缓存更新策略

有了以上基本了解,我们进入到本次分享的主题——缓存更新策略。

 

首先思考一下,为什么会有缓存更新策略的问题,这个策略需要解决的又是什么问题?

 

 

 

缓存层是解决数据库性能的一个中间层,既然是中间层,那么引入缓存层当然不能影响以前正常的业务操作。这里就引出了一个问题,就是如何确保缓存层中的数据与数据库中数据的一致性问题。缓存更新策略正是为了处理数据一致性的问题而诞生的。

 

 

缓存更新的模式有四种:Cache aside,Read through,Write through,Write behind caching。

 

1、  Cache aside(缓存预留)

这是最常用最常用的策略。其具体逻辑如下:

失效:应用程序先从cache取数据,没有得到,则从数据库中取数据,成功后,放到缓存中。

命中:应用程序从cache中取数据,取到后返回。

更新:先把数据存到数据库中,成功后,再让缓存失效。

 

2、Read/Write Through (直接读/写)

Read Through 就是在查询操作中更新缓存,也就是说,当缓存失效或过期的时候,Cache Aside是由调用方负责把数据加载入缓存,而Read Through则用缓存服务自己来加载,从而对应用方是透明的。

Write Through 和Read Through类似,不过是在更新数据时发生。当有数据更新的时候,如果没有命中缓存,直接更新数据库,然后返回。如果命中了缓存,则更新缓存,然后再由Cache自己更新数据库(这是一个同步操作)。

我们可以看到,在上面的Cache Aside中,我们的应用代码需要维护两个数据存储,一个是缓存(Cache) ,一个是数据库(Repository)。所以,应用程序比较难维护。而Read/Write Through是把更新数据库(Repository)的操作由缓存自己代理了,所以,对于应用层来说,就简单很多了。可以理解为,应用认为后端就是一个单一的存储,而存储自己维护自己的Cache。

 

/3、  Write Behind Caching(回写)

在更新数据的时候,只更新缓存,不更新数据库,而我们的缓存会异步地批量更新数据库。这个设计的好处就是让数据的I/O操作飞快无比(因为直接操作内存) ,因为异步,Write Behind Caching还可以合并对同一个数据的多次操作,所以性能的提高是相当可观的。

Write Behind Caching实现逻辑比较复杂,因为他需要追踪有哪数据是被更新了的,需要刷到持久层上。

 

但是,其带来的问题是,数据不是强一致性的,而且可能会丢失(Unix/Linux非正常关机会导致数据丢失,就是因为这个原因,因为Linux文件系统的Page Cache的算法使用的就是write back,类似于Write Behind Caching)。在软件设计上,我们基本上不可能做出一个没有缺陷的设计,就像算法设计中的时间换空间,空间换时间一个道理,有时候,强一致性和高性能,高可用和高性性是有冲突的。

 

 

五、 思考

 

思考如下场景:

1、用户A将商品S的售价从50修改为100

2、同一时间用户B在进行开单操作

 

这种情况下如何确保用户B在出售商品S的时候,售价是100呢?

 

使用上述的缓存更新策略,是否能解决这个场景问题。

 

还是不能的,比如,一个是读操作,但是没有命中缓存,然后就到数据库中取数据,此时来了一个写操作,写完数据库后,让缓存失效,然后,之前的那个读操作再把老的数据放进去,所以,会造成脏数据。

 

但,这个案例理论上会出现,不过,实际上出现的概率可能非常低,因为这个条件需要发生在读缓存时缓存失效,而且并发着有一个写操作。而实际上数据库的写操作会比读操作慢得多,而且还要锁表,而读操作必需在写操作前进入数据库操作,而又要晚于写操作更新缓存,所有的这些条件都具备的概率基本并不大。

 

所以,要么通过2PC或是Paxos协议保证一致性,要么就是拼命的降低并发时脏数据的概率,而Facebook使用了这个降低概率的这种方法,因为2PC太慢,而Paxos太复杂。当然,最好还是为缓存设置上过期时间。

目录
相关文章
|
缓存 Java Maven
Java 使用LRUmap设计一个简单的缓存场景
Java 使用LRUmap设计一个简单的缓存场景
536 0
Java 使用LRUmap设计一个简单的缓存场景
|
XML 存储 缓存
设计一个缓存策略,动态缓存热点数据
写在前面,因为我们最近的大作业项目需要用到热点排行这个功能,因为我们是要使用Elasticsearch来存储数据,然后最初设想是在ES中实现这个热点排行的功能,但是经过仔细思考,在我们这个项目中使用ES来做热点排行是一个很蠢的方式,因为我们这只是一个很小的排行,所以最终我们还是使用Redis来实现热点排行
471 1
设计一个缓存策略,动态缓存热点数据
|
存储 缓存 NoSQL
微服务实践01--微服务管理11--缓存02--分级缓存设计
微服务实践01--微服务管理11--缓存02--分级缓存设计
342 0
微服务实践01--微服务管理11--缓存02--分级缓存设计
|
缓存 前端开发 大数据
如何设计一个缓存函数
在项目中你有优化过自己写过的代码吗?或者在你的项目中,你有用过哪些技巧优化你的代码,比如常用的函数防抖、节流,或者异步懒加载、惰性加载等。
120 0
如何设计一个缓存函数
|
缓存 Java 数据库连接
第06篇:Mybatis缓存设计
MyBatis 内置了一个强大的事务性查询缓存机制,它可以非常方便地配置和定制。本篇文章,小编将会在最短的时间呢,通过观察源码来深刻了解Mybatis的 一级二级缓存;然后在说如何定制。
159 0
|
存储 缓存 运维
|
消息中间件 缓存 NoSQL
高可用架构设计(3) -电商商品详情页缓存背景及框架说明
高可用架构设计(3) -电商商品详情页缓存背景及框架说明
405 0
高可用架构设计(3) -电商商品详情页缓存背景及框架说明
|
缓存 NoSQL Redis
一图看懂redis、缓存的设计
一图看懂redis、缓存的设计
160 0
一图看懂redis、缓存的设计
|
存储 缓存 Java
Spring注解缓存设计原理及实战
注解驱动的Spring Cache能够极大的减少我们编写常见缓存的代码量,通过少量的注释标签和配置文件,即可达到使代码具备缓存的能力,且具备很好的灵活性和扩展性。但是我们也应该看到,Spring Cache由于基于Spring AOP技术,尤其是动态的proxy技术,导致其不能很好的支持方法的内部调用或者非public方法的缓存设置,当然这些都是可以解决的问题。
482 0
Spring注解缓存设计原理及实战
|
缓存 监控 Java
Ehcache缓存设计原理
Ehcache缓存设计原理
281 0
Ehcache缓存设计原理