Redis雪崩效应以及解决方案

Redis雪崩效应以及解决方案

缓存雪崩产生的原因

 

缓存雪崩通俗简单的理解就是：由于原有缓存失效（或者数据未加载到缓存中），新缓存未到期间（缓存正常从Redis中获取，如下图）所有原本应该访问缓存的请求都去查询数据库了，而对数据库CPU和内存造成巨大压力，严重的会造成数据库宕机，造成系统的崩溃。

 

缓存失效的时候如下图：

 

缓存失效时的雪崩效应对底层系统的冲击非常可怕！那有什么办法来解决这个问题呢？基本解决思路如下：

  第一，大多数系统设计者考虑用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，避免缓存失效时对数据库造成太大的压力，虽然能够在一定的程度上缓解了数据库的压力但是与此同时又降低了系统的吞吐量。

 第二，分析用户的行为，尽量让缓存失效的时间均匀分布。

 第三，如果是因为某台缓存服务器宕机，可以考虑做主备，比如：redis主备，但是双缓存涉及到更新事务的问题，update可能读到脏数据，需要好好解决。

 

解决方案

1：在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。

  缓存失效时的雪崩效应对底层系统的冲击非常可怕！那有什么办法来解决这个问题呢？基本解决思路如下：

 第一，大多数系统设计者考虑用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，避免缓存失效时对数据库造成太大的压力，虽然能够在一定的程度上缓解了数据库的压力但是与此同时又降低了系统的吞吐量。

 第二，分析用户的行为，尽量让缓存失效的时间均匀分布。

第三，如果是因为某台缓存服务器宕机，可以考虑做主备，比如：redis主备，但是双缓存涉及到更新事务的问题，update可能读到脏数据，需要好好解决。

 

 

解决方案

 

1：在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。

     注意:加锁排队只是为了减轻数据库的压力，并没有提高系统吞吐量。假设在高并发下，缓存重建期间key是锁着的，这是过来1000个请求999个都在阻塞的。同样会导致用户等待超时，这是个治标不治本的方法。

2：不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。

3：做二级缓存，A1为原始缓存，A2为拷贝缓存，A1失效时，可以访问A2，A1缓存失效时间设置为短期，A2设置为长期（此点为补充）

 

架构如下所示时候：

如何攻击redis？

如果再redis中有1000个key，如果同一时间失效？   直接查数据库了 不再走redis了 ！ 大连查询请求过来，，，，产生了雪崩效应~

这时候使用 限流 服务降级、熔断 的方案  这三个方案是针对redis的上一层的

 

Redis雪崩效应的解决方案

1、可以使用分布式锁   单机版的话本地锁

2、消息中间件方式

3、一级和二级缓存 Redis+Ehchache

4、均摊分配Redis的key的失效时间

 

解释：

 1、  当突然有大量请求到数据库服务器时候，进行请求限制。使用所的机制，保证只有一个线程（请求）操作。否则进行排队等待（集群分布式锁，单机本地锁）。减少服务器吞吐量，效率低。

 

 加入锁！

 

保证只能有一个线程进入  实际上只能有一个请求在执行查询操作

也可以在此处进行使用限流的策略~

 

2、使用消息中间件解决

  这种方案是最靠谱的方案！

   消息中间件 可以解决高并发！！！

  如果大量的请求进行访问时候，Redis没有值的情况，会将查询的结果存放在消息中间件中（利用了MQ同步特性）

   查不到时候 走MQ  

 

 3、一级二级缓存参考： https://www.cnblogs.com/toov5/p/9892910.html

 

4、均摊分配redis key的失效时间 

     不让在同一时间失效，不同key失效时间不同 哈哈