阿里妹导读：响应时间长，遇到性能瓶颈时，开发者第一个想到的总是性能优化。《什么技能产品经理不会提，但技术人必须懂？》讲到了什么时候需要使用缓存。但缓存的用法是什么？一旦缓存使用不当，或稍有不注意，反而会翻车，导致系统投入更多的维护成本，陡增更高的复杂度。今天，科怀就来讲讲缓存的正确使用姿势。
在合理应用缓存前，需要了解缓存领域里相关的几个常用术语：
1）缓存命中：表示数据能够从缓存中获取，不需要回源；
2）Cache miss：表示没有命中缓存，如果缓存内存中还有内存空间的话，会将数据加入到缓存中；
3）存储成本：当没有命中缓存时，回源获取后会将数据放置到存储中，整个将数据放置到存储空间所需要的时间以及空间称之为存储成本；
4）缓存失效：当源数据发生变更后，意味着缓存中的数据失效；
5）缓存污染：将不经常访问的数据放置到缓存存储空间中，以至于高频访问的数据无法放置到缓存中；
6）替代策略：当数据放置到缓存空间时，由于空间不足时，就需要从缓存空间中去除已有的数据，选择去除哪些数据就是由替代策略决定的。常见的替代策略有如下这些：
由于存储空间有限，替代策略要解决的核心问题是尽量保留高频访问的缓存数据，降低缓存污染以提升缓存命中率和整体的缓存效率，难点在于，需要基于数据历史访问情况，以一种合适的对未来访问情况的预估才能找到更佳的策略。
使用缓存通常的操作是，请求先访问缓存数据，如果缓存中不存在的话，就会回源到数据库中然后将数据写入到缓存中；如果存在的话就直接返回数据。从整个过程来看，缓存层就处于数据访问的前置环节，分担数据库在高并发容易出现系统故障的风险，所以在使用过程中需要对缓存层很谨慎的进行分析。在访问缓存数据时，有常见的三大场景：缓存穿透、缓存击穿以及缓存雪崩。
现象：
每次请求直接穿透缓存层，直接回源到数据库中，给数据库带来了巨大访问压力，甚至宕机。
原因：
访问数据会先访问缓存，如果数据不存在缓存中才会查询数据库，但是如果查询数据库也查询不出来数据，也是说当前访问数据永远不会写入缓存中。这样就导致了，访问一定不存在的数据，就相当于缓存层形同虚设，每次请求都会到db层，造成数据库负担过大。
方案一：采用bloom filter保存缓存过的key，在访问请求到来时可以过滤掉不存在的key，防止这些请求到db层；
方案二：如果db查询不到数据，保存空对象到缓存层，设置较短的失效时间；
方案三：针对业务场景对请求的参数进行有效性校验，防止非法请求击垮db。
现象：当某一key失效时，造成大量请求到db层，击垮存储层。
原因：
为了保证缓存数据的时效性，通常会设置一个失效时间，如果是热点key，高并发时会有海量请求直接越过缓存层到数据库，这样就会给数据库造成的负担增大，设置宕机。
现象：
多个key失效，造成大量请求到db层，导致db层负担过重甚至宕机。
原因：
缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到数据库，最终导致数据库瞬时压力过大而崩溃。
缓存穿透、缓存击穿以及缓存雪崩这三个术语很容易弄混，也是读缓存中典型的三个场景问题，做一下简单的总结是很有必要的。缓存穿透强调是获取本不存在的缓存数据，请求必然会越过缓存层直接到达到存储层，很明显这是利用业务规则的漏洞对系统发起攻击，解决方案的核心原则是过滤这些非法业务请求，与是否是热点数据、缓存失效时间等因素没有关系。
缓存击穿强调的是热点key的失效，导致某一时刻大量请求会直接到db层，解决方案的核心原则是规避数据库的并发操作。缓存雪崩强调的多个key的集体失效，与key是否是热点数据并不是必然的因素，解决方案的核心原则则让key之间的失效时间分布更加均匀，避免集体失效的情况。
引入缓存后数据会分别存放到缓存以及数据库两个地方，因此数据更新时，需要涉及到这两处地方得更新，并且更新时序的不同会有不同的结果。关于数据更新目前业界已经沉淀了Cache Aside Pattern，Read/Write through等多种方式。
https://coolshell.cn/articles/17416.html
-
失效：应用程序先从cache取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。
-
-
更新：先把数据存到数据库中，成功后，再让缓存失效。
Cache Aside Pattern在数据更新的时候是采用先更新数据库，再失效缓存。为什么需要采用这样的方式来解决数据更新的问题，先假设更新数据库以及缓存都会事务成功，由于某一种更新导致的不一致性在下一章节进行讨论。
❶ 并发写容易写覆盖造成脏数据问题：
当数据发生更新的时候，针对缓存数据可以有两种方式来进行处理分别是更新缓存数据以及失效数据让下一次读请求重新从db中获取数据后重载入缓存中。假设更新缓存数据的话，在并发情况下会存在多线程写缓存造成脏数据的问题，如下图：
如上图所示，假设A、B两个线程，A先更新数据库后 B再更新数据库，然后分别进行更新缓存，但是B先更新缓存成功，A后更新缓存成功，这样就导致数据库是最新的数据但是缓存中是旧的脏数据。而如果失效缓存数据的话，可以保证下一次读请求回源到数据库将最新的数据载入到缓存中，避免脏数据的问题。因此，针对数据更新缓存采用失效的方式进行处理，也可以参考这篇文章《Why does Facebook use delete to remove the key-value pair in Memcached instead of updating the Memcached during write request to the backend?》。
❷ 双写不同数据源容易造成数据不一致：同时写数据库以及缓存数据，任何一个更新失败都会造成数据不一致，由于“物理失败”造成的数据不一致在下一个章节进行阐述。另外事务都成功，无论是先更新缓存还是再更新数据库，还是先更新数据库再更新缓存，这两种情况在并发的情况下也很容易出现双写不成功，操作时序如下图，这种方式不推荐。
❺ 违背数据懒加载，避免不必要的计算消耗：如果有些缓存值是需要经过复杂的计算才能得出，所以如果每次更新数据的时候都更新缓存，但是后续在一段时间内并没有读取该缓存数据，这样就白白浪费了大量的计算性能，完全可以后续由读请求的时候，再去计算即可，这样更符合数据懒加载，降低计算开销。
在确定数据更新后缓存会失效来进行处理的话，针对数据库以及缓存更新时序就存在如下这几种：
❷ 假设在并发的情况下，按照这种更新时序会存在什么问题？
如时序图所示，线程A先失效缓存数据的时候，B线程读请求发现缓存数据为空的话，就会从数据库中读取旧值放入到缓存中，这样就导致后续的读请求读到的都是缓存中的脏数据。针对这样的情况可以采用延时双删的策略来有效避免，伪代码 如下：
cache.delKey(key); db.update(data); Thread.sleep(xxx); cache.delKey(key);
主要是在写请求更新完数据库后进行休眠一段时间，然后删除可能由读请求带来的脏数据存入到缓存。另外，数据库如果采用的是主从分离的架构的话，读出来的数据也有可能是主从未同步完成造成的脏数据。这种通过延时双删的方式需要线程休眠，因此很显然会降低系统吞吐量，并不是一种优雅的解决方式，也可以采用异步删除的方式。当然可以设置过期时间，到期后缓存失效载入最新的数据，需要系统能够容忍一段时间的数据不一致。
❸ 先更新数据库再失效缓存 ：这是推荐的更新数据时采用的方式，实际上这也是可能存在数据不一致的情况，时序图如下：
❹ 假设缓存刚好到期失效时，读请求从db中读取数据，写请求更新完数据后再失效缓存后，读请求将旧数据存入到缓存中，这种情况也会导致脏数据的问题。实际上这种情况发生的概率很低，要发生这种情况的前提条件是写数据库要先于读数据库完成，一般而言读数据库相比于写数据库要耗时更短，这种前提条件成立的概率很低。针对这种”逻辑失败“造成的数据不一致，可以采用上面所说的异步双删的策略以及过期失效的方式来避免。
可以看出在并发的情况下，如果条件苛刻的话，这两种更新的时序都有可能导致脏数据的情况。只不过在大概率的情况下先更新数据库再失效缓存能够保证数据一致，也是业界推荐的处理方式，包括Facebook的论文《Scaling Memcache at Facebook》也使用了这个策略。当数据发生变更上，需要考虑的是最新的数据放置在哪里？很显然cache aside pattern 选择的是将最新的数据放到了db上（cache asside pattern：缓存靠边站），因为数据不一致的情况大概率会存在，需要根据业务场景选择合适的可信设备存储最新的数据。
Cache Aside Pattern对db以及缓存的更新逻辑是由调用方自己去控制，很显然这是一个很复杂的过程。Write/Read Through对调用方而言，缓存是作为整个的数据存储，而不用关系缓存后面的db，数据库的更新则是由缓存统一进行管理，对调用方而言只需要和缓存进行交互，整体过程是透明的。
-
Read Through：当数据发生更新时，查询缓存时更新缓存，然后由缓存层同步的更新数据库即可，对调用方而言只需要和缓存层交互即可；
-
Write Through：Write Through 套路和Read Through相仿，不过是在更新数据时发生。当有数据更新的时候，如果没有命中缓存，直接更新数据库，然后返回。如果命中了缓存，则更新缓存，然后再由Cache自己同步更新数据库。如下图所示（来源于网络）：
3.3 Write Behind Cache Pattern
这种模式是当数据更新的时候直接更新缓存数据，然后建立异步任务去更新数据库。这种异步方式请求响应会很快，系统的吞吐量会明显提升。但是，因为是异步更新数据库，数据一致性的保障就会变弱，如果更新数据库失败则会永远的造成系统脏数据，需要很精细设计系统重试的策略，另外如果异步服务宕机的话，还要考虑更新的数据如何持久化，服务重启后能够迅速恢复。在更新数据库时，由于并发多任务的存在，还需要考虑并发写是否会造成脏数据的问题，就需要追溯每次更新数据的时序。使用这种模式需要考虑的细节会有很多，设计出一套好的方案是件很不容易的事情。
上面这四种更新策略是非常经典的，也是业界经过大规模业务总结下来的经验，如果认真分析这四种更新策略的话，也会是受益匪浅，在更新策略的设计我得理解是主要关注如下两个方面：
缓存的存在是为了系统高性能，利用内存的IO读取的高速的特性，来提升系统的性能，提高系统吞吐量，另外，缓存的存在会让一部分读请求不会到达db层，分解了db的压力，毕竟db是最容易出现瓶颈的地方。这是为什么利用缓存的两个重要原因。但是，带来的问题就是，数据会存在在两个地方分别是缓存以及数据库中，当数据更新的时候就需要思考让”正确的数据应该放在哪个最可信的存储介质上“，就需要结合业务性质在两个数据存储介质上进行选择。
Cache Aside Pattern选择先更新数据库，再失效缓存，这样可以保证最新最正确的数据一定会落在数据库中，这样可以保证核心的业务数据在数据库中一定是可信的，但是带来的问题是业务逻辑更复杂，系统处理更新逻辑耗时更长。如果是非核心数据的更新，可以选择write behind cache pattern的方式，只需要更新缓存即可，能够快速的响应。缺点是很容易造成数据不一致，数据库中的数据不一定的就是最可信的数据。所以，不同的更新策略实际上也是将最新的数据优先选择放在哪里更合适以及系统性能的一种权衡，需要结合业务场景做好trade-off。
4.1 数据不一致的原因
由于引入缓存，数据就会分散在两处不同数据源，当数据更新时，实时上很难做到数据一致，除非采用强一致性方案，这里不在进行讨论。在找出合适的解决方案前，需要分析下存在数据不一致的主要原因，才能对症下药：
1）逻辑失败造成的数据不一致：
在上一章主要分析了更新数据时的四种更新策略，在并发的情况下，无论是先删除缓存还是更新数据库，还是更新数据库再失效缓存，都会数据不一致的情况，主要是因为异步读写请求在并发情况下的操作时序导致的数据不一致，称之为”逻辑失败“。解决这种因为并发时序导致的问题，核心的解决思想是将异步操作进行串行化。
2）物理失败造成的数据不一致：
在cache aside pattern中先更新数据库再删除缓存以及异步双删策略等等，如果删除缓存失败时都出现数据不一致的情况。但是数据库更新以及缓存操作是没办法放到一个事务中，一般来说，使用缓存是分布式缓存如果缓存服务很耗时，那么将更新数据库以及失效缓存放到一个事务中，就会造成大量的数据库连接挂起，严重的降低系统性能，甚至会因为数据库连接数过多，导致系统崩溃。像这种因为缓存操作失败，导致的数据不一致称之为”物理失败“。大多数情况物理失败的情况会重用重试的方式进行解决。
在绝大部分业务场景中，追求的是最终一致性，针对物理失败造成的数据不一致常用的方案有：消费消息异步删除缓存以及订阅Binlog的方式，针对逻辑失败造成的数据不一致常用的方案有：队列异步操作同步化。
在分析cache aside pattern发现在并发的情况下也会存在数据不一致的场景，只不过发生的概率很低，另外如果先删除缓存再更新数据库在并发读写的情况下也会存在数据不一致的情况。类似这种由于并发时序导致的数据不一致的情况，都是因为写请求还没有结束读请求读取的是旧数据，如果读请求在写请求之后处理，即请求的处理能够串行化的话，就能保证读请求读到的是写请求更新的最新的数据。
将请求进行串行化，最常用的方式是采用队列的方式，一个队列只能对应一个工作线程，更新数据的写请求放置队列中，等待异步处理；读请求如果能从缓存中获取数据，则返回，如果缓存中没有数据，就将读请求放置到队列中，等待写请求数据更新完成。这种方案需要考虑的问题有：
