缓存相关问题

1.缓存预热

解决的问题：缓存预热就是系统上线后，提前将相关的缓存数据直接加载到缓存系统。避免在用户请求的时候，由于缓存中没有任何数据，而并发地全部访问数据库。

解决方法即提前将相关的缓存数据直接加载到缓存系统

2.缓存雪崩

问题：

        在一个较短的时间内，缓存中较多的key过期，恰恰就是在较短的时间内，有很多请求访问过期key而未命中，让请求到达数据库，数据库同时接收大量的请求，而无法及时处理，导致数据库崩溃。redis得不到数据库的响应，无法释放链接，导致redis集群崩溃。应用服务器无法及时得到redis的响应，同时新的请求不断到来，应用服务器崩溃。同时重启应用服务、redis服务、数据库服务，重启以后，海量请求呼啸而至，缓存中是空的，继续崩溃。

解决方案：

1.对key的过期时间进行分类错峰：均匀分布key的过期时间，避免大量key在较短时间内集中过期。

2.超热key永不过期

3.使用mq削峰，让呼啸而至的请求排队。（用户体验不好）

4.避免mysql慢查询 (超过long_query_time参数设定的时间阈值（默认10s），就被认为是慢的，是需要优化的。慢查询被记录在慢查询日志里。慢查询日志默认是不开启的。如果需要优化SQL语句，就可以开启这个功能，它可以让你很容易地知道哪些语句是需要优化的。)

3.缓存击穿

问题：

        redis中某一个高热key过期，同时海量请求都在访问这同一个高热key，均未命中。海量请求呼啸而至，奔向数据库，数据库崩溃

解决方案：

1.在特殊节日前，预先设定阶段性高热key的过期时间

2.现场调整，对自然流量所推出来的新的高热key，延长其过期时间或者设置其为永久key

4.缓存穿透

问题：

        redis中出现大量未命中的请求。出现非正常URL的访问，这些访问由于没有走正常的应用，所以可以故意访问一类不可能存在的key，这些key不在缓存中，数据库中也没有。后续出现大量以上请求，很可能是懂技术的人在对服务器进行攻击！

解决方案：

1.缓存null：对查询结果为null的数据也进行缓存，设定较短的过期时间

2.白名单策略:采用布隆过滤器，布隆过滤器的思想是，将所有可能存在的key哈希到一个足够大的 bitmap 中，一个一定不存在的数据会被这个 bitmap 拦截掉，从而避免了对底层存储系统的查询压力附加 对于空间的利用到达了一种极致