第3章：污染根因故障树——构建从现象到根因的完整故障树

3.1 故障树的核心思想

缓存污染不会凭空发生。一个“缓存命中率突然下降”的现象背后，可能是代码中某个key拼接错误、配置里一条过期策略遗漏，也可能是架构层面缺少兜底防护。故障树（Fault Tree）的任务是：从可观测的现象出发，沿着分层路径逐级下钻，直到找到可修复的原子根因。

本章构建的故障树覆盖代码层、配置层和架构层共三层，每层都给出具体的排查入口、判断规则和修复动作。

3.2 故障树全景

3.3 逐层排查表

以下表格是对故障树各层节点的详细展开，包含现象表现、数据采集命令、判断规则和修复动作。

redis-cli --bigkeys -i 0.1
redis-cli memory usage <key>

redis-cli info keyspace
redis-cli ttl <key>

# 开启慢查询日志
redis-cli slowlog get 10

redis-cli info stats | grep evicted
redis-cli config get maxmemory

redis-cli config get maxmemory-policy

# 监控不存在key的请求
redis-cli monitor | grep -i "null"

redis-cli info keyspace
# 检查keyspace中expires字段

3.4 现象识别：从表象到故障树入口

在实际生产环境中，你最先感知到的不会是“缓存污染”这个词，而是以下3类可观测信号。每种信号直接映射到故障树的某一层入口。

3.5 数据采集：每一层的取证命令集

在进入故障树之前，必须统一采集以下三组数据。这些数据帮助你在故障树中快速判定走哪个分支。

3.5.1 全局缓存统计（3秒内完成）

# Redis 实例级统计
redis-cli info stats | grep -E 'hits|misses|evicted|expired'
redis-cli info memory | grep -E 'used_memory_human|maxmemory|fragmentation'
redis-cli info keyspace

# 逐DB扫描
for db in {0..15}; do
  redis-cli -n $db dbsize
  redis-cli -n $db info keyspace 2>/dev/null
done

3.5.2 热点key与bigkey采集

# 使用redis-cli内置分析（生产慎用，建议在备库执行）
redis-cli --hotkeys -i 0.1
redis-cli --bigkeys -i 0.1

# 手动采样热点key（使用monitor，仅低峰期使用，持续5秒）
timeout 5 redis-cli monitor | awk '{print $3}' | sort | uniq -c | sort -rn | head -20

3.5.3 慢查询与延迟取证

# 慢查询日志（确认是否有慢写导致并发异常）
redis-cli slowlog get 50

# 延迟基线测量
redis-cli --latency -h <host> -p <port> -i 1

# RDB/AOF 重写期间延迟抖动检查
redis-cli info persistence

3.6 原因定位：故障树逐层下钻判断规则

3.6.1 代码层定位（是否命中代码层？）

判断规则：如果keyspace_hits无骤降但expired_keys和evicted_keys均正常，且数据不一致告警出现，则进入代码层。

1. 检查key设计：执行--bigkeys观察是否有单个key占用超过50%的内存；执行--hotkeys观察热key是否集中在少数前缀。
2. 检查过期策略：随机采样100个key，执行ttl，统计返回-1的比例。
3. 检查并发写：在业务代码中搜索SET命令附近是否有事务/Lua包裹，或使用monitor观察同一key在短时间内是否被多次写入。

# 示例：批量检查key的ttl状态
redis-cli --scan --pattern 'prefix:*' | head -200 | while read k; do
  ttl=$(redis-cli ttl "$k")
  if [ "$ttl" -eq -1 ]; then
    echo "NO_EXPIRE: $k"
  fi
done

3.6.2 配置层定位（是否命中配置层？）

判断规则：如果evicted_keys/s > 100或used_memory/maxmemory > 90%，则进入配置层。

1. 检查内存限制：对比maxmemory与used_memory_human，确认使用率。
2. 检查淘汰策略：执行config get maxmemory-policy，确认策略是否与业务模型匹配。
3. 检查连接/超时参数：查看timeout、tcp-keepalive是否设置合理。

# 检查配置层核心参数
redis-cli config get maxmemory
redis-cli config get maxmemory-policy
redis-cli config get timeout
redis-cli config get tcp-keepalive

3.6.3 架构层定位（是否命中架构层？）

判断规则：如果keyspace_misses比例突然升高且DB负载同频飙升，则进入架构层。

1. 检查穿透：通过monitor统计返回空值的请求比例，或查看应用日志中“缓存未命中-查DB为空”的日志量。
2. 检查击穿：确认热点key在其过期时间点前后是否有DB查询尖刺。
3. 检查雪崩：检查expired_keys在时间轴上是否有集中的批量过期。

# 检查过期key的时间分布（需在Redis 7.0+使用expiry统计）
redis-cli DEBUG SDSLEN <key>  # 仅示意，实际使用info expire stats

3.7 修复动作与复测验证

每个叶子节点对应一组明确的修复动作，修复后必须通过复测才能关闭该分支。

3.8 预防：将故障树左移

故障树的真正价值不在于事后排查，而在于将树上的每一个叶子节点转换为CI门禁或监控告警，提前拦截污染。

• 代码层预防：在Code Review阶段增加“缓存key规范检查”（正则校验key格式）；在CI阶段使用Redis Mock对并发写场景进行压力测试。
• 配置层预防：将maxmemory、maxmemory-policy、timeout等参数作为基础设施配置代码（如K8s ConfigMap）纳入版本管理，变更需审批。
• 架构层预防：在灰度发布前，使用流量回放工具模拟穿透/击穿场景，验证布隆过滤器和兜底策略是否生效。