一、背景
对于传统的后端业务场景(或者单机应用)中,访问量以及对响应时间的要求均不高,通常只使用DB即可满足要求。这种架构简单,便于快速部署,很多网站发展初期均考虑使用这种架构。但是随着访问量的上升,以及对响应时间的要求提升,单DB无法再满足要求。这时候通常会考虑DB拆分(sharding)、读写分离、甚至硬件升级(SSD)等以满足新的业务需求。但是这种方式仍然会面临很多问题,主要体现在:
1、性能提升有限,很难达到数量级上的提升,尤其在互联网业务场景下,随着网站的发展,访问量经常会面临十倍、百倍的上涨。
2、成本高昂,为了承载N倍的访问量,通常需要挂载更多的只读库,或者升级数据库实例的规格。
在计算机科学领域中有一句话:任何问题都可以通过增加一个间接的中间层来解决。本次的分享正是介绍解决以上问题的一个中间层——缓存层设计。
二、前言
鉴于缓存层的设计异常的复杂,需要考虑的问题很多,诸如:更新策略,缓存穿透,缓存一致性,缓存并发,缓存雪崩等。
本次只涉及到缓存的更新策略部分。
三、缓存层鸟瞰图
如上图所示,为了解决数据库性能瓶颈问题,对于读多写少的数据查询,可以通过多架设一层缓存层来减少对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太复杂。当然,最好还是为缓存设置上过期时间。