为什么要使用缓存
我们做的每一个项目基本上刚开始都是一个很小的项目，每天的QPS很少，那个时候系统访问都是直接请求到数据库；后来项目越来越大，使用的人越来越多，每天对于数据库的压力剧增，为了保证“有效、有限的请求”访问到数据库，我们放大前置环节的逻辑和成本，所以缓存应运而生。
缓存的好处有以下两点：
- 提高接口的响应时间和并发量；
- 减轻数据库的压力。
但是，我们用到了缓存，就不得不考虑三个经典的场景：“缓存穿透”、“缓存击穿”、“缓存雪崩”。本文将介绍三种场景并给出合理的解决方案，如有异议，请进行友好的评论。
缓存穿透
正常情况下，一个请求过来，首先判断key是否存在，如果key存在，直接返回；如果key不存在或者已过期，查询数据库，如果数据库中存在数据，则更新缓存并返回数据；如果不存在，则直接返回空。
缓存穿透（cache penetration）是用户访问的key在数据库中一定不存在的数据，如果有人利用这个漏洞恶意系统，每次请求的压力都给到数据库，会压垮数据库，造成系统崩溃。
方案一：缓存默认值
在数据库查询不存在时，可以将其缓存为默认值。不过设置的时间不宜过长（建议设置为60s），如果过了一会儿数据库新增了该数据，时间太长的话，就会出现数据不一致的情况。
方案二：业务逻辑前置判断
如果有人为的恶意打击，用不合理的参数去请求系统，按照方案一新增了大量的不存在的key到内存中，极端情况下，缓存也被撑爆了……
所以我们可以在接口处进行数据合法性校验，进行提前拒绝。比如：a接口只允许查询18+的成年人的数据，请求带有未成年人就明显不合适。
方案三：使用布隆过滤器
如果有人很巧妙的用合理的参数但是系统内不存在的key请求系统，系统按照方案一、方案二也会新增大量的不存在key到内存中，这时又怎么办呢……
那我们可以使用布隆过滤器（本文不做扩展哈，请自行了解），当把数据写入数据库的时候，使用布隆过滤器进行标记，当有请求时，如果发现缓存消失，在去查询数据库前，先查询布隆过滤器该key是否存在，如果不存在，直接返回，不过布隆过滤器有一定的误判率，这个可以忽略。
方案四：加互斥锁或队列
经过方案一、二、三的优化，应该可以处理穿透的问题吧，但是仔细想一想，兄弟儿，我们是高并发的场景啊，所以，场景是大量的请求同一时刻都来请求同一个key，发现没有这个key，全都去访问数据库，以至于系统崩溃……
在这里，我们要加一个锁，只保证一个线程去创建缓存，其余的等待，这样就ok了。
缓存击穿
缓存击穿（Cache Breakdown）指的是一个热点key，在不停的被大量的请求访问，当这个热点key缓存失效的瞬间，大量的请求访问到数据库，以至于系统崩溃。
方案一：永不过期
提前把热点数据不设置过期时间，后台异步更新缓存。
但是！我又要说但是了！我现在举个例子，就要推翻这个方案了，打自己的脸。
我们自家的甲秀宝商城最近3月8日女神节做一次大促，把运营童鞋收集整理的关于女性热点商品都做了永不过期，但是大促当天发现面巾纸是卖的最多的，差点就要祭天了……
所以，真实场景是就像你根本无法知道女朋友想什么一样，同理你也不能真正的预估到客户想买什么，哪个是热点商品，所以，这个方案也就是面试吹吹……
方案二：加互斥锁或队列
其实我理解缓存击穿和缓存穿透差不多，所以加一个互斥锁，让一个线程正常请求数据库，其他线程等待即可（这里可以使用线程池来处理），都创建完缓存，让其他线程请求缓存即可。
缓存雪崩
缓存雪崩（Cache Avalanche）指的是当某一个时刻出现大规模的缓存失效，然后大量的请求直接访问到数据库，以至于压垮数据库，造成系统崩溃等情况。
出现这种情况的可能有两种：
- 缓存采用相同的过期时间。
- 缓存服务出现故障。
方案一：相对随机数过期时间
key的过期时间加上一个随机值，保证不是同一时间失效，即可。
方案二：分布式集群部署
单节点缓存服务容易宕机，那我们就部署个集群，然后把缓存均匀的分不到不同的服务器上，搞定。
方案三：服务限流、熔断、降级
当流量到一定的阈值或者服务出现异常、故障时，直接返回“请稍后再试”的友好性处理，让一部分用户正常使用，其他用户多重试几次，不过这样难免会降低用户体验，不过几个人有问题也总比整个系统崩溃好~
END
缓存穿透、缓存击穿、缓存雪崩，说白了核心就是“避免无效（或重复）的请求”到数据库，所以我觉得只要是以这个思想去设计都是ok的~
