缓存问题隐患
- 缓存无底洞
- 缓存穿透
- 缓存雪崩
- 缓存失效
- 热点key倾斜
- 热点key重建
- 缓存数据库双写不一致
1、缓存雪崩
问题现象：大量的缓存同一时刻失效；
典型问题：所有首页的Key失效时间都是12小时，秒杀活动大量用户涌入，假设当时每秒 6000 个请求，本来缓存在可以扛住每秒 5000 个请求，但是缓存当时所有的Key都失效了。此时 1 秒 6000 个请求全部落数据库。
解决方案：
把每个Key的失效时间都加个随机值，这样可以保证数据不会在同一时间大面积失效
setRedis（Key，value，time + Math.random() * 10000）；
如果Redis是集群部署，将热点数据均匀分布在不同的Redis库中也能避免全部失效的问题；
或者设置热点数据永远不过期，有更新操作就更新缓存就好了（比如运维更新了首页商品，那你刷下缓存就完事了，不要设置过期时间）
2、缓存穿透
问题现象：缓存和数据库中都没有的数据，而用户不断发起请求，我们数据库的 id 都是1开始自增上去的，如发起为id值为 -1 的数据或 id 为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大，严重会击垮数据库。
解决方案：
接口层增加校验，比如用户鉴权校验，参数做校验，不合法的参数直接代码Return，比如：id 做基础校验，id <=0的直接拦截等。
将对应Key的Value对写为null，过期时间设置很短
高级用法布隆过滤器（Bloom Filter）这个也能很好的防止缓存穿透的发生，他的原理也很简单就是利用高效的数据结构和算法快速判断出你这个Key是否在数据库中存在，不存在你return就好了，存在你就去查了DB刷新KV再return。
利用nginx对单个IP的访问频次做阈值控制
3、缓存击穿
指一个Key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个Key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库。
解决方案：
设置热点数据永远不过期。或者加上互斥锁就能搞定了
一般避免以上情况发生我们从三个时间段去分析下：
-
-
事前：Redis 高可用，主从+哨兵，Redis cluster，避免全盘崩溃。
-
事中：本地 ehcache 缓存 + Hystrix 限流+降级，避免MySQL被打死。
-
事后：Redis 持久化 RDB+AOF，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。
-
4、数据库与缓存双写不一致问题（秒杀场景）
读多写少： 引入分布式锁的读写锁如Redisson.getReadWriteLock(lockKey)
真正支撑高并发及高可用的复杂系统中缓存架构？
节选自： 【中华石杉】亿级流量电商详情页系统的大型高并发与高可用缓存架构实战 P1
如何让redis集群支撑几十万QPS高并发+99.99%高可用+TB级海量数据+企业级数据备份与恢复？： Redis企业级集群架构
如何支撑高性能及高并发到极致？同时缓存架构最终的安全保护层？：（nginx+luna）+redis+ehcache三级缓存架构
如何解决大value缓存的全量更新效率低下问题？：缓存维度化拆分解决方案
如何将缓存命令率提升到极致？： 双层nginx部署架构，一致性hash流量分发策略
如何解决高并发场景下，如何解决数据库与缓存双写时树不一致情况？：数据库+缓存双写一致性解决方案
如何解决高并发场景下，缓存重建时的分布式并发冲突问题？：基于zookeeper分布式锁的缓存并发重建解决方案
如何解决高并发场景下，缓存冷启动Mysql瞬间被打死问题？：基于storm实时统计热数据的分布式快速缓存预热解决方案
如何解决高并发场景下，缓存雪崩问题？事前+事中+事后的三层解决方案
如何解决高并发场景下，缓存穿透问题？避免Mysql带来过大压力：缓存穿透解决方案
如何解决高并发场景下，缓存失效问题？避免给redis集群带来过大压力？: 缓存失效解决方案
如何解决热点缓存导致单机负荷瞬间超高？：基于storm的实时热点发现，及毫秒级实时热点缓存负载均衡降级