Redis缓存的三大常见问题

Hello，我们又见面啦，还是小编我呦！今天主要和大家一起分享一下redis中的三大缓存问题，缓存穿透，缓存击穿和缓存雪崩哈

那就和大家先一起分享一下缓存的三大问题哦！

缓存穿透：

是指查询一个一定不存在的数据，由于缓存不命中，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。

常见的解决方案一般是两种：

（1）缓存空对象法：缓存空对象法就是如果缓存不命中，从储存层开始查询，无论数据是否存在，都将结果写入缓存，比如如果数据不存在，就将null写入redis。但是这种方式会存在一个很大的缺点，那就是redis内的缓存会越来越大！

（2）布隆过滤器：布隆过滤器是可以设置算法并且可以设置容错率，但是容错率不能为0，也就是说，布隆过滤器判断值是否存在不是100%的准确。下面就为大家介绍两种布隆过滤器，一种是谷歌的布隆过滤器，一种是redis的布隆过滤器。

1、谷歌布隆过滤器：谷歌的布隆过滤器是一种基于jvm的布隆过滤器，重启即失效，本地内存无法用在分布式场景，不支持大数据量存储

2、Redis布隆过滤器：可扩展性Bloom过滤器：一旦Bloom过滤器达到容量，就会在其上创建一个新的过滤器，不存在重启即失效或者定时任务维护的成本：基于Google实现的布隆过滤器需要启动之后初始化布隆过滤器。缺点：需要网络IO，性能比Google布隆过滤器低。

布隆过滤器优点：占用内存非常小，底层实现为位数组。

布隆过滤器实现原理：类似于java中的集合，判断值是否存在于布隆过滤器中。

布隆过滤器中可以插入参数，预计插入数据量，和误判率（不能设置为0）。误判率越高，消耗内存越低。

布隆过滤器，根据误判率和插入数据量通过算法来计算数组大小和hash函数的个数。布隆过滤器不能删除。布隆过滤器内的数量会越来越多，需定时替换，新增的数据需要重新添加到布隆过滤器。布隆过滤器存在误判的情况。

缓存雪崩：

缓存雪崩是指机器宕机或在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩。缓存雪崩出现的原因是因为大面积数据失效导致的。

对于缓存雪崩，我们的解决思路一般是两种：1、搭建一个redis高可用集群

                                        2、缓存失效的时间点尽量均匀

那么下面我们可以看一下具体的解决方法：

1. 在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。
2. 做二级缓存，A1为原始缓存，A2为拷贝缓存，A1失效时，可以访问A2，A1缓存失效时间设置为短期，A2设置为长期。
3. 不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。
4. 如果缓存数据库是分布式部署，将热点数据均匀分布在不同搞得缓存数据库中。

缓存击穿：

缓存击穿是指缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力

我们知道，使用缓存，如果获取不到，才会去数据库里获取。但是如果是热点 key，访问量非常的大，数据库在重建缓存的时候，会出现很多线程同时重建的情况。因为高并发导致的大量热点的 key 在重建还没完成的时候，不断被重建缓存的过程，由于大量线程都去做重建缓存工作，导致服务器拖慢的情况。

    1、普通分布式锁，通过setnx命令来实现分布式锁，当多个线程访问redis时，一个线程执行setnx命令时，其他线程会返回失败，直到等到当先线程完成del操作时，才可以下一次获得锁。但如果当先的线程死掉，则会发生死锁，故要给当前的key设置过期时间。

    2、redis中提供了很多锁服务，比如redLock（红锁）。

今天小编就和大家分享到这里啦，记得点个赞和关注哦！点关注，不迷路！