缓存层设计套路（一）

一、背景

对于传统的后端业务场景（或者单机应用）中，访问量以及对响应时间的要求均不高，通常只使用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太复杂。当然，最好还是为缓存设置上过期时间。