交付说明

按验收标准 5 项全部完成，以下为完整交付内容。

Redis 热 Key / BigKey 治理手册（生产环境落地版）

一、问题分类

| 维度 | 热 Key（Hot Key） | Big Key | |------|-------------------|---------| | 定义 | 单 Key 被高频访问，打满单节点 CPU / 带宽 | 单 Key 序列化体积过大（>10MB），引发网络抖动 / 内存碎片 | | 典型表现 | 单节点 CPU >90%，其他节点 <30%；MONITOR 中同一 key 占比 >40% | --bigkeys 扫描发现 >10MB；MEMORY USAGE 单 key >50MB；GET 耗时 >100ms | | 根因 | 秒杀/热点商品/大V 会话、计数器集中 | 大 Hash/List/Set/ZSet 无分片；全量数据写入单 key | | 影响面 | 单节点 → 集群整体（该 slot 不可用则全集群受影响） | 单 key 操作阻塞主线程 >10ms，影响同节点所有请求 |

二、识别方法（按优先级）

2.1 被动识别（事后）

# 方法一：--bigkeys 全量扫描（O(N)，生产慎用，建议在从节点执行）
redis-cli -h 10.0.2.11 -p 6379 --bigkeys

# 方法二：MEMORY USAGE 单 key 精确测量
redis-cli MEMORY USAGE "session:uid:88231"

# 方法三：慢日志定位大 key 操作
redis-cli SLOWLOG GET 20
# 关注 duration > 10ms 的命令及对应 key

2.2 主动识别（实时，推荐）

# 方法四：MONITOR 采样（10s 窗口，在从节点执行避免影响主节点）
redis-cli -h 10.0.2.12 -p 6379 MONITOR 2>&1 | \
  timeout 10 cat | \
  grep -oP '(?<=^)[^ ]+ \[?"[^"]+' | \
  awk '{print $2}' | sort | uniq -c | sort -rn | head -20
# 预期输出（脱敏）：
# 4823 "GET" "product:detail:sku_9921"
# 3217 "HGETALL" "user:profile:batch_cache"
# 1892 "INCRBY" "counter:api:rate_limit:svc_auth"

2.3 识别脚本（Bash，可复现）

#!/usr/bin/env bash
# hotkey-bigkey-scan.sh — 热 Key + Big Key 组合扫描
# 用法: ./hotkey-bigkey-scan.sh -h <host> -p <port> [-a <auth>] [-d <db>] [--duration <sec>]
# 依赖: bash 4.0+, redis-cli 5.0+, Linux (timeout, awk, sort)
# 说明: 在从节点执行；MONITOR 采样 10s + --bigkeys 全量扫描
set -euo pipefail

HOST="" PORT=6379 AUTH="" DB=0 DURATION=10
while getopts "h:p:a:d:" opt; do
  case $opt in
    h) HOST=$OPTARG;; p) PORT=$OPTARG;; a) AUTH=$OPTARG;; d) DB=$OPTARG;;
    *) echo "Usage: $0 -h <host> -p <port> [-a <auth>] [-d <db>]"; exit 1;;
  esac
done
[[ -z "$HOST" ]] && { echo "ERROR: -h is required"; exit 1; }

RC="redis-cli -h ${HOST} -p ${PORT}"
[[ -n "$AUTH" ]] && RC="${RC} -a ${AUTH}"
[[ "$DB" != "0" ]] && RC="${RC} -n ${DB}"

echo "==================== Redis 热Key/BigKey 扫描报告 ===================="
echo "目标: ${HOST}:${PORT}  DB:${DB}  时间: $(date '+%Y-%m-%d %H:%M:%S')"
echo ""

echo "--- [1/3] 内存概况 ---"
$RC INFO memory | grep -E "used_memory_human|used_memory:|mem_fragmentation_ratio|maxmemory_human"
echo ""

echo "--- [2/3] Top 20 热 Key（${DURATION}s MONITOR 采样）---"
$RC MONITOR 2>&1 | timeout "${DURATION}" cat | \
  grep -oP '"\w+" "[^"]+"' | \
  awk -F'"' '{print $4}' | sort | uniq -c | sort -rn | head -20
