Redis缓存机制

Redis 的键删除策略：

Redis的过期删除策略就是:惰性删除和定期删除两种策略配合使用。

惰性删除:惰性删除不会去主动删除数据，而是在访问数据的时候，再检查当前键值是否过期，如果过期则执行删除并返回null给客户端，如果没有过期则返回正常信息给客户端。它的优点是简单，不需要对过期的数据做额外的处理，只有在每次访问的时候才会检查键值是否过期，缺点是删除过期键不及时，造成了一定的空间浪费。
定期删除: Redis会周期性的随机测试一批设置了过期时间的key并进行处理。测试到的已过期的key将被删除。

1、定时删除
  在设置某个key 的过期时间同时，我们创建一个定时器，让定时器在该过期时间到来时，立即执行对其进行删除的操作。
优点:定时删除对内存是最友好的，能够保存内存的key一旦过期就能立即从内存中删除。
缺点:对CPU最不友好，在过期键比较多的时候，删除过期键会占用一部分CPU时间，对服务器的响应时间和吞吐量造成影响。
2、惰性删除
  设置该key过期时间后，我们不去管它，当需要该key时，我们在检查其是否过期，如果过期，我们就删掉它，反之返回该key。
优点:对CPU友好，我们只会在使用该键时才会进行过期检查，对于很多用不到的key不用浪费时间进行过期检查。
缺点:对内存不友好，如果一个键已经过期，但是一直没有使用，那么该键就会一直存在内存中，如果数据库中有很多这种使用不到的过期键，这些键便永远不会被删除，内存永远不会释放。从而造成内存泄漏。
3、定期删除
  每隔一段时间，我们就对一些key进行检查，删除里面过期的key。
优点:可以通过限制删除操作执行的时长和频率来减少删除操作对CPU的影响。另外定期删除，也能有效释放过期键占用的内存。
缺点:难以确定删除操作执行的时长和频率。如果执行的太频繁，定期删除策略变得和定时删除策略一样，对CPU不友好。如果执行的太少，那又和惰性删除一样了，过期键占用的内存不会及时得到释放。另外最重要的是，在获取某个键时，如果某个键的过期时间已经到了，但是还没执行定期删除，那么就会返回这个键的值，这是业务不能忍受的错误。
 

---

缓存异常处理：

缓存异常有四种类型：

1. 缓存和数据库不一致。

2. 缓存雪崩。

3. 缓存击穿。

4. 缓存穿透。

1. 如何保证和数据库双写的一致性？

四种方案：

1.先更新数据库，后更新缓存。

2.先更新缓存，后更新数据库。

3.先删除缓存，后更新数据库。

4.先更新数据库，后删除缓存。
 

  第一种和第二种方案，没有人使用的，因为第一种方案存在问题是:并发更新数据库场景下，会将脏数据刷到缓存。
  第二种方案存在的问题是:如果先更新缓存成功，但是数据库更新失败，则肯定会造成数据不一致。目前主要用第三和第四种方案。

● 先删除缓存，后更新数据库

