redis缓存雪崩

缓存雪崩

 

缓存雪崩，是指在某一个时间段，缓存集中过时失效。

产生雪崩的缘由之一，好比在写本文的时候，立刻就要到双十二零点，很快就会迎来一波抢购，这波商品时间比较集中的放入了缓存，假设缓存一个小时。那么到了凌晨一点钟的时候，这批商品的缓存就都过时了。而对这批商品的访问查询，都落到了数据库上，对于数据库而言，就会产生周期性的压力波峰。

 

 解决思路：

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

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

　　第三，若是是由于某台缓存服务器宕机，能够考虑作主备，好比：redis主备，可是双缓存涉及到更新事务的问题，update可能读到脏数据，须要好好解决。

 

其实集中过时，倒不是很是致命，比较致命的缓存雪崩，是缓存服务器某个节点宕机或断网。由于天然造成的缓存雪崩，必定是在某个时间段集中建立缓存，那么那个时候数据库能顶住压力，这个时候，数据库也是能够顶住压力的。无非就是对数据库产生周期性的压力而已。可是缓存服务节点的宕机，对数据库服务器形成的压力是不可预知的，颇有可能瞬间就把数据库压垮。

 

 缓存失效的时候以下图：

两种实际方法：

1. 并发量不是特别多的时候，使用最多的解决方案是加锁排队。

 

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

注意：加锁排队的解决方式分布式环境的并发问题，有可能还要解决分布式锁的问题；线程还会被阻塞，用户体验不好！所以，在真正的高并发场景下不多使用！

 

2.还有一个解决办法解决方案是：给每个缓存数据增长相应的缓存标记，记录缓存的是否失效，若是缓存标记失效，则更新数据缓存。

 

解释说明：

　　缓存标记：记录缓存数据是否过时，若是过时会触发通知另外的线程在后台去更新实际key的缓存；

　　缓存数据：它的过时时间比缓存标记的时间延长1倍，例：标记缓存时间30分钟，数据缓存设置为60分钟。 这样，当缓存标记key过时后，实际缓存还能把旧数据返回给调用端，直到另外的线程在后台更新完成后，才会返回新缓存。

 

3. 好比作电商项目的时候，通常是采起不一样分类商品，缓存不一样周期。在同一分类中的商品，加上一个随机因子。这样能尽量分散缓存过时时间，并且，热门类目的商品缓存时间长一些，冷门类目的商品缓存时间短一些，也能节省缓存服务的资源。

 

关于缓存崩溃的解决方法，这里提出了三种方案：使用锁或队列、设置过时标志更新缓存、为key设置不一样的缓存失效时间，还有一各被称为“二级缓存”的解决方法，有兴趣的读者能够自行研究。