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

Summary

Severity reasoning: 用户可见的页面加载失败（503）和极高延迟（15s），影响核心商品详情页，黑五期间直接导致收入损失，属于 SEV1。

deepseek-chat·prompt v1·output: zh·10874ms·1835↑ / 1581↓ tok·$0.00223

Root cause hypotheses

• high缓存键统一在 09:00 UTC 过期，黑五流量 12 倍叠加，导致缓存雪崩

  Evidence: Redis cache miss rate 从 2% 飙升至 95%，且所有 miss 键匹配 'catalog:item:*'，与预热的 TTL=7h 吻合（02:00+7h=09:00）。

• highDB 连接池耗尽，查询排队导致锁等待和 CPU 100%

  Evidence: 日志显示 09:00:02 UTC 连接池达到上限，查询开始排队；Postgres CPU 100% 且 lock waits 上升。

• medium黑五营销邮件导致突发流量超出系统容量

  Evidence: 流量为正常 12 倍，且发生在缓存失效的同一时刻，系统未做限流或降级。

Investigation checklist

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

   redis-cli --scan --pattern 'catalog:item:*' | head -20 | xargs -L1 redis-cli ttl

   Copy

   Expected: 大部分键 TTL 为 0 或负数（已过期），少量键可能还有剩余 TTL

2. 检查 DB 当前活跃连接数和等待事件

   SELECT count(*) FROM pg_stat_activity WHERE state = 'active'; SELECT * FROM pg_stat_activity WHERE wait_event IS NOT NULL LIMIT 10;

   Copy

   Expected: 活跃连接数接近池上限，大量查询处于 'wait_event' 状态（如 'LWLock' 或 'ClientRead'）

3. 检查 DB 中耗时最长的查询

   SELECT pid, now() - pg_stat_activity.query_start AS duration, query, state FROM pg_stat_activity WHERE state != 'idle' ORDER BY duration DESC LIMIT 5;

   Copy

   Expected: 大量查询为 'SELECT * FROM items WHERE id = ...' 且 duration 超过 10 秒

4. 确认 Redis 缓存命中率指标

   kubectl exec -n production deploy/redis-metrics -- redis-cli info stats | grep keyspace_misses

   Copy

   Expected: keyspace_misses 远高于 keyspace_hits，miss 率约 95%

Mitigation plan

• 立即在 Redis 中手动预热热门商品缓存，使用批量查询并设置随机 TTL（如 5-8 小时）

  Risk: 手动预热会额外增加 DB 负载，可能短暂加剧问题。需先限流或降级部分流量。

  Rollback: 停止预热脚本，等待缓存自然过期或回滚代码变更

• 在 catalog-svc 中启用限流：对 /items/{id} 接口按用户或 IP 限流，拒绝超出部分的请求返回 429

  Risk: 部分用户会收到 429，但优于 503。需确保限流不误伤正常用户。

  Rollback: 移除限流配置，恢复原始流量处理

• 临时增加 DB 连接池大小（如从 50 增至 100）并重启 catalog-svc 以应用新配置

  Risk: 增加连接数可能加剧 DB CPU 争用，需监控。

  Rollback: 恢复原连接池大小并重启服务

Customer impact

黑五期间用户访问商品详情页时，约 8% 请求返回 503 错误，其余请求延迟高达 15 秒，严重影响购物体验和转化率。预计在缓存预热和限流生效后逐步恢复。

Postmortem draft

Follow-ups

• P0为缓存键添加随机 TTL（如基础 TTL 7h ± 1h），避免同时过期— service owner
• P0在 catalog-svc 中实现缓存雪崩防护：使用互斥锁或分布式锁，防止并发 DB 查询— service owner
• P1为关键接口添加限流和降级策略，黑五期间启用— platform team
• P1增加缓存命中率告警，当 miss 率超过阈值时自动触发— on-call SRE
• P2黑五前进行全链路压测，模拟缓存失效场景— service owner