1、Redis缓存穿透
缓存穿透是指当用户在查询一条数据的时候，而此时数据库和缓存却没有关于这条数据的任何记录，而这条数据在缓存中没找到就会向数据库请求获取数据。用户拿不到数据时，就会一直发请求，查询数据库，这样会对数据库的访问造成很大的压力。
如：用户查询一个 id = -1 的商品信息，一般数据库 id 值都是从 1 开始自增，很明显这条信息是不在数据库中，当没有信息返回时，会一直向数据库查询，给当前数据库的造成很大的访问压力。缓存穿透的发生一般是受到 “黑客攻击” 所导致的，所以应该进行监控，如果真的是黑客攻击，及时添加黑名单
解决缓存穿透的方法：
①、缓存空对象从缓存出发，如果当前MySQL数据库不存在的信息，在redis中把它缓存成一个空对象，返回给用户。（代码维护简单，但是效果不是很好）。
②、Redis 也为我们提供了一种解决方案，那就是布隆过滤器（代码维护比较复杂，效果挺好的）。
方法1：缓存空对象
缓存空对象就是指一个请求发送过来，如果此时缓存中和数据库都不存在这个请求所要查询的相关信息，那么数据库就会返回一个空对象，并将这个空对象和请求关联起来存到缓存中，当下次还是这个请求过来的时候，这时缓存就会命中，就直接从缓存中返回这个空对象，这样可以减少访问数据库的压力，提高当前数据库的访问性能。流程如下图所示
但是这会有一个问题：如果大量不存在的请求过来，那么这时候缓存中会缓存许多空对象，如果时间一长，会导致缓存中存在大量空对象，这样不仅会占用许多的内存空间，还会浪费许多资源！我们可以将这些对象在一段时间之后清理，Redis 给我们提供了有关过期时间的命令，这样我们就可以设置空对象的时候顺便设置一个过期时间，就可以解决占用内存空间，浪费资源的问题了！
setex key seconds valule:设置键值对的同时指定过期时间(s)
redisCache.put(Integer.toString(id), null, 60) //过期时间为 60s
方法2：布隆过滤器
布隆过滤器是用来过滤东西的，它是一种基于概率的数据结构，主要判断当前某个元素是否在该集合中，运行速度快。布隆过滤器的巨大用处就是，能够迅速判断一个元素是否在一个集合中。因此他有如下三个使用场景:
- 网页爬虫对URL的去重，避免爬取相同的URL地址
- 反垃圾邮件，从数十亿个垃圾邮件列表中判断某邮箱是否垃圾邮箱（同理，垃圾短信）
- 缓存穿透，将所有可能存在的数据缓存放到布隆过滤器中，当黑客访问不存在的缓存时迅速返回避免缓存及DB挂掉。
布隆过滤器可以简单理解为是一个不怎么精确的 set 结构（set 具有去重的效果）
但是有个小问题是：当使用它的 contains 方法去判断某个对象是否存在时，它可能会误判。也就是说布隆过滤器不是特别精确，但是只要参数设置的合理，它的精确度可以控制的相对足够精确，只会有小小的误判概率。
当布隆过滤器说某个值存在时，这个值可能不存在；当它说不存在时，那就肯定不存在。
布隆过滤器特点：
- 一个非常大的二进制位数组（数组中只存在 0 和 1）
- 拥有若干个哈希函数（Hash Function）
- 在空间效率和查询效率都非常高
- 布隆过滤器不会提供删除方法，在代码维护上比较困难。
每个布隆过滤器对应到 Redis 的数据结构里面就是一个大型的位数组和几个不一样的无偏hash函数。所谓无偏就是能够把元素的 hash 值算得比较均匀。
向布隆过滤器中添加 key 时，会使用多个 hash 函数对 key 进行 hash 算得一个整数索引值然后对位数组长度进行取模运算得到一个位置，每个 hash 函数都会算得一个不同的位置。再把位数组的这几个位置都置为 1 就完成了 add 操作。（ 每一个 key 都通过若干的hash函数映射到一个巨大位数组上，映射成功后，会在把位数组上对应的位置改为1）
那为什么布隆过滤器会存在误判率呢？其实它会误判是如下这个情况：
影响布隆过滤器准确率的三个重要因素：
- 哈希函数的好坏
- 存储空间大小
- 哈希函数个数
如何提高布隆过滤器的准确率呢？
hash函数的设计也是一个十分重要的问题，对于好的hash函数能大大降低布隆过滤器的误判率。
对于一个布隆过滤器来说，如果其位数组越大的话，那么每个key通过hash函数映射的位置会变得稀疏许多，不会那么紧凑，有利于提高布隆过滤器的准确率。
对于一个布隆过滤器来说，如果key通过许多hash函数映射，那么在位数组上就会有许多位置有标志，这样当用户查询的时候，在通过布隆过滤器来找的时候，误判率也会相应降低。
2、缓存击穿
造成缓存击穿的原因有两个：
- 一个“冷门”key，突然被大量用户请求访问。
- 一个“热门”key，在缓存中时间恰好过期，这时有大量用户来进行访问。
这样会导致大并发请求直接穿透缓存，请求数据库，瞬间对数据库的访问压力增大。
解决办法：
常用的解决方案是加锁。对于key过期的时候，当key要查询数据库的时候加上一把锁，这时只能让第一个请求进行查询数据库，然后把从数据库中查询到的值存储到缓存中，对于剩下的相同的key，可以直接从缓存中获取即可。
单机环境下：直接使用常用的锁即可（如：Lock、Synchronized等）；
分布式环境下可以使用分布式锁，如：基于数据库、基于Redis或者zookeeper 的分布式锁。
3、缓存雪崩
缓存雪崩是指在某一个时间段内，缓存集中过期失效，如果这个时间段内有大量请求，而查询数据量巨大，所有的请求都会达到存储层，存储层的调用量会暴增，引起数据库压力过大甚至宕机。
原因：
- Redis突然宕机
- 大部分数据失效
举个例子：
比如我们基本上都经历过购物狂欢节，假设商家举办 23:00-24:00 商品打骨折促销活动。程序小哥哥在设计的时候，在 23:00 把商家打骨折的商品放到缓存中，并通过redis的expire设置了过期时间为1小时。这个时间段许多用户访问这些商品信息、购买等等。但是刚好到了24:00点的时候，恰好还有许多用户在访问这些商品，这时候对这些商品的访问都会落到数据库上，导致数据库要抗住巨大的压力，稍有不慎会导致，数据库直接宕机（over）。
当商品没有失效的时候是这样的：
当缓存失效的时候却是这样的：
解决方法：
redis高可用
redis有可能挂掉，多增加几台redis实例，（一主多从或者多主多从），这样一台挂掉之后其他的还可以继续工作，其实就是搭建的集群。
限流降级
在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量，对某个key只允许一个线程查询数据和写缓存，其他线程等待。
数据预热
数据加热的含义就是在正式部署之前，我先把可能的数据先预先访问一遍，这样部分可能大量访问的数据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key。
不同的过期时间
设置不同的过期时间，让缓存失效的时间点尽量均匀。
注参考博客Redis缓存穿透、击穿和雪崩_radis穿刺_野心很大的天蝎的博客-CSDN博客
