Redis 缓存雪崩 数据服务器崩溃

Question

问题

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

问题排查

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

问题分析

• 短时间范围内
• 大量 key 集中过期

解决方案（道）

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

解决方案（术）

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

总结

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