Redis实际运用中遇到的问题及解决方案

• 缓存预热
• * 现象：宕机
  • * 问题排查
    • 解决方案
• 缓存雪崩
• * 现象：数据库服务器崩溃
  • * 问题排查
    • 解决方案（理论）
    • 解决方案（实施）
• 缓存击穿
• * 现象：数据库服务器崩溃
  • * 问题排查
    • 解决方案
• 缓存穿透
• * 现象：数据库服务器崩溃
  • 问题排查
  • 问题分析
  • 解决方案
• 性能指标监控
• * 监控指标
  • * 性能指标：Performance
    • 内存指标：Memory
    • 基本活动指标：Basic activity
    • 持久性指标：Persistence
    • 错误指标：Error
  • 监控方式
  • * 工具
    • 命令

缓存预热

就是系统启动前，提前将相关的缓存数据直接加载到缓存系统中。避免用户请求的时候，先查询数据库，然后再查数据缓存的问题。让用户直接查询事先被预热的缓存数据。

现象：宕机

不进行缓存预热可能带来宕机的问题

问题排查

• 请求数量比较大
• 主从之间数据吞吐量较大，数据同步操作频度较高

解决方案

• 统计数据访问记录，统计访问频度较高的热点数据
• 利用LRU数据删除策略，构建数据留存队列（例如使用storm和kafka）
• 将统计结果中的数据分类，根据级别，redis优先加载级别较高的热点数据
• 利用分布式多服务器同时进行数据读取，提速数据加载过程
• 使用脚本程序固定触发数据预热过程
• 如果条件允许，使用CDN，效果会更好

缓存雪崩

就是瞬间过期数据量太大，导致对数据库服务器造成压力。如果能够有效避免过期时间集中，可以有效解决雪崩现象的出现，配合其他策略一起使用，并监控服务器的运行数据，根据运行记录快速调整。

现象：数据库服务器崩溃

• 系统平稳运行过程中，忽然数据库连接量激增
• 应用服务器无法及时处理请求
• 大量408、500错误页面的出现
• 客户反复刷新页面获取数据
• 数据库崩溃
• 应用服务器崩溃
• 重启应用服务器无效
• redis服务器崩溃
• redis集群崩溃
• 重启数据库后再次被瞬间流量放倒

问题排查

• 在一个较短的时间内，缓存中较多的key集中过期
• 此周期内请求访问过期的数据，redis未命中，redis向数据库获取数据
• 数据库同时接到大量的请求无法及时处理
• redis大量请求被积压，开始出现超时现象
• 数据库流量激增，数据库崩溃
• 重启后仍然面对缓存中无数据可用
• redis服务器资源被严重占用，redis服务器崩溃
• redis集群崩溃
• 应用服务器无法及时得到数据响应请求，来自客户端的请求数量越来越来多，应用服务器崩溃
• 应用服务器、redis、数据库全部重启，但效果不理想

解决方案（理论）

• 更多的页面静态化处理
• 构建多级缓存架构（nginx+redis+ehcache）
• 检测mysql严重耗时的业务并进行优化
• 灾难预警机制
  • 监控redis服务器性能指标
    • CPU占用及使用率
    • 内存容量
    • 查询平均响应时间
    • 线程数
• 限流、降级
  • 短时间范围内牺牲一些客户体验，限制一部分请求访问，降低应用服务器压力，待业务低速运转后再逐步开放访问

解决方案（实施）

• LRU和LFU切换（删除策略）
• 数据有效期策略调整
  • 根据业务有效期进行分类错峰，A类90min，B类80min
  • 过期时间使用固定时间+随机值的形式，稀释集中到期key的数量
• 超热数据使用永久key
• 定期维护（自动+人工）
  • 对即将过期数据做访问量分析，确认是否延时，配合访问量统计，做热点数据的延时
• 加锁
  • 慎用

缓存击穿

