缓存穿透
请求都跑到存储层，失去了缓存包含存储的意义。
造成的原因
- 自身业务代码或者数据出现问题
- 一些恶意攻击、 爬虫等造成大量空命中
解决方案
- 缓存空对象
- 布隆过滤器
- 布隆过滤器不能删除数据，如果要删除得重新初始化数据。
缓存失效(击穿)
由于大批量缓存在同一时间失效可能导致大量请求同时穿透缓存直达数据库
解决方案
- 我们在批量增加缓存时将这一批数据的缓存过期时间设置为一个随机时间
缓存雪崩
缓存雪崩指的是缓存层支撑不住或宕掉后， 流量会像奔逃的野牛一样， 打向后端存储层。
预防和解决缓存雪崩问题
- 保证缓存层服务高可用性，比如使用Redis Sentinel或Redis Cluster。
- 依赖隔离组件为后端限流熔断并降级。比如使用Sentinel或Hystrix限流降级组件。
- 提前演练。 在项目上线前， 演练缓存层宕掉后， 应用以及后端的负载情况以及可能出现的问题， 在此基础上做一些预案设定。
热点缓存key重建优化
在缓存失效的瞬间， 有大量线程来重建缓存， 造成后端负载加大， 甚至可能会让应用崩溃。
我们可以利用互斥锁来解决，此方法只允许一个线程重建缓存， 其他线程等待重建缓存的线程执行完， 重新从缓存获取数据即可。
缓存与数据库双写不一致
在大并发下，同时操作数据库与缓存会存在数据不一致性问题
解决方案
- 给缓存数据加上过期时间，每隔一段时间触发读的主动更新即可。
- 如果不能容忍缓存数据不一致，可以通过加分布式读写锁 保证并发读写或写写的时候按顺序排好队，读读的时候相当于无锁。
- 可以用阿里开源的canal通过监听数据库的binlog日志及时的去修改缓存，但是引入了新的中间件，增加了系统的复杂度。
总结：
以上我们针对的都是读多写少 的情况加入缓存提高性能，如果写多读多的情况又不能容忍缓存数据不一致，那就没必要加缓存了，可以直接操作数据库。
如果数据库抗不住压力，还可以把缓存作为数据读写的主存储，异步将数据同步到数据库，数据库只是作为数据的备份。