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