第1章 缓存污染现象识别

缓存污染（Cache Pollution）是指无效、过期或低效数据占据了缓存空间，导致热点数据被逐出、命中率骤降、系统行为紊乱的隐性故障。与硬件故障或网络分区不同，缓存污染在初期往往被误判为“负载波动”或“正常毛刺”，直到业务报表出现系统性偏差才引起重视。本章建立四维现象识别框架，帮助运维与开发人员在第一时间锁定“污染”而非其他根因。

1.1 四维现象总览

缓存污染的临床表现可归纳为四个正交维度，每个维度对应一类可量化指标与典型误判场景：

现象维度 核心指标 典型误判 污染关联度
命中率异常下降 缓存命中率 < 基线 − 15% 流量突增、缓存预热不足 ★★★★★
响应时间抖动 P99 延迟 > 3× 均值，且无规律 GC 暂停、网络重传 ★★★★☆
数据不一致 同一 key 在不同节点返回值不同 主从延迟、双写时序 ★★★★★
业务报表偏差 汇总数据与离线数仓对账不符 ETL 逻辑变更、时区漂移 ★★★☆☆
排查红线：当命中率下降与响应抖动同时出现，且无对应流量尖峰时，缓存污染概率超过 70%。此时不应盲目扩容或刷新缓存，必须先执行污染取证。

1.2 现象识别故障树

以下故障树从监控告警出发，逐层过滤噪声，最终收敛到“缓存污染”判定。每个叶子节点对应一组数据采集动作（第2章展开）。

缓存污染现象识别故障树 监控告警触发 命中率异常下降 响应时间抖动 数据不一致 业务报表偏差 命中率 < 基线 − 15% 逐出量突增 > 300% P99 延迟 > 3× 均值 延迟分布无周期模式 同 key 跨节点返回值差异 TTL 剩余时间乱序 在线汇总与离线对账不符 偏差集中在部分维度 命中率下降 + 任意一个其他现象 (抖动 / 不一致 / 报表偏差) 判定：缓存污染疑似 进入第2章：数据采集 说明： “命中率下降 + 响应抖动”组合是缓存污染的最强信号；单维度现象需排除流量、GC、网络后 方可进入污染排查流程。故障树适用于 Redis / Memcached / Local Cache 等所有缓存形态。

1.3 四维现象逐一拆解

1.3.1 缓存命中率异常下降

缓存命中率是衡量缓存效率的首要指标。污染导致的命中率下降具备三个特征：

  • 陡降而非缓降：命中率在 1–2 个监控周期内从基线 92% 跌至 50% 以下，而非随流量线性变化。
  • 逐出量（eviction）同步飙升：被逐出的 key 数量超过日常峰值的 3 倍。
  • set 操作频率异常：每秒 set 次数大幅上升，说明大量新数据正在“污染”缓存。

以下命令用于快速采集命中率与逐出数据：

# Redis  INFO 命令提取命中率与逐出量
redis-cli INFO stats | grep -E 'keyspace_hits|keyspace_misses|evicted_keys'

# 示例输出片段
keyspace_hits:1245678
keyspace_misses:987654
evicted_keys:45678

# 计算命中率（bash）
hits=$(redis-cli INFO stats | awk -F: '/keyspace_hits/{gsub(/\r/,"");print $2}')
misses=$(redis-cli INFO stats | awk -F: '/keyspace_misses/{gsub(/\r/,"");print $2}')
echo "scale=2; $hits * 100 / ($hits + $misses)" | bc
判断规则：当命中率 < 基线 − 15% 且 evicted_keys 较前日同时段增长 > 300% 时，标记为“疑似污染待查”。若同时观察到 set 操作频率 > 2× 基线，污染置信度提升至 80%。

1.3.2 响应时间抖动

污染导致的响应抖动区别于 GC 或网络抖动的关键在于无周期与key 维度的局部性。

抖动类型 特征 与污染的关系
GC 抖动 周期性出现，所有 key 延迟同步升高 无关（需先排除）
网络重传 延迟尖峰集中在 TCP 重传窗口 弱相关
污染抖动 P99 高但 P50 正常，集中在被污染 key 分片 强相关

诊断抖动根因时，优先提取慢查询日志，观察哪些 key 触发了后端回源：

# Redis SLOWLOG 获取最近 10 条慢查询
redis-cli SLOWLOG GET 10

