适用场景

Redis 变慢常见两类原因：大 key 阻塞单线程，热 key 压垮单节点。两者都要先用扫描与监控定位，再决定拆分或拆分+本地缓存。改的时候要小心，别一边治理一边打挂线上。

配置步骤（热 key 识别与多级缓存）

# 1) 热 key 线索
redis-cli monitor | head -200        # 极短时间采样，生产慎用
redis-cli info commandstats | grep get
# 或使用客户端侧统计：按 key 前缀统计 QPS

# 2) 多级缓存结构
# L1 本地缓存（JVM/进程内，TTL 1-5 秒）
# L2 Redis（分片副本，读写随机选副本）
# L3 数据库（兜底，带互斥重建）

# 3) 热 key 副本化（示例思路）
# key 改为 biz:hot:item:<id>:<0..N>，读时随机选副本

# 4) 限流与降级
# 热点接口加令牌桶，超限返回缓存或降级数据

关键参数与建议

  • 大 key 标准：String > 10KB、集合元素数 > 5000 视为需要关注
  • 扫描方式：SCAN 遍历 + MEMORY USAGE，禁止线上使用 KEYS
  • 热 key 识别：监控单 key QPS，或采样客户端命令统计
  • 大 key 治理：拆分为多个小 key（按时间/分片），或用 Hash 分桶
  • 热 key 治理：本地缓存、多副本随机读、限流与降级
  • 删除方式：大 key 用 UNLINK 异步删除，避免阻塞
  • 预防机制：写入侧限制单 key 大小，代码评审加检查项

容易踩的坑

  • 热 key 只加副本不改路由，读到同一分片
  • 本地缓存 TTL 过长，数据更新后长时间不一致
  • 缓存击穿没有互斥，热点失效瞬间把数据库打挂
  • 限流阈值定太低，正常用户被限
  • 只治热点不治缓存穿透，恶意请求仍压库
  • 监控只看集群总 QPS，看不出单 key 热点

验证与巡检

# 热点治理效果
redis-cli info stats | grep -E 'instantaneous_ops|keyspace_hits|keyspace_misses'
# 命中率 = hits / (hits + misses)，目标 > 90%

# 单分片水位与网络
redis-cli -h node1 info cpu | grep used_cpu_sys
  • 巡检：命中率 > 90%、单 key QPS 有上限、热点接口有降级开关

小结

Redis 治理验收：线上无大 key、热 key 有副本或本地缓存、单节点内存与 QPS 水位可控、写入侧有约束防止复发。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。