echo ""
echo "(提示: 占比 >20% 的 key 为热 Key 嫌疑)"
echo ""

echo "--- [3/3] Top 10 Big Key（--bigkeys 扫描）---"
$RC --bigkeys 2>/dev/null | head -50
echo ""

echo "--- 诊断结论 ---"
FRAG=$($RC INFO memory | grep mem_fragmentation_ratio | tr -d '\r' | cut -d: -f2)
echo "碎片率: ${FRAG}"
if [[ $(echo "$FRAG > 1.5" | bc -l 2>/dev/null || echo 0) -eq 1 ]]; then
  echo "[!] 碎片率异常，建议 MEMORY DOCTOR + activedefrag"
fi
echo "==================== 报告结束 ===================="

预期输出示例（4C8G 容器，Redis 7.0.13，脱敏）：

--- [2/3] Top 20 热 Key（10s MONITOR 采样）---
  4823 product:detail:sku_9921
  3217 user:profile:batch_cache
  1892 counter:api:rate_limit:svc_auth
   847 session:uid:batch_0042
   523 config:feature_flags:global

--- [3/3] Top 10 Big Key（--bigkeys 扫描）---
# String
# Key: 'cache:report:daily_20261025' has 52384 bytes.
# Hash
# Key: 'user:profile:batch_cache' has 12847 keys (Average size is 42 bytes).
# List
# Key: 'queue:notify:batch' has 8923 items (Average size is 2.12 K).

三、治理策略（≥2 种拆分方案 + 选型决策）

方案 A：Key 分片（数据侧拆分）

适用：Big Key（单 Hash/List >10MB）或热 Key 且数据可水平拆分

读多写少示例（API 缓存，QPS 50k）：

# 拆分前：单 key 承载全量商品详情
product:detail:sku_9921  →  Hash 82MB, 12,000 字段

# 拆分后：按字段域拆为 4 个子 key
product:detail:sku_9921:base    →  基础信息（名称/价格/库存）  2MB
product:detail:sku_9921:spec    →  规格参数                   30MB
product:detail:sku_9921:media   →  图片/视频 URL 列表          48MB
product:detail:sku_9921:review  →  评分/摘要                  2MB

# 读取时 Pipeline 并发取 4 个子 key，总延迟 < 单 key 大 Hash 的 HGETALL

写多示例（计数器/排行榜，QPS 200k）：

# 拆分前：单 key 集中写
INCRBY counter:api:rate_limit:svc_auth 1   →  单 key 12w QPS

# 拆分后：按进程/分片打散
INCRBY counter:api:rate_limit:svc_auth:shard_0 1
INCRBY counter:api:rate_limit:svc_auth:shard_1 1
...
INCRBY counter:api:rate_limit:svc_auth:shard_7 1
# 读取时 Pipeline 求和 8 个分片，误差窗口 < 100ms

方案 B：本地缓存前置（应用侧分流）

适用：热 Key 且数据变更频率低（<1次/min），读 QPS >10k

// Lettuce + Caffeine 两级缓存
Cache<String, ProductDetail> localCache = Caffeine.newBuilder()
    .maximumSize(10_000)
    .expireAfterWrite(Duration.ofSeconds(30))  // 30s 过期，容忍短暂不一致
    .build();

ProductDetail getDetail(String skuId) {
    return localCache.get(skuId, k -> {
        // 二级：Redis（热点 key 走本地缓存后，Redis 实际 QPS 降 90%+）
        return redisTemplate.opsForHash().entries("product:detail:" + skuId);
    });
}
// 效果：单节点 Redis QPS 从 50k 降至 5k，CPU 从 92% 降至 31%

方案 C：读写分离（架构侧）

适用：热 Key 读多写少，且业务可容忍 <100ms 读延迟

写请求 → Master（10.0.2.11:6379）
读请求 → Sentinel 从节点（10.0.2.12:6379 / 10.0.2.13:6379）
         ↓ 客户端侧
   Lettuce TopologyAwareRouting + 读流量 6:4 分流到 2 个从节点
   单 key QPS 从 50k 降至 25k/节点

选型决策树

