缓存穿透
指查询一个数据库一定不存在的数据。
正常的使用缓存流程大致是，数据查询先进行缓存查询，如果key不存在或者key已经过期，再对数据库进行查询，并把查询到的对象，放进缓存。如果数据库查询对象为空，则不放进缓存。
假如有恶意攻击，就可以利用这个漏洞，对数据库造成压力，甚至压垮数据库。
解决办法
缓存空对象
如果数据库查询对象为空，就缓存空对象，再次访问这个数据，就会从缓存中获取，以此保护后端数据源。
如果缓存NULL，是做无用功，还是会造成缓存穿透。
缓存空对象遇到的两个问题:
1、 如果是网络恶意攻击（每次key不一样，且数据库不存在），缓存占用了更多的内存。
解决方案：
缓存空对象要考虑到缓存时间的设置。这时候设置一个较短的过期时间（通常设定的缓存过期为60秒），就会自动剔除这些键。
2、 如果过期时间设置的过大，数据库在此期间正好添加了该数据，就会出现数据不一致场景。
解决方案：
通过消息系统或者其它方式来清除缓存中的空对象。
使用布隆过滤器
布隆过滤器由一个很长且初值都为0的二进制（bit）数组和N个哈希函数组成，可以用来快速判断某个数据是否存在。当数据写入数据库时，布隆过滤器会通过三个操作完成标记：
- 使用N个hash函数，分别计算这个数据的hash值，得到N个hash值。
- 把这N个hash值对二进制数组的长度取模，得到每个hash值在数组中的位置，把对应位置设置为1。
- 如果数据不存在，那么就没用使用布隆过滤器标记过数据，那么，bit数组对应的bit位为零。只要二进制数组中这N个位置有一个不为1，就表明布隆过滤器就没标记过该数据。
反过来说，如果通过哈希函数算出来的值，对应的地方都是1，那么我们能够肯定的得出：这个数据一定存在于这个布隆过滤器中吗？
答案是否定的，因为多个不同的数据通过hash函数算出来的结果是会有重复的，所以会存在某个位置是别的数据通过hash函数置为的1。
我们可以得到一个结论：布隆过滤器可以判断某个数据一定不存在，但是无法判断一定存在。
举例：
- 默认位数组：
[0，0，0，0，0，0] - 比方说有个已知key的下标是0，2，5，那么对应位数组：
[1，0，1，0，0，1] - 判断某个未知key存不存在的时候，假设我们计算出来的下标是0，2，4，那么对应位数组：
[1，0，1，0，1，0]，此时位数组内5对应下标值为0，而已知key位数组的5对应下标位1，说明这两个一定不是同一个key。 - 相反，如果某个key计算出来的下标为
[1，0，1，0，0，1]，只能说这个key可能存在，因为这个位置可能是其它key计算出来的
布隆过滤器优缺点
- 优点：优点很明显，二进制组成的数组，占用内存极少，并且插入和查询速度都足够快。
- 缺点：随着数据的增加，误判率会增加；还有无法判断数据一定存在；另外还有一个重要缺点就是无法删除数据。
我们可以使用Redis的bitmap来实现简单的布隆过滤器，bitmap支持2^32大小，对应到内存也就是512MB，可以放下2亿左右的数据，性能高，空间占用率及小，省去了大量无效的数据库连接。
解决缓存击穿的问题时，当把数据写入数据库，使用布隆过滤器做标记。当缓存消失后，在去数据库查询之前，通过查询布隆过滤器判断数据是否存在，如果不存在，就不查询数据库。
请求入库添加检测
把恶意请求（参数不合理、参数非法、参数不存在或者id小于0）直接过滤掉。
缓存击穿
是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。
解决方法
设置热点数据永远不过期
从redis上看，确实没有设置过期时间，这就保证了，不会出现热点key过期问题，也就是“物理”不过期。
从功能上看，如果不过期，那不就成静态的了吗？所以我们把过期时间存在key对应的value里，如果发现要过期了，通过一个后台的异步线程进行缓存的构建。
从实战上看，这种方法对于性能非常友好，唯一不足的就是构建缓存时候，其余线程(非构建缓存的线程)可能访问的是老数据，但是对于一般的互联网功能来说这个还是可以忍受。
加互斥锁（mutex key）
大体思路就是只让一个线程构建缓存，其他线程等待构建缓存的线程执行完，重新从缓存获取数据就可以了，如下图所示。
大道至简，通常情况下，设置热点数据永远不过期就好了，互斥锁（mutex key）真心用不上。
缓存雪崩
指在某一个时间段，缓存集中过期失效。
当某一个时刻出现大规模的缓存失效的情况，那么就会导致大量的请求直接打在数据库上面，导致数据库压力巨大，如果在高并发的情况下，可能瞬间就会导致数据库宕机。这时候如果运维马上又重启数据库，马上又会有新的流量把数据库打死。这就是缓存雪崩。
造成缓存雪崩的原因是什么？
造成缓存雪崩的关键在于在同一时间大规模的key失效。
为什么会出现这个问题呢，有下面几种可能：
- 第一种可能是Redis宕机，
- 第二种可能是采用了相同的过期时间。
解决方法
过期时间设置随机值
在原有的失效时间上加上一个随机值，比如，1-5分钟随机。这样就避免了同一时间大量数据过期现象的发生而导致缓存雪崩。
分布式部署且均匀分布热点数据
如果缓存数据库是分布式部署，将热点数据均匀分布在不同搞得缓存数据库中。同时，分布式集群可以防止Redis宕机导致缓存雪崩的问题。
热点数据永不过期
设置热点数据永远不过期。
缓存雪崩的兜底措施
如果真的发生了缓存雪崩，有没有什么兜底的措施？
1、使用熔断机制。当流量到达一定的阈值时，就直接返回“系统拥挤”之类的提示，防止过多的请求打在数据库上。至少能保证一部分用户是可以正常使用，其他用户多刷新几次也能得到结果。
2、提高数据库的容灾能力，可以使用分库分表，读写分离的策略。
举例说明
比如，针对电商项目，一般是采取不同分类商品，缓存不同周期。
在同一分类中的商品，加上一个随机因子。这样能尽可能分散缓存过期时间， 而且，热门类目的商品缓存时间长一些，冷门类目的商品缓存时间短一些，也能节省缓存服务的资源。
其实集中过期，倒不是非常致命，比较致命的缓存雪崩，是缓存服务器某个节点宕机或断网。
因为自然形成的缓存雪崩，一定是在某个时间段集中创建缓存，那么那个时候数据库能顶住压力，这个时候，数据库也是可以顶住压力的。无非就是对数据库产生周期性的压力而已。
而如果因为缓存服务节点的宕机，对数据库服务器造成的压力是不可预知的，很有可能瞬间就把数据库压垮。
总结
缓存雪崩和缓存击穿主要是数据不在缓存上，而缓存穿透是数据既不在缓存上，也不在数据上。
缓存穿透的解决方法：
- 入口进行合法性验证
- 缓存空值或者缺省值
- 使用布隆过滤器快速判断
缓存击穿的解决方法：
- 不设置过期时间
- 加互斥锁
缓存雪崩的解决方法：
- 给过期时间加上小的随机数
- 服务降级
- 服务熔断
- 请求限流
- redis 设置主从集群
缓存穿透、缓存击穿、缓存雪崩的预防方案：
使用服务降级、请求熔断、请求限制会影响用户使用体验，最好使用预防方案。
- 针对缓存穿透，在请求入口做规范校验，以及使用布隆过滤器判断数据是否存在。
- 针对缓存击穿，不要设置过期时间。
- 针对缓存雪崩，合理设置数据过期时间，以及搭建redis主从集群。
