Redis系列笔记第四篇----Redis企业级解决方案

Redis企业级解决方案

1. 缓存预热

服务器启动后迅速宕机。

1.1 问题排查

1. 请求数量较高。
2. 主从之间数据吞吐量较大，数据同步操作频率较高。

1.2 解决方案

前期工作：

1. 日常统计数据访问记录，统计热点数据。
2. 利用LRU数据删除策略，构建数据留存队列。

准备工作：

3. 将统计的结果，根据级别，Redis优先加载级别较高的热点数据。
4. 利用分布式多服务器同时进行数据读取，提高数据加载速度。

实施：

5. 使用脚本固定触发数据预热过程。
6. 如果条件允许，使用CDN。

1.3 总结

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

2. 缓存雪崩

2.1 问题排查

1. 在一个较短的时间内，缓存中较多的key集中过期。
2. 在此期间访问过期的数据，Redis未命中，Redis向数据库请求数据。
3. 数据库无法处理大量的请求。
4. Redis请求被积压，Redis超时。
5. 数据库流量过大，崩溃。
6. 重启数据库后缓存中依然没数据。
7. Redis服务器资源被占用，崩溃。
8. Redis集群瓦解。
9. 应用服务器无法得到数据，客户端请求越来越多，应用服务器崩溃。
10. 全部服务器重启，效果依然不理想。

2.2 解决方案1

平时的设计

1. 更多的页面静态化处理。
2. 构建多级缓存。
   • NGINX
   • Redis
   • ehcache
3. 优化MySQL耗时的业务。
   • 容易超时的查询
   • 耗时较高的事务
4. 灾难预警机制。
   • 监控Redis服务器性能指标
   • CPU
   • 内存
   • 平均响应时间
   • Redis线程数
5. 限流、降级。
   短时间牺牲一些客户体验，限制一部分请求访问，降低应用服务器压力。

2.3 解决方案2

问题真来到时的解决方案

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

2.4 总结

缓存雪崩就是瞬间过期数据量太大，导致对数据库服务器造成压力。如果能够有效避免过期时间集中，可以有效地解决雪崩现象。

3. 缓存击穿

3.1 问题描述

1. 系统平稳运行
2. 数据库连接量激增
3. Redis无大量key过期
4. Redis内存平稳
5. Redis CPU正常
6. 数据库崩溃

3.2 问题排查

1. Redis中某个访问量巨大的key过期。
2. 多个数据请求从服务器请求Redis均未命中。
3. Redis短时间内发起了对数据库中同一数据的大量访问。

3.3 分析

• 单个可以高热。
• key过期。

3.4 解决方案

1. 预先设定
   • 以电商为例，指定主打商品，增加这类信息的过期时间。
2. 现场调整
   • 监控访问量，对流量激增的数据增加过期时间，或者设置为永久key。
3. 后台刷新数据
   • 启动定时数据，高峰期来之前，刷新数据有效期。
4. 二级缓存
   • 设置不同的失效时间，保证不会被同时淘汰。
5. 加锁
   • 慎用，分布式锁，防止被击穿。

3.5 总结

单个高热数据过期。

4. 缓存穿透

4.1 现象

1. 系统平稳运行
2. 应用服务器流量逐渐增加。
3. Redis命中率逐渐降低。
4. Redis内存平稳。
5. RedisCPU占用激增。
6. 数据库压力激增。
7. 数据库崩溃。

4.2 问题排查

1. Redis大面积未命中。
2. 出现非正常URL访问。

4.3 分析

1. Redis想获取的数据在数据库中不存在。
2. Redis获取到null数据后未存储，直接返回。
3. 重复这个过程。
4. 黑客可能在攻击服务器。

4.4 解决方案

1. 缓存不存在的数据

   • 对查询结果为null的数据进行缓存，设定短时限。

2. 白名单

   • 提前预热各种数据id对应的bitmaps，id作为bitmaps的offset，加载正常数据时放行，异常数据拦截。（效率偏低）
   • 使用布隆过滤器。（不能100%过滤）

3. 实施监控

   实时监控Redis命中率和null数据的占比。
   - 非活动时段，如果命中率降低了超过5倍，纳入重点排查对象。（从98%到90%）
   - 活动时段， 超过50倍重点排查。
   然后使用黑名单防控。

4. key加密

   • 校验访问的key，如果不满足规则，驳回访问请求。

4.5 总结

缓存击穿，是访问了一个数据库里面就不存在的数据。

不管是黑名单还是白名单，警报解除后都咬移除，以免增加系统压力。

5. 性能监控指标

性能指标：Performance

• latency Redis

  响应一个请求的时间
  s

• instantaneous_ops_per_sec

  平均每秒处理请求总数

• hit rate

  缓存命中率（计算出来的）

内存指标：Memory

• used_memory

  已使用内存

• mem_fragmentation_ratio

  内存碎片率

• evicted_keys

  由于最大内存限制被移除的key数量

• blocked_clients

  由于BLPOP、BRPOP、BRPOPLPUSH而被阻塞的客户端

基本活动指标：Basic activity

• connected_clients

  客户端连接数

• connected_slaves

  slave数量

• master_last_io_seconds_ago

  最近一次主从交互之后的秒数

• keyspace

  数据库中key的总数

持久化指标：Persistence

• rdb_last_save_time

  最后一次持久化到磁盘的时间戳

• rdb_changes_sinnce_last_save

  最后一次持久化以来数据库的更改数

错误指标：Error

• rejected_connections

  由于到达maxclient限制而被拒绝的连接数

• keyspace_misses

  key未命中的次数

• master_link_down_since_seconds

  主从断开的持续时间

6. 性能监控工具

命令:

性能测试： shell执行。

redis-benchmark [-h 主机] [-p 端口] [-c 连接数] [-n 请求数]

打印服务器调试信息： 需要在cli里执行。

monitor

慢日志： 需要在cli里执行。

slowlog [operator]

- get: 获取慢查询日志
- len: 获取慢查询日志条目数
- reset: 重置慢查询日志

相关配置：

• slowlog-log-slower-than 1000 设置慢查询时间的时间下限，单位微秒。
• slowlog-max-len 100 设置慢查询命令对应的日志长度。