Redis-企业级解决方案

一、缓存预热：

现象：“停机” 服务器启动后迅速停机

问题排查 1.要求数量较高 2.主从数据吞吐量大，数据同步操作频率高

解决方案 准备工作： 1.日常统计数据访问记录，统计热点数据访问频率高 2.利用LRU数据删除策略构建数据保留队列 例如，storm与kafka合作 准备工作： 1.根据等级对统计结果中的数据进行分类，redis优先加载等级较高的热点数据 2.同时使用分布式多服务器读取数据，加速数据加载过程 3.热点数据主同时预热 实施： 1.用脚本程序固定触发数据预热过程 2.如果条件允许，使用CDN(内容分发网络)效果会更好

综上所述，缓存预热是指在系统启动前直接将相关缓存数据加载到缓存系统中。避免在用户要求时查询数据库，然后缓存数据，用户直接查询预热的缓存数据。

二、缓存雪崩：

数据库服务器崩溃(1) 1.在系统平稳运行过程中，数据库连接量突然激增 2.应用服务器不能及时处理请求 3.大量408，出现了500错误页面 4.客户反复刷新页面获取数据 5.数据库崩溃 6.应用服务器崩溃 7.重启应用服务器无效 8.Redis服务器崩溃 9.Redis集群崩溃 10.重启数据库后，再次被瞬时流量放下

问题排查 1.缓存中较多的key在短时间内集中过期 2.在此周期内要求访问过期数据，redis未命中，redis从数据库获取数据 3.数据库同时收到大量请求，无法及时处理 4.Redis的大量请求被积压，并开始出现超时现象 5.数据库流量激增，数据库崩溃 6.重启后仍面临缓存无数据的可用性 7.Redis服务器资源被严重占用，Redis服务器崩溃 8.Redis集群崩溃，集群瓦解 9.应用服务器无法及时获得数据响应请求，客户端的请求越来越多，应用服务器崩溃 10.应用服务器，redis，数据库全部重启，效果不理想

问题分析 在短时间内 大量key集中过期

解决方法(道)

1、更多的页面静态处理

2、构建多级缓存架构，Nginx缓存+redis缓存+ehcahe缓存

3、优化检测Mysql的严重耗时业务，调查数据库瓶颈：如超时查询、耗时高事务等

4、灾害预警机制

监控redis服务器性能指标：

CPU占用，CPU利用率：

内存容量：

查询平均响应时间：

线程数：

5、在客户端方面，采用限流降级

牺牲部分客户体验，限制部分请求访问，降低应用服务器压力，然后在业务低速运行后逐步释放访问。

解决方案(术)

1、LRU和LFU之间的切换

2、调整数据有效期策略

根据业务数据的有效期对错峰进行分类 ，A类90分钟，B类80分钟，C类70分钟

过期时间以固定时间+随机值的形式稀释到期key的数量

3、使用永久key超热数据

4、定期维护(自动+人工)

对即将到期的数据进行访问分析，确认是否延迟，配合访问统计，对热点数据进行延迟

5、加锁

慎用

结论：缓存雪崩是指瞬时过期的key数据量过大（大量key失效），导致redis未命中，对数据库服务器造成压力。如果能有效避免过期时间的集中，就能有效解决雪崩现象（约40%）的出现，并与其他策略一起使用，监控服务器的运行数据，并根据运行记录快速调整。

三、缓存击穿

数据库服务器崩溃(2) 1.系统运行平稳 2.数据库连接量瞬间激增 3.没有大量key过期的Redis服务器 4.Redis内存稳定，无波动 5.Redis服务器CPU正常 6.数据库崩溃

问题排查 1.Redis中的一个key过期了，这个key的访问量巨大 2.多个数据请求直接从服务器压到Redis后都没有命中 3.Redis在短时间内对数据库中的同一数据发起了大量访问

问题分析

单key高热数据