# 输出示例
1) 1) (integer) 14           # 日志 ID
   2) (integer) 1734567890   # 时间戳
   3) (integer) 23000        # 执行耗时（微秒）
   4) 1) "GET"               # 命令
      2) "user:profile:87654321"
   5) "127.0.0.1:45876"
   ...
# 重点检查被污染 key 的 GET 操作是否密集出现在 SLOWLOG 中

1.3.3 数据不一致

缓存污染导致的不一致通常呈现为“同一 key 在不同数据节点或不同时间点返回不同值”。与主从延迟导致的最终一致性不同，污染不一致是持久且自洽的错乱。

典型验证手法：

# 对同一 key 连续多次读取，观察值是否突变
redis-cli GET product:stock:9876
# 返回 42
redis-cli GET product:stock:9876
# 返回 137  （值突变，且无对应写操作）
取证技巧：开启 Redis 的 keyspace 通知或审计日志，捕获对疑似 key 的所有写操作。若写操作来源与预期业务代码不符，则几乎可以确认缓存被污染。

1.3.4 业务报表偏差

报表偏差是缓存污染的“慢反馈”现象——在线服务使用污染数据做聚合，离线数仓则从原始库抽取，两者对账时发现系统性差异。排查时需注意：

  • 偏差维度与缓存 key 的 prefix 强相关（如 user:、order:、product:）。
  • 偏差量级与缓存 TTL 设置相关：TTL 越短，偏差自愈越快；TTL > 30 分钟，偏差可持续数小时。

1.4 现象组合排查矩阵

单一现象不足以定论，组合现象大幅提升污染置信度。以下矩阵用于现场快速分级：

组合编号 现象组合 污染概率 建议动作
C1 命中率↓ + 抖动↑ 85–95% 立即进入数据采集（第2章）
C2 命中率↓ + 数据不一致 80–90% 优先定位写污染源
C3 命中率↓ + 报表偏差 60–75% 关联分析偏差 key 集合
C4 仅命中率↓ 30–50% 排除流量与配置因素
C5 仅报表偏差 10–20% 优先检查 ETL 与数仓逻辑
重要提醒：在组合 C1 或 C2 场景下，不要执行“全缓存刷新”作为第一响应。全量刷新会瞬间打穿缓存、压垮后端数据库，且丢失污染现场的关键证据（如被污染 key 的原始值和写入来源）。正确的第一步是执行 redis-cli --bigkeys 或扫描热点 key 分布，采集污染样本。

1.5 实战案例：一次被误判为“流量突增”的缓存污染

背景：某电商平台大促期间，商品详情页缓存命中率从 94% 骤降至 41%，P99 响应时间从 12ms 飙升至 380ms。值班团队第一时间扩容缓存集群并重启缓存服务，但命中率仅恢复至 55%，且 20 分钟后再次恶化。

现象拆解：

  • 命中率下降 + 抖动（C1 组合），污染概率 > 90%。
  • 进一步检查发现 evicted_keys 较前日增长 420%，且 set 操作的 key 集中于 product:flashsale: 前缀。
  • 慢查询日志显示 product:flashsale: 相关 key 的 GET 平均耗时 210ms，远高于其他 key 的 6ms。

结论：秒杀活动将大量一次性商品 ID 写入缓存，这些 key 仅被访问 1–2 次，却挤占了热门商品 key 的空间。属于典型的“局部性污染 + 逐出风暴”。

经验教训：如果团队在现象识别阶段就启用“命中率 + 抖动”组合判定，可以避免无效扩容，直接进入 key 级别污染分析，平均修复时间可从 47 分钟缩短至 12 分钟。

1.6 现象识别阶段的输出物

完成本章四维识别后，排查人员应产出以下交付物，作为第2章数据采集的输入：

  1. 污染嫌疑 key 列表：通过 SLOWLOG 和 --bigkeys 扫描获得，至少包含 5–10 个具体 key。
  2. 时间窗口标记：命中率开始下降的精确时间点（精度到秒），用于日志关联分析。
  3. 组合置信度评级：C1–C5 中的一级，用于决定排查紧急程度。
  4. 排除清单：已确认排除的干扰因素（如 GC 暂停、网络重传、主从延迟）。

第1章核心任务：在监控告警触发后，使用四维现象 + 故障树在 5 分钟内完成“是否缓存污染”的定性判断。不跳步、不臆断、不盲目操作。

← 上一章 📖 返回目录 下一章 →