编程界的小学生
1、概念
比如电商网站，有以下商品在redis里和mysql里。且Redis里只存放热点商品， 而不是全部。
苹果、香蕉、鸭梨等，但是用户搜了个我这电商网站里没有卖的商品，这时候redis里肯定没有搜的数据，就去请求db了。db也不一定有（有可能有有可能没有），如果没有的话那白白浪费性能了。这就是缓存穿透。量少的话就别说了，量少都没必要redis缓存。大量的话会很恐怖，比如淘宝，他无所不卖，万一真找到一个不卖的东西去搜，然后redis没有，结果都去请求mysql了。那不GG了嘛？
2、解决方案
二、缓存雪崩1、概念
1.1、情况一
大批量热点数据过期后，高并发请求，直接请求到db，引起db压力造成查询阻塞甚至宕机。
1.2、情况二
Redis挂了。导致请求都到db了。假设高并发5000个请求，本来缓存再高峰期可以抗住每秒4000个请求，但是Redis挂了，5000个请求直接干到了数据库层，这可能又把数据库给打死了。
2、解决方案
2.1、情况一的解决方案
- 简单粗暴，设置热点数据永不过期（具体还看业务是否允许）
- 将缓存失效的时间分散开，比如每个热点key的过期时间是随机的，而不是每个key都一样是固定的。这样不会遇到同时大量热点数据过期的情况，分批过期，将高并发大流量变成一部分一部分的小流量打给数据库，这样就没问题了。
2.2、情况二的解决方案
- 加一层本地ehcache缓存。也就是请求进来先查ehcache缓存，ehcache没有的话去查redis，redis也没有再去db。这时候redis挂了，但是我们本地ehcache还有，所以不会打到db层。
- 限流组件，可以设置每秒最大请求数，超过最大请求数的那些请求怎么办？走降级！可以返回一些默认值，或者友情提示啥的。
三、缓存击穿限流的好处是数据库绝对不会死，因为限流组件保证了有多少请求能进来。只要数据库不死，就能对外继续提供请求。虽然有部分用户请求走降级，但不是全部，会有大部分请求得到执行。
1、概念
某个 key 非常非常热点，访问非常的频繁，高并发访问的情况下，当这个 key在失效（可能expire过期了，也可能LRU淘汰了）的瞬间，大量的请求进来，这时候就击穿了缓存，直接请求到了数据库，一下子来这么多，数据库肯定受不了，这就叫缓存击穿。某个key突然失效，然后这时候高并发来访问这个key，结果缓存里没有，都跑到db了。
2、解决方案
- 热点数据永不过期（看业务需求。不过很少有这种场景，一般都是比如搞活动或者大促的时候才会存这些热点数据，活动过后就需要到期，不会设置永不过期。），此方法简单粗暴，不过还看具体需求。
- 分布式锁。来个请求后先锁住，然后去db查，查到后再将数据set到redis里。只有当redis里getKey没拿到数据需要请求db的时候才加锁。不影响Redis里有数据的时候处理高并发请求，也能保证db不会被打垮。
微信公众号【Java码农社区】
