Redis进阶(六):缓存

1.缓存

速度快的设备可以作为速度慢的设备的缓存

缓存能够有意义：二八定律，20%的数据可以应对80%的请求

通常使用redis作为数据库的缓存（mysql）

数据库是非常重要的组件，mysql速度比较慢

因为mysql等数据库，效率比较低，所以承担的并发量有限，一旦请求数量变多了，数据库的压力就会提高。

服务器每次处理一个请求，一定都要消耗一定的系统资源，如果某个资源达到上限，就会出现故障。

处理以上问题有俩种方式：

2.缓存更新策略

1.定期生成

会把访问的数据，以日志的形式记录下来，每次数据被访问，日志会记录下来，因此就可以统计热点数据，根据日志中统计热点数据的维度来进行定期更新缓存（天、月）

这个时候就可以写一套离线流程（shell、py脚本）通过定时任务触发：a、完成统计热词的过程；b、根据热词找到搜索结果的数据 c、把缓存数据同步到缓存服务器上 d、控制这些缓存服务器的重启

这种方式可控但缺少实时性，无法应对突发事件

2.实时生成

如果在缓存查到了，返回结果

如果redis中不存在，从数据库查数据，查到的数据先保存到redis中，并且返回结果

但是这样不停的往redis中填写数据会导致redis内存占用越来越多：需要一个淘汰策略

3.缓存预热

缓存中的数据有俩种方式生成：定期生成和实时生成，定期生成不涉及预热~

那在实时生成的具体业务是：redis查询不到数据再从mysql中查询，当redis刚启动其中没有数据的时候，所有请求会给到mysql，mysql压力也会大，但随着时间的推移redis上的数据越积越多

缓存预热就是解决以上问题，缓存预热把定期生成和实时生成结合一下，先通过离线的方式，通过一些统计的途径，先把热点数据找到一批，导入到redis中。随着时间推移，逐渐就可以使用新的热点数据淘汰掉旧的数据

4.缓存穿透

查询的某个key，在redis中没有，mysql也没有，这个key肯定也不会被更新到缓存中~

这次查询没有下次还是没有，反复查询，如果这种情况出现很多会对mysql造成巨大的压力

产生原因：

1、业务设计不合理，缺少必要的参数校验

2、开发运维误操作，数据被删除

3、黑客 

如何解决

1、改进业务/加强监控报警

2、如果发现当前key不存在redis和mysql：

a、当前数据写入到redis中，value设置成非法值 "" 

b、引入布隆过滤器，每次查询redis/mysql之前，先判定一下key是否存在布隆过滤器上（把所有key存到布隆过滤器）

5.缓存雪崩

短时间内，redis中大规模key失效，导致缓存命中率陡然下降，并且mysql的压力迅速上升，甚至直接宕机。

产生原因：

1、redis挂了

2、redis没挂，可能之前短时间内设置大量的key请求，且过期时间相同

如何解决：

1、加强监控报警，加强redis集群可用性保证

2、不给key设置过期时间/过期时间添加随即因子：避免同一时刻过期

6.缓存击穿

相对于缓存雪崩，这里主要指的是热点key，突然过期了，导致大量的请求直接访问到数据库上，甚至引发数据库宕机。

我们可用通过统计的方式发现热点key，并设置永不过期，进行必要的服务降级，例如访问数据库的时候使用分布式锁，限制同时请求数据库的并发数