一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第8天，点击查看活动详情。
缓存击穿（失效）
由于大批量缓存同一时间失效肯能导致大量请求同时穿透缓存直达数据库，可能会造成数据库瞬间压力过大甚至把数据库拖垮，对于这种情况我们在批量增加缓存时最好将这一批数据的缓存过期时间设置为一个固定时间+一个随机时间。
缓存穿透
缓存穿透是指查询一个根本不存在的数据，缓存层和存储层都不会命中，通常处于容错的考虑，如果从存储查询不到数据则不写入缓存层。
缓存穿透将导致不存在的数据每次请求都要到存储层去查询，失去了缓存保护后端存储的意义。
造成缓存穿透的基本原因有两个：
- 自身业务代码或者数据出现问题。
- 一些恶意攻击、爬虫等造成大量空命中。
缓存穿透解决方案
缓存空对象
从数据库查询不到数据后，缓存写入空对象，设置个过期时间。
布隆过滤器
对于恶意攻击，向服务器请求大量不存在的数据造成的缓存穿透，还可以用布隆过滤器做一次过滤，对于不存在的数据布隆过滤器一般都能过滤掉，从而拦截住请求不在向数据库发送。
当布隆过滤器说某个值存在时，这个值可能存在，当说他不存在时，那就肯定不存在。
缓存雪崩
缓存雪崩指的是缓存层支撑不住后宕机后，流量会像奔逃的野牛一样，打向后端存储层。
由于缓存层承载着大量请求，有效保护了存储层，但是如果缓存层由于某些原因不能提供服务，于是大量请求都会打到存储层，存储层的调用量会暴增，造成存储层也会级联宕机的情况。
预防和解决缓存雪崩的方案
- 保证缓存服务的高可用性，比如使用 Redis Sentinel 或 Redis Cluster。
- 缓存服务的拆分，不同服务使用不同的 Redis 实例，降低 Redis 实例的并发请求。
- 依赖隔离组件为后端限流熔断并降级。比如使用 Sentinel 或 Hystrix 限流降级组件。
- 提前演练。在项目上线前演练缓存层宕掉后，应用以及后端的负载情况，以及肯能出现的问题，在此基础上做一些应急预案。
热点缓存 key 重建优化
开发人员使用“缓存+过期时间”的策略既可以加速数据读写， 又保证数据的定期更新， 这种模式基本能够满足绝大部分需求。 但是有两个问题如果同时出现， 可能就会对应用造成致命的危害： 当前key是一个热点key（例如一个热门的娱乐新闻），并发量非常大。
- 当前key是一个热点key（例如一个热门的娱乐新闻），并发量非常大。
- 重建缓存不能在短时间完成， 可能是一个复杂计算， 例如复杂的SQL、 多次IO、 多个依赖等。
在缓存失效的瞬间， 有大量线程来重建缓存， 造成后端负载加大， 甚至可能会让应用崩溃。
要解决这个问题主要就是要避免大量线程同时重建缓存。
我们可以利用互斥锁加双重检测锁来解决，此方法只允许一个线程重建缓存， 其他线程等待重建缓存的线程执行完， 重新从缓存获取数据即可。
缓存与数据库双写不一致
在大并发下，同时操作数据库与缓存会存在数据不一致性问题
双写不一致情况
读写并发不一致
解决方案
- 并发几率很小的个人维度的数据，几乎不用考虑，加上缓存过期时间，缓存失效后查询主动更新
- 业务上是否能容忍一定时间的不一致，如能容忍的话，加上缓存过期时间
- 如果不能容忍缓存数据不一致，可以通过加分布式读写锁保证并发读写或写写的时候按顺序排好队，读读的时候相当于无锁。
- 也可以用阿里开源的canal通过监听数据库的binlog日志及时的去修改缓存，但是引入了新的中间件，增加了系统的复杂度。
今天的分享就到这里了，关于分布式锁我们下期介绍。