就是单个高热数据过期的瞬间，数据访问量巨大，redis未命中后，发起了大量对同一数据的数据库访问，导致对数据库服务器造成压力。应对策略应该在业务数据分析与预防方面进行，配合运行监控测试与即时调整策略，毕竟单个key的过期时间监控难度较高，配合雪崩处理策略即可。

现象：数据库服务器崩溃

• 系统平稳运行过程中
• 数据库连接量瞬间激增
• redis服务器无大量key过期
• redis内存平稳，无波动
• redis服务器cpu正常
• 数据库崩溃

问题排查

• redis某个key过期，客户端对该key的访问量巨大
• 多个数据请求从服务器直接压到redis后，均未命中
• redis在短时间内发起了大量对数据库中同一数据的访问

解决方案

• 预先设定
  • 以电商为例，每个商家根据店铺等级，指定若干款主打商品，在购物节期间，加大此类信息key的过期时间
• 现场调整
  • 监控访问量，对自然流量激增的数据，延长过期时间或设置永久性key
• 后台刷新数据
  • 启动定时任务，高峰期来临之前，刷新数据有效期，确保不丢失
• 二级缓存
  • 设置不同的失效时间，保障不会被同时淘汰就行
• 加锁
  • 分布式锁，防止被击穿。要注意性能瓶颈，慎用

缓存穿透

就是访问了不存在的数据，跳过了合法数据的redis数据缓存阶段，每次都访问数据库，导致对数据库服务器造成压力。通常此类数据的出现量是一个较低的值，当出现此类情况，以毒攻毒，并及时报警。应对策略应该在临时预案防范方面多做文章。

现象：数据库服务器崩溃

• 系统平稳运行过程中
• 应用服务器流量随时间增量较大
• redis服务器命中率随时间逐步降低
• redis内存平稳，无压力
• redis服务器cpu占用激增
• 数据库服务器压力激增
• 数据库崩溃

问题排查

• redis中大面积出现未命中
• 出现非正常URL访问（多见黑客攻击）

问题分析

• 获取的数据再数据库中也不存在，数据库查询未得到对应数据
• redis获取到null数据未进行持久化，直接返回
• 下次此类数据到达的时候，重复上述过程
• 出现黑客工具服务器

解决方案

• 缓存null
  • 对查询结果为null的数据进行缓存（长期使用，定期清理），设定短时限，例如30-50s，最高5min
• 白名单策略
  • 提前预热各种分类数据id对应的bitmaps，id作为bitmaps的offset，相当于设置了数据白名单。当加载正常数据时，放行。加载异常数据时直接拦截（效率比较低）
  • 使用布隆过滤器（有关布隆过滤器的命中问题当前状况可忽略）
• 实施监控
  • 实时监控redis命中率（业务正常范围时，通常会有一个波动值）与null数据的占比
    • 非活动时段波动：通常检测3-5倍，超过5倍纳入重点排查对象
    • 活动时段波动：通常检测10-50倍，超过50倍纳入重点排查对象
  • 根据倍数不同，启动不同的排查流程。然后使用黑名单进行防控
• key加密
  • 问题出现后，临时启动防灾业务key，对key进行业务层传输加密服务，设定校验程序，过来的key校验，校验不通过的，则驳回数据访问
• 无论白名单还是黑名单，都是对整体系统的压力，警报解除后尽快移除

性能指标监控

监控指标

性能指标：Performance

内存指标：Memory

基本活动指标：Basic activity

持久性指标：Persistence

错误指标：Error

监控方式

工具

命令

• benchmark
  redis-benchmark -h -p -c -n -k
  参数介绍：
  
• redis cli
  monitor -- 打印服务器调试信息
slowlog get/len/reset
  - get 获取慢查询日志
  - len 获取慢查询日志条目数
  - reset 重置慢查询日志
  slowlog-log-slower-than 1000 -- 设置慢查询的时间下线，单位：微秒
slowlog-max-len 100 -- 设置慢查询命令对应的日志显示长度，单位：命令数