[Eval][v2][zh] Cache stampede after Redis key expiry on Black Friday morning

Summary

Severity reasoning: 用户面故障：p99 延迟 15s（基线 80ms），503 错误率 8% 超过 1% 阈值且持续超过 5 分钟，收入路径（商品详情页）中断，符合 SEV1 定义。

deepseek-chat·prompt v2·output: zh·15125ms·2216↑ / 2039↓ tok·$0.00284

Root cause hypotheses

• high缓存 TTL 统一设置为 7 小时，导致所有缓存键在 09:00 同时过期，引发缓存雪崩

  Evidence: Redis 缓存命中率从 2% 骤降至 95% 未命中，且最后缓存命中日志在 08:59:58，与 TTL 过期时间吻合

• high黑五流量 12 倍于正常，数据库连接池耗尽导致查询排队和超时

  Evidence: 09:00:02 数据库连接池达到上限，查询开始排队，DB CPU 100% 持续

• medium数据库锁竞争加剧，慢查询阻塞其他查询

  Evidence: Postgres 锁等待指标上升，但未提供具体慢查询日志，需进一步验证

• medium应用层未实现缓存击穿保护（如互斥锁或提前刷新）

  Evidence: 每个缓存未命中都直接触发数据库查询，无任何保护机制

• lowRedis 实例性能瓶颈导致缓存读取延迟

  Evidence: Redis CPU 仅 25%，但缓存未命中率高，排除此假设

Investigation checklist

1. 确认缓存雪崩范围：检查 Redis 中 catalog:item:* 键的 TTL 分布

   redis-cli -h <redis-host> -p 6379 SCAN 0 MATCH 'catalog:item:*' COUNT 1000 | xargs -I {} redis-cli -h <redis-host> -p 6379 TTL {} | sort | uniq -c

   Copy

   Expected: 大量键 TTL 为 0 或接近 0，确认同时过期

2. 检查数据库当前活跃查询和等待事件

   SELECT pid, query_start, state, wait_event_type, wait_event, query FROM pg_stat_activity WHERE state != 'idle' ORDER BY query_start LIMIT 20;

   Copy

   Expected: 大量查询处于 'active' 状态，wait_event 可能为 'LWLock' 或 'ClientRead'

3. 检查数据库连接池使用率

   SELECT count(*) AS used_connections, setting AS max_connections FROM pg_stat_activity, pg_settings WHERE name = 'max_connections' GROUP BY setting;

   Copy

   Expected: used_connections 接近 max_connections，确认连接池耗尽

4. 检查应用日志中缓存未命中的频率

   kubectl logs -n prod -l app=catalog-svc --since=15m | grep -c 'cache miss'

   Copy

   Expected: 日志行数远高于正常值（正常每分钟 < 100，当前可能 > 10000）

5. 检查 Redis 内存使用和逐出策略

   redis-cli -h <redis-host> -p 6379 INFO memory | grep -E 'used_memory_human|maxmemory_human|evicted_keys'

   Copy

   Expected: 内存使用未达上限，逐出键数为 0，排除内存压力

Mitigation plan

• 立即启用缓存击穿保护：在应用层对缓存未命中加互斥锁，只允许一个请求回源数据库，其余等待缓存填充

  Risk: 锁等待可能导致请求超时，但比直接压垮数据库安全；需确保锁超时机制

  Rollback: 回滚代码变更或通过配置开关禁用互斥锁

• 手动预热缓存：从数据库导出热门商品数据，批量写入 Redis，设置随机 TTL（如 6-8 小时）

  Risk: 预热脚本可能进一步增加数据库负载，需在低峰期执行或限制并发

  Rollback: 停止预热脚本，清除已写入的缓存键

• 对 catalog-svc 实施限流：在入口处拒绝部分请求，保护数据库不被完全压垮

  Risk: 用户会看到更多 503 错误，但可防止系统完全崩溃

  Rollback: 移除限流规则或提高限流阈值

• 扩展数据库读副本：临时增加只读副本分担查询负载

  Risk: 副本同步延迟可能导致数据不一致，且扩容需要时间

  Rollback: 缩容副本

Customer impact

黑五期间，用户访问商品详情页时遇到高延迟（15 秒）或间歇性 503 错误，影响所有通过 catalog-svc 获取商品信息的用户。预计受影响用户数占当日活跃用户的 80% 以上。

Postmortem draft

Follow-ups

• P0为缓存 TTL 添加随机偏移，避免同时过期— catalog-svc 服务负责人
• P0实现缓存击穿保护机制（互斥锁或提前刷新）— catalog-svc 服务负责人
• P0黑五前进行全链路负载测试，验证缓存策略和数据库容量— SRE 团队
• P1增加数据库连接池使用率和锁等待的告警— 平台团队
• P1评估数据库只读副本的扩容自动化— 平台团队
• P1制定黑五流量预案，包括限流和降级策略— SRE 团队