如何解决redis的缓存雪崩与击穿

话题一：缓存击穿问题

业务开发中为了应对高并发,都会引入redis进行缓存，但是某些情况下会出现缓存击穿的问题，大量请求打到后端数据库。

1. 大key同时过期，导致缓存击穿。

2.爬虫发现URL规律，发起大量恶意请求

3.业务自身代码或数据出现问题

解决方案一：过期时间随机

解决方案二：分布式锁，限制访问DB线程数

通常解决方案往往是使用互斥锁，让一个线程访问数据库，并将数据更新到缓存中，其他线程访问缓存中数据。如果是基于jvm锁机制的话，只能解决单机问题，也就是只让本机一个线程访问缓存，但是分布式条件下是不能使用的。所以，要基于缓存的分布式锁来实现。

//查询缓存
if(redis.contains(key)){
       return value
}
------------  用锁保护mysql --------------------
tryLock....................
//查询数据库
if(redis.contains(key)){ //在锁里面在检查一次
    value = queryDB()
} else {
    return value;
}
redis.set(key,value) //重建缓存
return value;

unLock.......................
--------------------------------

分布式锁可以采用Redission来实现

解决方案三：布隆过滤器（Redis）

https://blog.csdn.net/fouy_yun/article/details/81075432

把所有的数据通过布隆过滤器放到内存中

话题二：缓存雪崩

在互联网系统运行过程中会出现缓存热点key的情况，比如微博上的某个热点话题，会有大量的人关注，这个key会集中在某一个redis cluster分片机器上，造成这台机器宕机，这些热点key转移到其他分片又会造成其他机器继续宕机，造成了雪崩的问题。

解决雪崩的两个关键点，一是如何快速发现热点可以，二是及时把热点key缓存到JVM堆内存（EHCache）

可以参考有赞TMC的思路，及时发现热点key，然后缓存到本地堆内存，TMC 在提供“热点探测” + “本地缓存”的核心能力同时，也为应用服务提供了灵活的配置选择，应用服务可以结合实际业务情况在“热点阈值”、“热点 key 探测数量”、“热点黑白名单”维度进行自由配置以达到更好的使用效果。