编辑
2023-11-03
缓存中间件
0
请注意,本文编写于 183 天前,最后修改于 36 天前,其中某些信息可能已经过时。

缓存预热

​ 缓存预热就是系统上线后,将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候,先查询数据库,然后再将数据缓存的问题,用户直接查询事先被预热的缓存数据,大大减少数据库的查询压力。

缓存雪崩

​ Redis主机挂了,导致Redis全盘崩溃,比如缓存中有大量数据同时过期。

如何解决呢

​ 1、监控redis服务器的性能指标。

​ 2、构建多层的缓存机构,在nginx缓存下面做redis缓存,在redis缓存下面在做ehcache缓存。

​ 3、redis缓存集群要实现高可用,可以使用主从 + 哨兵模式,或者Redis Cluster。

​ 4、数据库的性能也要优化,把数据库里面的超时查询和耗时比较高的事务想办法优化。

​ 5、开启Redis持久化机制aof/rdb,能尽快恢复缓存集群。

​ 6、要做好降级措施,如果出现缓存雪崩,要有兜底机制。可以限流、降级,短时间范围内牺牲一些客户体验,限制一部分请求访问,降低应用服务器压力,待业务低速运转后再逐步放开访问。

​ 7、LRU和LFU进行切换,LRU和LFU可以保证删除数据的时候不要去淘汰按照时间淘汰的,要去淘汰按照访问次数的。

​ 8、调整有效期的策略,例如把商品和热点新闻,我们把他们的错峰时间分开,不要让他们一次性全崩,过期时间使用固定时间+随机值的形式,稀释集中到期的key的数量。

​ 9、定期做维护,对即将过期数据做访问量分析,确认是否延时,配合访问量统计,做热点数据的延时。

缓存击穿

​ Redis中某个key过期,该key访问量巨大,多个数据请求从服务器直接压到Redis后,均未命中,在短时间内发起了大量对数据库中同一数据的访问,数据库压力暴增甚至崩溃。热点key突然失效,大量请求打到了MySQL上

如何解决呢

​ 1、预先设定:以电商为例,每个商家根据店铺等级,指定若干款主打商品,在购物节期间,加大此类信息key的过期时长。注意:购物节不仅仅指当天,以及后续若干天,访问峰值呈现逐渐降低的趋势

​ 2、对于访问频繁的热点key,可以设置长一点的失效时间或者不设置过期时间。

​ 3、后台刷新数据:启动定时任务,高峰期来临之前,刷新数据有效期,确保不丢失。

​ 4、差异失效:设置二级缓存,主A从B,更新时先更新B再更新A,查询时先查询A再查询B,如果A没有(消失或者失效)再查B。设置A、B不同的失效时间,保障不会被同时淘汰。

​ 3、互斥独占锁防止击穿,不建议使用,在高并发情况下性能低下。

缓存穿透

​ 请求查询一条记录时,先去redis再去mysql都查询不到该条记录,但是会有大量这样的请求,每次请求都会打到数据库上去,导致数据库压力暴增甚至崩溃。**Redis中大面积出现未命中,出现非正常URL访问。**比如,查询根本不存在的数据、Redis获取到null数据未进行持久化,直接返回、出现黑客攻击服务器。

如何解决呢

​ 1、缓存null,对查询结果为null的数据进行缓存(长期使用,定期清理),设定短时限,例如30-60秒,最高5分钟。

​ 2、白名单策略,提前预热各种分类数据id对应的bitmaps,id作为bitmaps的offset,相当于设置了数据白名单。当加载正常数据时放行,加载异常数据时直接拦截(效率偏低)。

​ 3、实时监控redis命中率(业务正常范围时,通常会有一个波动值)与null数据的占比,然后使用黑名单进行防控(运营)。

5、key加密,问题出现后,临时启动防灾业务key,对key进行业务层传输加密服务,设定校验程序,过来的key校验。例如每天随机分配60个加密串,挑选2到3个,混淆到页面数据id中,发现访问key不满足规则,驳回数据访问。

本文作者:whitebear

本文链接:

版权声明:本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!