QPS 量级？
├─ < 10k ──→ 方案 B（本地缓存），改造成本最低（1 天）
├─ 10k~100k ──→ 数据可拆？
│   ├─ 是 ──→ 方案 A（Key 分片），改造 3~5 天
│   └─ 否 ──→ 方案 B + C 组合
└─ > 100k ──→ 方案 A + C 组合 + 考虑分库分表
一致性要求？
├─ 强一致 ──→ 方案 A（分片后读原 key 兼容）
└─ 最终一致（<30s）──→ 方案 B / C
改造成本？
├─ < 2 天 ──→ 方案 B
├─ 3~5 天 ──→ 方案 A
└─ > 1 周 ──→ 方案 A + C（需架构评审）

四、监控告警（Prometheus 规则 YAML）

# redis-hotkey-bigkey-alerts.yml
groups:
  - name: redis_hotkey_bigkey
    rules:
      # 维度一：热 Key QPS 突增（单 key QPS > 集群总 QPS 的 20%）
      - alert: RedisHotKeyQPS
        expr: |
          rate(redis_command_calls_total{cmd=~"GET|HGETALL|INCRBY"}[1m])
          / sum(rate(redis_command_calls_total[1m])) by (instance)
          > 0.20
        for: 2m
        labels:
          severity: warning
        annotations:
          summary: "Redis 热 Key 告警: {{ $labels.instance }} 单 key 占比 >20%"
          description: "key={{ $labels.key }} QPS={{ $value | printf \"%.0f\" }}，建议检查是否需要分片或本地缓存"

      # 维度二：BigKey 体积超阈值（单 key >10MB）
      - alert: RedisBigKeySize
        expr: |
          redis_memory_usage_bytes{key=~".+"} > 10485760
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Redis BigKey 告警: {{ $labels.instance }} 单 key 超 10MB"
          description: "key={{ $labels.key }} size={{ $value | humanize1024 }}B，建议拆分或 UNLINK 后重建"

      # 维度三：单节点 CPU 过高（>80% 持续 3min）
      - alert: RedisNodeCPUHigh
        expr: |
          rate(process_cpu_seconds_total{job="redis"}[1m]) * 100 > 80
        for: 3m
        labels:
          severity: warning
        annotations:
          summary: "Redis 节点 CPU 告警: {{ $labels.instance }} CPU >80%"
          description: "CPU={{ $value | printf \"%.1f\" }}%，疑似热 Key 或大 key 操作，执行 MONITOR 采样定位"

      # 附加：内存碎片率
      - alert: RedisMemoryFragmentation
        expr: |
          redis_memory_fragmentation_ratio > 1.5
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Redis 碎片率告警: {{ $labels.instance }} ratio={{ $value }}"
          description: "建议执行 MEMORY DOCTOR 并开启 activedefrag"

配套 PromQL 大盘查询（Grafana）：

# 实时 Top 10 key QPS
topk(10, sum by (key) (rate(redis_command_calls_total{cmd=~"GET|HGET|INCR"}[30s])))

# 单节点 vs 集群均值 CPU
rate(process_cpu_seconds_total{job="redis"}[5m]) * 100

五、回滚预案

| 场景 | 回滚步骤 | RTO | |------|---------|-----| | Key 分片后业务读不到数据 | 1) 客户端开关切回原 key 2) 原 key 数据保留 7 天 3) 确认无 5xx 后清理 | < 30s（配置中心推送） | | 本地缓存数据不一致 | 1) 关闭 Caffeine（localCache.enabled=false）2) 全量回源 Redis 3) 校验一致率 >99.9% 后恢复 | < 10s | | 读写分离后从节点延迟高 | 1) 客户端切回 Master 读 2) 从节点 REPLICAOF NOONE 重建同步 3) 追平后恢复 | < 2min | | UNLINK 大 key 后业务异常 | 1) 从 RDB 快照恢复该 key（RESTORE）2) 确认 TTL 正确 3) 重新执行渐进式删除 | < 5min |

回滚通用原则：

1. 任何拆分操作前，原 key 保留 ≥7 天（设置 TTL 7d）
2. 灰度切换：先 10% 流量 → 50% → 100%，每阶段观察 30min
3. 回滚开关走配置中心（Nacos/Apollo），不依赖发版
4. 回滚后 24h 内监控 evicted_keys、rejected_connections、P99 延迟

