在项目开发中，我们几乎都会使用到缓存，使用缓存最直观的就是提升系统的响应能力，大大提升了用户体验，并且能够减轻服务器的压力，提高整个系统的性能。但是在高并发的场景下，我们需要在使用缓存时应注意该场景下缓存所带来的问题。
一、为什么要使用缓存
上述图是应用请求或浏览器网络请求的大致流程
用户增多后，服务器和数据库压力增大。为保持高吞吐量，需要加入缓存来减少服务端的计算量。
以上任意环节都可以加入缓存，浏览器和APP可以维护客户端的缓存，对于后端来说，我们比较关心服务端的缓存和数据库的缓存。
高性能、高并发
二、缓存的特征
缓存的命中率：当某个请求能够通过访问缓存而得到响应时，称为缓存命中。缓存命中率越高，缓存的利用率也就越高。在这里命中数就可以理解为用户请求的资源在缓存中，而没有命中就是指用户无法直接从缓存中获取资源，需要查询数据库或者由服务器计算分发资源。
缓存的最大元素：缓存中能存放的最大数据，可以理解为缓存的容量。当缓存中的数据超出了最大元素，那么就会触发缓存清空策略。合理设置最大元素值可以有效的帮我们提高命中率。
淘汰策略：
FIFO：先进先出策略，在实时性的场景下，需要经常访问最新的数据，那么就可以使用FIFO，使得最先进入的数据被淘汰。
LRU：（The Least Recently Used）最近最久使用策略，如果一个数据在最近一段时间没有被访问到，那么可以认为在将来它被访问的可能性也很小。因此，当空间满时，最久没有访问的数据最先被置换（淘汰）。在热点场景下适用，优先保证热点数据的有效性。
LFU：（Least Frequently Used）最近最少使用策略，如果一个数据在最近一段时间很少被访问到，那么可以认为在将来它被访问的可能性也很小。因此，当空间满时，最小频率访问的数据最先被淘汰。这类策略有效的保证高命中率。
三、缓存命中率影响因素
缓存适合读多写少的业务场景，如果是在写多读少的场景使用缓存的意义就不大，并且可以根据清空策略来保证缓存的命中率。实时性要求越低的场景就越适合缓存。
缓存的粒度越小，命中率就越高。对象缓存是目前缓存粒度最小的，因此被命中的几率更高。
缓存容量和基础设施，目前的缓存工具和中间件大多采用LRU算法，并且采用分布式架构能更好的扩展缓存。
缓存应该聚焦于高频访问且时效性低的热点数据上。
四、高并发下缓存出现的问题
4.1、缓存穿透
缓存穿透是指缓存服务器中没有缓存数据，数据库中也没有符合条件的数据，导致业务系统每次都绕过缓存服务器查询下游的数据库，缓存服务器完全失去了其应用的作用。
解决方案：
处理缓存空值：之所以会发生穿透，就是因为缓存没有对那些不存在的值得Key缓存下来，从而导致每次查询都要请求到数据库。可以为这些key对应的值设置为null并放到缓存中，这样再出现查询这个key 的请求的时候，直接返回null即可 。注意，要设置缓存空值的过期时间。
BloomFilter（布隆过滤器）：布隆过滤器是一种比较巧妙的概率性数据结构，它可以告诉你数据一定不存在或可能存在，相比Map、Set、List等传统数据结构它占用内存少、结构更高效。对于缓存穿透，我们可以将查询的数据条件都哈希到一个足够大的布隆过滤器中，用户发送的请求会先被布隆过滤器拦截，一定不存在的数据就直接拦截返回了，从而避免下一步对数据库的压力。
4.2、缓存击穿
缓存击穿是指当某一key的缓存过期时大并发量的请求同时访问此key，瞬间击穿缓存服务器直接访问数据库，让数据库处于负载的情况。
解决方案：
互斥锁：在缓存处理上，通常使用一个互斥锁来解决缓存击穿的问题。简单来说就是当Redis中根据key获得的value值为空时，先锁上，然后从数据库加载，加载完毕，释放锁。若其他线程也在请求该key时，发现获取锁失败，则先阻塞。
热点数据永不过期：设置热点数据永远不过期。
异步定时更新：在缓存处理上，比如某一个热点数据的过期时间是1小时，那么每59分钟，通过定时任务去更新这个热点key，并重新设置其过期时间。
4.3、缓存雪崩
缓存雪崩是指当大量缓存同时过期或缓存服务宕机，所有请求的都直接访问数据库，造成数据库高负载，影响性能，甚至数据库宕机。
解决方案：
不同的过期时间：为了避免大量的缓存在同一时间过期，可以把不同的key过期时间设置成不同的， 并且通过定时刷新的方式更新过期时间。
集群：在缓存雪崩问题防治上面，一个比较典型的技术就是采用集群方式部署，使用集群可以避免服务单点故障。
热点数据永不过期：设置热点数据永远不过期
4.4、缓存数据一致性
4.4.1、 缓存更新常用策略
cache aside
Read/Write through
Write behind
4.4.2、 Cache aside（旁路缓存）
（1）读请求 常见流程
应用首先会判断缓存是否有该数据，缓存命中直接返回数据，缓存未命中即缓存穿透到数据库，从数据库查询数据然后回写到缓存中，最后返回数据给客户端。
（2）写请求
首先更新数据库，然后从缓存中删除该数据。
4.4.3、 Cache aside踩坑
踩坑一：先更新数据库，再更新缓存
如果同时有两个写请求需要更新数据，每个写请求都先更新数据库再更新缓存，在并发场景可能会出现数据不一致的情况。
如上图的执行过程：
（1）写请求1更新数据库，将 age 字段更新为18；
（2）写请求2新数据库，将 age 字段更新为20；
（3）写请求2更新缓存，缓存 age 设置为20；
（4）写请求1更新缓存，缓存 age 设置为18；
执行完预期结果是数据库 age 为20，缓存 age 为20，结果缓存 age为18，这就造成了缓存数据不是最新的，出现了脏数据。
踩坑二：先删缓存，再更新数据库
如果写请求的处理流程是先删除缓存再更新数据库，在一个读请求和一个写请求并发场景下可能会出现数据不一致情况。
如上图的执行过程：
（1）写请求删除缓存数据；
（2）读请求查询缓存未击中(Hit Miss)，紧接着查询数据库，将返回的数据回写到缓存中；
（3）写请求更新数据库。
整个流程下来发现数据库中age为20，缓存中age为18，缓存和数据库数据不一致，缓存出现了脏数据。
踩坑三：先更新数据库，再删除缓存
在实际的系统中针对写请求还是推荐先更新数据库再删除缓存，但是在理论上还是存在问题，以下面这个例子说明。
如上图的执行过程：
（1）读请求先查询缓存，缓存未击中，查询数据库返回数据；
（2）写请求更新数据库，删除缓存；
（3）读请求回写缓存；
整个流程操作下来发现数据库age20，缓存age为18，即数据库与缓存不一致，导致应用程序从缓存中读到的数据都为旧数据。
但我们仔细想一下，上述问题发生的概率其实非常低，因为通常数据库更新操作比内存操作耗时多出几个数量级，上图中最后一步回写缓存（set age 18）速度非常快，通常会在更新数据库之前完成。
如果这种极端场景出现了怎么办？我们得想一个兜底的办法：缓存数据设置过期时间。通常在系统中是可以允许少量的数据短时间不一致的场景出现。
4.4.4、Read through
在 Cache Aside 更新模式中，应用代码需要维护两个数据源头：一个是缓存，一个是数据库。而在 Read-Through 策略下，应用程序无需管理缓存和数据库，只需要将数据库的同步委托给缓存提供程序 Cache Provider 即可。所有数据交互都是通过抽象缓存层完成的。
Read-Through流程
如上图，应用程序只需要与Cache Provider交互，不用关心是从缓存取还是数据库。
在进行大量读取时，Read-Through 可以减少数据源上的负载，也对缓存服务的故障具备一定的弹性。如果缓存服务挂了，则缓存提供程序仍然可以通过直接转到数据源来进行操作。
Read-Through 适用于多次请求相同数据的场景，这与 Cache-Aside 策略非常相似，但是二者还是存在一些差别，这里再次强调一下：
在 Cache-Aside 中，应用程序负责从数据源中获取数据并更新到缓存。
在 Read-Through 中，此逻辑通常是由独立的缓存提供程序（Cache Provider）支持。
4.4.5、Write through
Write-Through 策略下，当发生数据更新(Write)时，缓存提供程序 Cache Provider 负责更新底层数据源和缓存。
缓存与数据源保持一致，并且写入时始终通过抽象缓存层到达数据源。
Cache Provider类似一个代理的作用。
4.4.6、 Write behind
Write behind在一些地方也被成为Write back， 简单理解就是：应用程序更新数据时只更新缓存， Cache Provider每隔一段时间将数据刷新到数据库中。说白了就是延迟写入。
如上图，应用程序更新两个数据，Cache Provider 会立即写入缓存中，但是隔一段时间才会批量写入数据库中。
这种方式有优点也有缺点：
优点是数据写入速度非常快，适用于频繁写的场景。
缺点是缓存和数据库不是强一致性，对一致性要求高的系统慎用。
4.4.7、 总结
缓存更新的策略主要分为三种：
Cache aside
Read/Write through
Write behind
Cache aside 通常会先更新数据库，然后再删除缓存，为了兜底通常还会将数据设置缓存时间。
Read/Write through 一般是由一个 Cache Provider 对外提供读写操作，应用程序不用感知操作的是缓存还是数据库。
Write behind简单理解就是延迟写入，Cache Provider 每隔一段时间会批量输入数据库，优点是应用程序写入速度非常快。
