【Redis】Redis 淘汰、雪崩、击穿、穿透、预热、降级
为什么要理解Redis缓存问题
在高并发的业务场景下，数据库大多数情况都是用户并发访问最薄弱的环节。所以，就需要使用redis做一个缓冲操作，让请求先访问到redis，而不是直接访问Mysql等数据库。这样可以大大缓解数据库的压力。
当缓存库出现时，必须要考虑如下问题：
- 缓存穿透
- 缓存穿击
- 缓存雪崩
- 缓存污染（或者满了）
- 缓存和数据库一致性
缓存更新策略
缓存更新是redis为了节约内存而设计出来的一个东西，主要是因为内存数据宝贵，当我们向redis插入太多数据，此时就可能会导致缓存中的数据过多，所以redis会对部分数据进行更新，或者把他叫为淘汰更合适。
**内存淘汰：**redis自动进行，当redis内存达到咱们设定的max-memery的时候，会自动触发淘汰机制，淘汰掉一些不重要的数据(可以自己设置策略方式)
**超时剔除：**当我们给redis设置了过期时间ttl之后，redis会将超时的数据进行删除，方便咱们继续使用缓存
**主动更新：**我们可以手动调用方法把缓存删掉，通常用于解决缓存和数据库不一致问题
数据库缓存不一致解决方案：
由于我们的缓存的数据源来自于数据库,而数据库的数据是会发生变化的,因此,如果当数据库中数据发生变化,而缓存却没有同步,此时就会有一致性问题存在
数据库和缓存不一致采用什么方案：
综合考虑使用方案一，但是方案一调用者如何处理呢？这里有几个问题
操作缓存和数据库时有三个问题需要考虑：
如果采用第一个方案，那么假设我们每次操作数据库后，都操作缓存，但是中间如果没有人查询，那么这个更新动作实际上只有最后一次生效，中间的更新动作意义并不大，我们可以把缓存删除，等待再次查询时，将缓存中的数据加载出来
-
删除缓存还是更新缓存？
- 更新缓存：每次更新数据库都更新缓存，无效写操作较多
- 删除缓存：更新数据库时让缓存失效，查询时再更新缓存
-
如何保证缓存与数据库的操作的同时成功或失败？
- 单体系统，将缓存与数据库操作放在一个事务
- 分布式系统，利用TCC等分布式事务方案
应该具体操作缓存还是操作数据库，我们应当是先操作数据库，再删除缓存，原因在于，如果你选择第一种方案，在两个线程并发来访问时，假设线程1先来，他先把缓存删了，此时线程2过来，他查询缓存数据并不存在，此时他写入缓存，当他写入缓存后，线程1再执行更新动作时，实际上写入的就是旧的数据，新的数据被旧数据覆盖了。
- 先操作缓存还是先操作数据库？
- 先删除缓存，再操作数据库
- 先操作数据库，再删除缓存
那么，是不是Cache Aside这个就不会有并发问题了？
不是的，比如，一个是读操作，但是没有命中缓存，然后就到数据库中取数据，此时来了一个写操作，写完数据库后，让缓存失效，然后，之前的那个读操作再把老的数据放进去，所以，会造成脏数据。
但，这个case理论上会出现，不过，实际上出现的概率可能非常低，因为这个条件需要发生在读缓存时缓存失效，而且并发着有一个写操作。而实际上数据库的写操作会比读操作慢得多，而且还要锁表，而读操作必需在写操作前进入数据库操作，而又要晚于写操作更新缓存，所有的这些条件都具备的概率基本并不大。
缓存雪崩
Redis雪崩我们一般都称为缓存雪崩，意思就是说在某个时间节点，大量的 key 失效，导致大量的请求从缓存中获取不到数据而去请求数据库。
解决思路
解决方案：
-
给不同的Key的TTL添加随机值
- 很简单，因为上面刚刚说到，缓存雪崩是由于某个时间节点大量的 key 失效而导致的问题，那现在的问题不就是变成了如何防止同一个时间节点大量的 key 失效这种情况发生吗？
- 最简单的情况就是把key的过期时间分散开，也就是在设置key的过期时间的时候再加一个随机值，就这样就能完美的解决缓存雪崩的问题。
-
加锁
- 流程是这样子的，在多个请求同时到达业务系统时候，只能有一个线程能获取到锁，然后才能继续去缓存或者是数据库中查询数据，然后后面的流程和之前的是一样的，执行完成后释放锁，然后其他线程再争抢锁，然后重复前面的流程。
- 这个就是在缓存中如果获取不到，再去串行的访问数据看，这里不一定非要串行，可以配合线程池，控制一定的并发数。
- 这个缺点虽然很多，但是也是一种解决方案。用不用就看实际的业务场景了。毕竟没有没用技术方案，只有不适合业务场景的技术方案（手动狗头）。
-
利用Redis集群提高服务的可用性
-
给缓存业务添加降级限流策略
-
给业务添加多级缓存
缓存穿透
缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求。由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。
在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。
如发起为id为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大。
常见的解决方案有两种：
- 缓存空对象
- 优点：实现简单，维护方便
- 缺点：
- 额外的内存消耗
- 可能造成短期的不一致
- 布隆过滤
- 优点：内存占用较少，没有多余key
- 缺点：
- 实现复杂
- 存在误判可能
缓存穿透解决方案之缓存空数据
当我们客户端访问不存在的数据时，先请求redis，但是此时redis中没有数据，此时会访问到数据库，但是数据库中也没有数据，这个数据穿透了缓存，直击数据库，我们都知道数据库能够承载的并发不如redis这么高，如果大量的请求同时过来访问这种不存在的数据，这些请求就都会访问到数据库，简单的解决方案就是哪怕这个数据在数据库中也不存在，我们也把这个数据存入到redis中去，这样，下次用户过来访问这个不存在的数据，那么在redis中也能找到这个数据就不会进入到缓存了
缓存穿透解决方案之布隆过滤器
布隆过滤器其实采用的是哈希思想来解决这个问题，通过一个庞大的二进制数组，走哈希思想去判断当前这个要查询的这个数据是否存在，如果布隆过滤器判断存在，则放行，这个请求会去访问redis，哪怕此时redis中的数据过期了，但是数据库中一定存在这个数据，在数据库中查询出来这个数据后，再将其放入到redis中，
假设布隆过滤器判断这个数据不存在，则直接返回
这种方式优点在于节约内存空间，存在误判，误判原因在于：布隆过滤器走的是哈希思想，只要哈希思想，就可能存在哈希冲突
布隆过滤器是一种数据结构，更准确的说是一种概率型的数据结构，因为它能判断某个元素一定不存在或者是可能存在。
就这句话，搞蒙了很多人，今天我非要把你说明白了。布隆过滤器是一个bit数组，一个很长的bit数组和一系列的hash函数构成。先看下图
我们现在来举个例子，假设现在有小强和旺财两个人，他们分别经过三次hash得到的下标是这样子的（布隆过滤器不存储元素，仅仅是为一个元素是否存在打一个标志）
小强经过上面的三个hash后得到的下标分别为：2、4、5，那么该数组的2、4、5位置就会被置为1，也就是此时是这样子的
同样旺财经过上面的三个hash后得到的下标分别为：3、7、11，那么该数组的3、7、11位置就会被置为1，也就是此时是这样子的
现在假设来一个 007 经过上面的三个hash后得到的下标分别为：11、13、15因为13、和15位置是0，所以一定可以判断007 一定不存在。但是现在又来了一个
9527经过上面的三个hash后得到的下标分别为：2、5、7，但是你会发现257三个位置全部是1，那这个到底说明9527是存在还是不存在呢？
从我们上面的讲解可以 9527 之前并不存在，但是由于hash冲突，但是9527的三个下标值也刚好落在已经被置为1的下标位置，这就导致此时是无法判断9527是否存在的。这就是布隆过滤器的原理。
解决案例：
缓存击穿
缓存击穿是指缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力。
常见的解决方案有两种：
- 互斥锁
- 逻辑过期
逻辑分析：假设线程1在查询缓存之后，本来应该去查询数据库，然后把这个数据重新加载到缓存的，此时只要线程1走完这个逻辑，其他线程就都能从缓存中加载这些数据了，但是假设在线程1没有走完的时候，后续的线程2，线程3，线程4同时过来访问当前这个方法， 那么这些线程都不能从缓存中查询到数据，那么他们就会同一时刻来访问查询缓存，都没查到，接着同一时间去访问数据库，同时的去执行数据库代码，对数据库访问压力过大
使用互斥锁来解决：
因为锁能实现互斥性。假设线程过来，只能一个人一个人的来访问数据库，从而避免对于数据库访问压力过大，但这也会影响查询的性能，因为此时会让查询的性能从并行变成了串行，我们可以采用tryLock方法 + double check来解决这样的问题。
假设现在线程1过来访问，他查询缓存没有命中，但是此时他获得到了锁的资源，那么线程1就会一个人去执行逻辑，假设现在线程2过来，线程2在执行过程中，并没有获得到锁，那么线程2就可以进行到休眠，直到线程1把锁释放后，线程2获得到锁，然后再来执行逻辑，此时就能够从缓存中拿到数据了。
逻辑过期方案来解决：
方案分析：我们之所以会出现这个缓存击穿问题，主要原因是在于我们对key设置了过期时间，假设我们不设置过期时间，其实就不会有缓存击穿的问题，但是不设置过期时间，这样数据不就一直占用我们内存了吗，我们可以采用逻辑过期方案。
我们把过期时间设置在 redis的value中，注意：这个过期时间并不会直接作用于redis，而是我们后续通过逻辑去处理。假设线程1去查询缓存，然后从value中判断出来当前的数据已经过期了，此时线程1去获得互斥锁，那么其他线程会进行阻塞，获得了锁的线程他会开启一个 线程去进行 以前的重构数据的逻辑，直到新开的线程完成这个逻辑后，才释放锁， 而线程1直接进行返回，假设现在线程3过来访问，由于线程线程2持有着锁，所以线程3无法获得锁，线程3也直接返回数据，只有等到新开的线程2把重建数据构建完后，其他线程才能走返回正确的数据。
这种方案巧妙在于，异步的构建缓存，缺点在于在构建完缓存之前，返回的都是脏数据。
**互斥锁方案：**由于保证了互斥性，所以数据一致，且实现简单，因为仅仅只需要加一把锁而已，也没其他的事情需要操心，所以没有额外的内存消耗，缺点在于有锁就有死锁问题的发生，且只能串行执行性能肯定受到影响
逻辑过期方案： 线程读取过程中不需要等待，性能好，有一个额外的线程持有锁去进行重构数据，但是在重构数据完成前，其他的线程只能返回之前的数据，且实现起来麻烦
解决案例：
缓存预热
所谓缓存预热就是将一些可能经常使用数据在系统启动的时候预先设置到缓存中，这样可以避免在使用到的时候先去数据库中查询。
缓存降级
当访问量突然剧增（例如下班的点，大家都在地铁上刷手机呢）、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。
系统可以根据一些关键数据进行自动降级，降级的最终目的是保证核心服务可用，即使是有损的。但是有的一些业务的核心服务是不能降级的。这是一种丢卒保帅的思想。