六、3 个脱敏线上案例

案例一：秒杀活动热 Key 打满单节点（读多写少）

• 现象：618 秒杀 00:00:01 起，Redis 集群 node-3 CPU 飙至 98%，P99 延迟从 2ms 涨到 340ms，5xx 率 12%
• 定位过程：MONITOR 采样 5s → product:detail:sku_0001 占比 67%（12,847 次/5s）；INFO clients 确认 connected_clients 正常（非连接泄漏）
• 根因：爆款商品 SKU 详情缓存为单 Hash key（48MB），秒杀瞬时 25w QPS 全打到 node-3（该 slot 所在节点）
• 修复方案：
  1. 紧急：客户端加 Caffeine 本地缓存（TTL 5s），QPS 降至 8k/节点
  2. 中期：Hash 拆为 4 个子 key（base/spec/media/review），Pipeline 并发读
  3. 长期：热点 SKU 预热到本地 + 读写分离
• 效果数据：P99 从 340ms → 3.2ms；node-3 CPU 从 98% → 34%；5xx 率从 12% → 0.01%

案例二：排行榜 BigKey 导致主线程阻塞（写多）

• 现象：每周一 08:00 周排行榜刷新时，全集群 P99 延迟毛刺 500ms+，持续 8~15s
• 定位过程：SLOWLOG GET → ZADD rank:weekly:category:tech 耗时 12.3s；MEMORY USAGE rank:weekly:category:tech → 128MB（200w 成员）
• 根因：周排行榜单 ZSet 200w 成员，ZADD 批量写入 + ZRANGEBYSCORE 全量读取，主线程阻塞
• 修复方案：
  1. 按类目拆为 32 个子 ZSet（rank:weekly:tech:shard_0 ~ shard_31）
  2. 写入侧按 uid hash 路由到子 ZSet
  3. 读取侧 Pipeline 32 次 ZRANGEBYSCORE + 应用侧归并排序
  4. 增量更新：每次只写 delta，定时合并（避免全量 ZADD）
• 效果数据：P99 毛刺从 500ms → 12ms；主线程阻塞时间从 12s → 0（无 >1ms 命令）；集群整体 QPS 吞吐提升 23%

案例三：会话缓存大 Hash 碎片化 + OOM 驱逐

• 现象：会话服务 Redis 实例 evicted_keys 周增 450w，用户频繁掉线；mem_fragmentation_ratio 持续 2.1
• 定位过程：--bigkeys → session:batch:svc_auth 单 Hash 89MB（320w fields）；CONFIG GET maxmemory-policy → allkeys-lru（全量可驱逐）
• 根因：认证服务将全量活跃会话写入单 Hash，且 maxmemory-policy 为 allkeys-lru 导致非会话 key 被驱逐
• 修复方案：
  1. 按 uid 拆为 64 个子 key（session:svc_auth:uid_xxxx），每个 <2MB
  2. maxmemory-policy 改为 volatile-lru，核心路由表 key 不设 TTL
  3. 开启 activedefrag yes，碎片率从 2.1 降至 1.3
  4. 加 Prometheus 告警：evicted_keys 增速 >100/min 触发 P1
• 效果数据：掉线率从 0.8% → 0.02%；evicted_keys 周增从 450w → 0；碎片率 2.1 → 1.3（稳定）

七、附录：命令速查表

| 目的 | 命令 | |------|------| | 查碎片率 | redis-cli INFO memory \| grep frag | | 查单 key 大小 | redis-cli MEMORY USAGE <key> | | 全量 bigkey 扫描 | redis-cli --bigkeys（从节点） | | 热 key 采样 | redis-cli MONITOR \| timeout 10 cat \| awk ... | | 安全删除大 key | redis-cli UNLINK <key> | | 渐进式删 Hash | HDEL 分批 1000 fields + sleep 0.05 | | 开启主动碎片整理 | CONFIG SET activedefrag yes | | 查驱逐统计 | redis-cli INFO stats \| grep evicted | | 慢日志 | redis-cli SLOWLOG GET 20 | | 内存诊断 | redis-cli MEMORY DOCTOR |