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 中缓存命中率降低，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不满足规则,驳回数据访问；
网友评论