如果key过期了，比如微博上的某个数据比较流行，这个就会出现

解决方法(术)

1、预先设定

以电子商务为例。每个商家根据店铺等级指定几种主要商品。在购物节期间，增加此类信息key的过期时间

注：购物节不仅指当天，而且在接下来的几天内，访问峰值呈逐渐下降的趋势

2、现场调整

监控访问量延长过期时间或将自然流量激增的数据设置为永久key

3、后台刷新数据

启动定时任务，在高峰期到来之前刷新数据有效期，确保不丢失

4、二级缓存

设置不同的故障时间，确保不会同时被淘汰

5、加锁

分布式锁，防止被击穿，但也要注意性能瓶颈，谨慎使用！

总结：

缓存击穿是单个热数据过期 在此时此刻，数据访问量很大。在击中redis之前，发起了大量的数据库访问，对数据库服务器造成了压力。应对策略应在业务数据分析和预防中进行，并配合运行监控测试和及时调整策略。毕竟，单个key的过期监控很困难，可以配合雪崩处理策略。

四、缓存穿透：

数据库服务器崩溃(3) 1.系统运行平稳 2.应用服务器流量随时间增加 3.随着时间的推移，Redis服务器的命中率逐渐降低 4.Redis内存稳定，内存无压力 5.Redis服务器CPU占用激增 6.数据库服务器压力激增 7.数据库崩溃

问题排查

1、Redis中的大面积未命中

2、url访问异常。

问题分析：

数据库中没有获得的数据，数据库查询也没有获得相应的数据

Redis没有持久地获取null数据，直接返回

下次此类数据将重复上述过程

黑客攻击服务器出现

解决方案(术)

1、缓存null

缓存查询结果为null的数据(长期使用和定期清理)，设定短时间限制，如30-60秒，最高5分钟

2、白名单策略

提前预热各种分类数据id对应的bitmaps，id作为bitmaps的offset，相当于设置数据白名单。当加载数据正常时，放行，加载异常数据时直接拦截(效率低)，相当于添加过滤器

使用布隆过滤器，

3、实施监控

与nulll数据对比实时监控redis命中率(业务正常时，通常会有波动值)

非活动时间波动：通常检测3-5倍，超过5倍纳入关键调查对象

活动时间波动:重点排场对象通常检测10-50倍，超过50倍

根据不同的倍数，启动不同的调查流程，然后使用黑名单进行防控（操作）

4、key加密

问题出现后，暂时启动防灾业务key，在业务层传输key加密服务，设置验证程序，key验证，如每天随机分配60个加密串，选择2到3个，混淆页面数据ID，发现访问key不符合规则，拒绝数据访问。

总结

缓存穿透访问不存在的数据，跳过合法数据的redis数据缓存阶段。每次访问数据库，都会对数据库服务器造成压力。通常，这些数据的数量是一个较低的值。当这种情况发生时，黑名单和白名单都是对整个系统的压力。

监控性能指标

性能指标：Performance

内存指标：Memory

基本活动指标：Basic activity

持久指标：Persistence

错误指标：Error

工具 Cloud Insight Redis Prometheus Redis-stat Redis-faina RedisLive zabbix 命令 benchmark redis cli monitor showlog

benchmark redis-benchmark [-h ] [-p ] [-c ] [-n <requests]> [-k ] 命令 范例1

redis-benchmark

说明:50个连接，1万次请求相应的性能

范例2

redis-benchmark -c 100 -n 5000

说明:100个连接，5000个请求相应的性能

benchmark

monitor

命令

monitor

打印服务器调试信息

showlog showlog [operator] 命令 get ：获取慢查询日志 len ：获取慢查询日志的数量 reset ：重置慢查询日志 相关配置 slowlog-log-slower-than 1000 #设置慢查询时间下线，单位:微秒

slowlog-max-len 100 #设置慢查询命令对应的日志显示长度，单位：命令数