该方案也会出问题，此时来了两个请求，请求A(更新操作）和请求B(查询操作)

1. 请求A进行写操作，删除缓存。
2. 请求B查询发现缓存不存在。

3. 请求B去数据库查询得到旧值。

4. 请求B将旧值写入缓存。
5. 请求A将新值写入数据库。
上述情况就会导致不一致的情形出现。而且，如果不采用给缓存设置过期时间策略，该数据永远都是脏数据。

解决方法：

延时双删：

(1）先淘汰缓存
(2）再写数据库（这两步和原来一样)
(3）休眠1秒，再次淘汰缓存，这么做，可以将1秒内所造成的缓存脏数据，再次删除。确保读请求结束，写请求可以删除读请求造成的缓存脏数据。自行评估自己的项目的读数据业务逻辑的耗时，写数据的休眠时间则在读数据业务逻辑的耗时基础上，加几百ms即可。
如果使用的是Mysql的读写分离的架构的话，那么其实主从同步之间也会有时间差。

● 先更新数据库，后删除缓存

  这一种情况也会出现问题，比如更新数据库成功了，但是在删除缓存的阶段出错了没有删除成功，那么此时再读取缓存的时候每次都是错误的数据了。
 

缓存击穿:

  缓存击穿跟缓存雪崩有点类似，缓存雪崩是大规模的key失效，而缓存击穿是某个热点的key失效，大并发集中对其进行请求，就会造成大量请求读缓存没读到数据，从而导致高并发访问数据库，引起数据库压力剧增。这种现象就叫做缓存击穿。
从两个方面解决，第一是否可以考虑热点key不设置过期时间，第二是否可以考虑降低打在数据库上的请求数量。
解决方案:
●在缓存失效后，通过互斥锁或者队列来控制读数据写缓存的线程数量，比如某个key只允许一个线程查询数据和写缓存，其他线程等待。这种方式会阻塞其他的线程，此时系统的吞吐量会下降。

●热点数据缓存永远不过期。永不过期实际包含两层意思:
（1 物理不过期，针对热点key不设置过期时间.
（2 逻辑过期，把过期时间存在key对应的value里，如果发现要过期了，通过一个后台的异步线
程进行缓存的构建。
 

缓存穿透:

  缓存穿透是指用户请求的数据在缓存中不存在即没有命中，同时在数据库中也不存在，导致用户每次请求该数据都要去数据库中查询一遍。如果有恶意攻击者不断请求系统中不存在的数据，会导致短时间大量请求落在数据库上，造成数据库压力过大，甚至导致数据库承受不住而宕机崩溃。 

  缓存穿透的关键在于在Redis中查不到key值，它和缓存击穿的根本区别在于传进来的key在Redis中是不存在的。假如有黑客传进大量的不存在的key，那么大量的请求打在数据库上是很致命的问题，所以在日常开发中要对参数做好校验，一些非法的参数，不可能存在的key就直接返回错误提示。
 

解决办法：

1. 将无效的key存放进Redis中:
  当出现Redis查不到数据，数据库也查不到数据的情况，我们就把这个key保存到Redis中，设置
value="null"，并设置其过期时间极短，后面再出现查询这个key的请求的时候，直接返回null，就不需要再查询数据库了。但这种处理方式是有问题的，假如传进来的这个不存在的Key值每次都是随机的，那存进Redis也没有意义。
2. 使用布隆过滤器:
  如果布隆过滤器判定某个key 不存在布隆过滤器中，那么就一定不存在，如果判定某个key存在，那么很大可能是存在(存在一定的误判率)。于是我们可以在缓存之前再加一个布隆过滤器，将数据库中的所有key都存储在布隆过滤器中，在查询Redis前先去布隆过滤器查询key是否存在，如果不存在就直接返回，不让其访问数据库，从而避免了对底层存储系统的查询压力。
如何选择 : 针对一些恶意攻击，攻击带过来的大量key是随机，那么我们采用第一种方案就会缓存大量不存在key的数据。那么这种方案就不合适了，我们可以先对使用布隆过滤器方案进行过滤掉这些key。所以，针对这种key异常多、请求重复率比较低的数据，优先使用第二种方案直接过滤掉。而对于空数据的key有限的，重复率比较高的，则可优先采用第一种方式进行缓存。

缓存雪崩:

  如果缓在某一个时刻出现大规模的key失效，那么就会导致大量的请求打在了数据库上面，导致数据库压力巨大，如果在高并发的情况下，可能瞬间就会导致数据库宕机。这时候如果运维马上又重启数据库，马上又会有新的流量把数据库打死。这就是缓存雪崩。
造成缓存雪崩的关键在于同一时间的大规模的key失效，主要有两种可能 : 第一种是Redis宕机，第二种可能就是采用了相同的过期时间。
 

缓存预热:

  缓存预热是指系统上线后，提前将相关的缓存数据加载到缓存系统。避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题，用户直接查询事先被预热的缓存数据。
  如果不进行预热，那么Redis初始状态数据为空，系统上线初期，对于高并发的流量，都会访问到数据库中，对数据库造成流量的压力。
缓存预热解决方案 :
  数据量不大的时候，工程启动的时候进行加载缓存动作;·数据量大的时候，设置一个定时任务脚本，进行缓存的刷新;·数据量太大的时候，优先保证热点数据进行提前加载到缓存。