概述
1、缓存预热
(1)问题排查
- 请求数量较高
- 主从之间数据吞吐量较大,数据同步操作频度较高
(2)解决方案
缓存预热就是在系统启动时,提前将相关的缓存数据加载到 Redis 中,减轻应用直连数据库对数据库造成的压力。
预热过程:
1、日常运营中,统计分析出热点数据;
2、构建数据留存队列;
3、将统计结果中的数据,预先加载到 Redis 中进行预热;
4、提速数据加速过程;
5、使用脚本固化预热过程;
2、缓存雪崩
缓存雪崩就是瞬间过期数据量过大,导致对数据库造成压力
(1)场景:
1、在较短的时间内,大量的 Key 同时过期;
2、此时大量的请求访问过期数据,Redis 未命中,Redis 向数据库进行请求查询;
3、数据库接收到大量的 Redis 请求,无法及时处理,造成 Redis 请求积压,Redis 开始出现超时问题;
4、数据库连接激增,导致数据库崩溃;
5、Redis 服务器资源被严重占用,导致 redis 服务器崩溃;
6、此时客户端请求持续增加,应用服务器崩溃;
7、应用服务器,Redis,数据库全部重启,重启之后缓存中没有数据,面临再次崩溃的局面
(2)解决方案
- 缓存策略切换:LRU 与 LFU 切换;
- 数据有效期策略调整:
- 根据业务数据有效期进行业务错峰;
- 过期数据使用随机数过期,避免过期 Key 集中释放;
- 超热 数据使用永久KEY;
- 适当的进行数据加锁
- 更多的页面静态化处理;
- 构建多级缓存结构,比如 Nginx 缓存,Redis 缓存,应用缓存等;
- 对数据库查询进行优化;
- 构建灾难预警进制:监控 Redis 服务CPU,内存,查询响应时间,线程数等
- 业务限流、降级:短时间内牺牲一些用户体验,限制一部分用户的请求,降低请求压力,待数据、性能恢复之后逐步放开业务;
3、缓存击穿
缓存击穿就是单个超热数据过期的瞬间,Redis 无法命中,大量的请求放行给了数据库,同一时间大量的数据库请求,造成数据崩溃
(1)场景
Redis 中的某个超热 Key 过期了,该Key 无法命中,放行给了数据库查询,造成数据库压力激增;
(2)解决方案:
- 预先设定:预先分析,对超热的 Key 进行延长过期时间的处理;
- 实时监控:实时监控业务流量,对大流量业务进行临时调整;如延长数据过期时间等
- 二级缓存:设置不同失效时间的数据,保证数据不被同时淘汰;
- 加锁:添加分布式锁,防止被击穿;
4、缓存穿透
**Redis 中缓存命中率降低,
(1)现象
1、在系统平稳运行的过程,应用服务器流量增大;
2、Redis 服务中心的缓存命中率随着时间逐步降低;但 Redis 内存稳定,CPU占用激增;
3、数据库服务器压力激增,导致数据库服务崩溃;
(2)场景
1、获取的数据在数据库中不存在,数据库查不到,无法进行缓存,每次请求都是直连数据库;
2、出现类似黑客攻击场景,非正常的业务访问;
(3)解决方案
- 白名单策略
- 提前预热各种分类数据对应的 bitmaps,id作为 bitmaps的 offset,相当于设置了数据白名单。当加载正常数据时,放行,加载异常数据时直接拦截(效率偏低)
- 使用布隆过滤器(有关布隆过滤器的命中问题对当前状况可以忽略;
- 实施监控实时监控
- redist命中率(业务正常范国时,通常会有一个波动值)与null数据的占比
- 非活动时段波动:通常检测3-5倍,超过5倍纳入重点排查对象
- 活动时段波动:通常检测10-50倍,超过50倍纳入重点排查对象
- Key 加密
- 问题出现后,临时启动防灾业务key,对key进行业务层传输加密服务,设定校验程序,过来的key校验
- 例如每天随机分配60个加密串,挑选2到3个,混淆到页面数据中,发现访问key不满足规则,驳回数据访问;
最后
以上就是调皮小熊猫为你收集整理的Redis 企业级应用的全部内容,希望文章能够帮你解决Redis 企业级应用所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
发表评论 取消回复