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，并设置永不过期，进行必要的服务降级，例如访问数据库的时候使用分布式锁，限制同时请求数据库的并发数