1、缓存预热
问题表现:
- 服务器启动后迅速宕机
问题分析:
- 请求数量较高
- 主从之间数据吞吐量较大,数据同步操作频度较高
解决方案:
- 日常例行统计数据访问记录,统计访问频度较高的热点数据,redis优先加载级别较高的热点数据
- 利用分布式多服务器同时进行数据读取,提速数据加载过程
- 使用脚本程序固定触发数据预热过程,热点数据主从同时预热
2、缓存雪崩
问题表现:
问题分析:
解决方案:
- 更多的页面静态化处理
- 构建多级缓存架构:Nginx缓存+redis缓存+ehcache缓存
- 灾难预警机制
监控redis服务器性能指标:cpu使用率、内存容量、查询平均响应时间、线程数 - 限流、降级
短时间范围内牺牲一些客户体验,限制一部分请求访问,降低应用服务器压力,待业务低速运转后再逐步放开访问 - 数据有效期策略调整
根据业务数据有效期进行分类错峰,A类90分钟,B类80分钟,C类70分钟
过期时间使用固定时间+随机值的形式,稀释集中到期的key的数量
总结:
缓存雪崩就是瞬间过期数据量太大,导致对数据库服务器造成压力。如能够有效避免过期时间集中,可以有效解决雪崩现象的出现(约40%),配合其他策略一起使用,并监控服务器的运行数据,根据运行记录做快速调整
3、缓存击穿
问题表现:
问题分析:
- Redis中某个key过期,该key访问量巨大(高热)
解决方案:
- 以电商为例,每个商家有指定若干款主打商品,在购物节期间,加大此类信息key的过期时长
- 监控访问量,对自然流量激增的数据延长过期时间或设置为永久性key
- 启动定时任务,高峰期来临之前,刷新数据有效期,确保不丢失
- 加分布式锁,防止被击穿,但这个有性能瓶颈
总结:
缓存击穿就是单个高热数据过期的瞬间,数据访问量较大,未命中redis后,发起了大量对同一数据的数据库访问,导致对数据库服务器造成压力
4、缓存穿透
问题表现:
问题排查:
问题分析:
解决方案:
- 缓存null
对查询结果为null的数据进行缓存(长期使用,定期清理),设定短时限,例如30-60秒,最高5分钟 - 白名单策略
提前预热各种分类数据id对应的bitmaps,id作为bitmaps的offset,相当于设置了数据白名单。当加载正常数据时,放行,加载异常数据时直接拦截(效率偏低) - 实施监控
实时监控redis命中率(业务正常范围时,通常会有一个波动值)与null数据的占比 - key加密
对key进行业务层传输加密服务,设定校验程序,过来的key校验,例如每天随机分配60个加密串,挑选2到3个,混淆到页面数据id中,发现访问key不满足规则,驳回数据访问
总结:
缓存穿透就是访问了不存在的数据,跳过了合法数据的redis数据缓存阶段,每次访问数据库,导致对数据库服务器造成压力。
5、性能指标监控
5.1 监控指标
常见的监控指标有:
5.2 监控工具或命令
1、工具
2、
命令benchmark
- 指令
redis-benchmark [-h ] [-p ] [-c ] [-n <requests]> [-k ]
-
参数
-
举例
redis-benchmark
默认配置,显示50个连接,10000次请求对应的性能
redis-benchmark -c 100 -n 5000
100个连接,5000次请求对应的性能
3、
命令monitor
(redis客户端命令)
- 指令
monitor
-
作用
打印服务器调试信息 -
举例
4、
命令slowlog
(redis客户端命令)
- 指令
showlong [operator]
设置慢查询的时间下限,单位:微秒
slowlog-log-slower-than 1000
设置慢查询命令对应的日志显示长度,单位:命令数
slowlog-max-len 100