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

service: catalog-svccreated: 6/3/2026, 12:09:10 AM

Raw incident context

Time: 09:00 UTC, Black Friday. catalog-svc latency exploded at exactly 09:00:00 UTC.

Symptoms:
- catalog-svc p99: 15s (baseline 80ms)
- 503 rate: 8% (intermittent during DB overload)
- Postgres CPU: 100% sustained, lock waits climbing
- Redis CPU: 25% (looks healthy)
- Redis cache miss rate for keys matching "catalog:item:*": 95% (baseline 2%)
- All product detail page requests are flooding through to DB

Background:
- We pre-warm the homepage catalog cache every night at 02:00 UTC with TTL=7h
- 02:00 UTC + 7h = 09:00 UTC ← all keys expired simultaneously
- Black Friday traffic ramp: 12x normal at 09:00 UTC (marketing email blast)
- No per-key locking; every cache miss triggers a fresh DB query

Logs:
- 08:59:58 UTC — last cache hit logged
- 09:00:00 UTC — first wave of "cache miss + DB query" log lines
- 09:00:02 UTC — DB connection pool hits ceiling, queries start queueing

On-call:
- 09:02 — pager (multiple alerts: DBHighCPU, CatalogSvcLatencyHigh, CheckoutErrorRate)
- 09:03 — diagnosis: cache stampede confirmed by Redis miss-rate metric
- 09:05 — debating: extend TTL (won't help in flight), warm cache manually (DB is the bottleneck), or shed load

Summary

SEV1

09:00 UTC 黑五流量高峰期间，catalog-svc 因缓存雪崩导致数据库 CPU 100%，p99 延迟飙升至 15s，出现间歇性 503 错误。所有商品详情页请求绕过缓存直接查询数据库，连接池耗尽。

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

deepseek-chat·prompt v2·output: zh·11425ms·2216↑ / 1509↓ tok·$0.00226

Root cause hypotheses

high缓存 TTL 统一为 7 小时，所有键在 09:00 UTC 同时过期，导致缓存雪崩
Evidence: Redis 缓存命中率从 2% 骤降至 95% 未命中，日志显示 08:59:58 最后命中，09:00:00 开始大量缓存未命中查询。
medium黑五流量 12 倍于正常，数据库连接池配置不足
Evidence: 09:00:02 连接池达到上限，查询开始排队，DB CPU 100%。
low数据库查询未优化，缺少索引导致全表扫描
Evidence: 当前无直接证据，但高并发下慢查询可能加剧问题。

Investigation checklist

确认缓存雪崩：检查 Redis 缓存命中率趋势
```
kubectl exec -n prod deploy/redis -c redis -- redis-cli INFO stats | grep -E 'keyspace_hits|keyspace_misses'
```
Expected: keyspace_misses 远高于 hits，确认缓存未命中率 > 90%
检查数据库活跃连接和等待事件
```
kubectl exec -n prod deploy/catalog-db -- psql -U app -c "SELECT count(*) FROM pg_stat_activity WHERE state != 'idle';"
```
Expected: 活跃连接数接近 max_connections，大量查询处于等待状态

查看数据库当前运行的慢查询

kubectl exec -n prod deploy/catalog-db -- psql -U app -c "SELECT pid, now() - pg_stat_activity.query_start AS duration, query, state FROM pg_stat_activity WHERE state != 'idle' ORDER BY query_start DESC LIMIT 10;"

Expected: 大量查询来自 catalog-svc，持续时间长，可能缺少索引

检查 catalog-svc 日志中的错误模式

kubectl logs -n prod -l app=catalog-svc --since=15m | grep -E 'ERROR|timeout|connection refused' | head -20

Expected: 大量数据库连接超时或拒绝连接错误

Mitigation plan

立即对 catalog-svc 进行限流，保护数据库不被压垮
Risk: 部分用户请求被拒绝，但可防止数据库完全崩溃。
Rollback: 移除限流配置，恢复原始流量
手动预热缓存：从数据库导出热门商品数据并写入 Redis，但需先降低 DB 负载
Risk: 直接查询数据库可能加剧负载，需先限流或扩容。
Rollback: 停止预热脚本，清除已写入的缓存键
扩容数据库副本（只读副本）分担查询压力
Risk: 扩容耗时较长，且需要修改连接配置。
Rollback: 缩容副本，恢复原状

Customer impact

用户访问商品详情页时遇到高延迟（15秒）或 503 错误，影响所有通过首页和营销邮件进入的用户。预计受影响用户数占黑五流量的 80% 以上。

Postmortem draft

Summary

[FILL IN]

Timeline (UTC)

08:59:58 — 最后一次缓存命中
09:00:00 — 缓存雪崩开始，大量缓存未命中
09:00:02 — 数据库连接池耗尽
09:02 — 告警触发
09:03 — 确认缓存雪崩
[FILL IN] — 限流实施
[FILL IN] — 缓存预热完成
[FILL IN] — 服务恢复

Impact

p99 延迟 15s，503 错误率 8%，持续约 [FILL IN] 分钟
影响所有商品详情页请求

Root Cause

缓存 TTL 统一为 7 小时，所有键在 09:00 UTC 同时过期，叠加黑五 12 倍流量，导致缓存雪崩，数据库过载。

Detection

Prometheus 告警：DBHighCPU、CatalogSvcLatencyHigh、CheckoutErrorRate

Response

限流 catalog-svc
手动预热缓存
扩容数据库副本

What Went Well

监控告警及时
缓存命中率指标帮助快速定位

What Went Poorly

缓存 TTL 未做抖动处理
未预演黑五流量场景

Action Items

[FILL IN] 缓存 TTL 增加随机偏移
[FILL IN] 实现缓存预热自动化
[FILL IN] 黑五前进行压测

Follow-ups

P0缓存 TTL 增加随机偏移，避免同时过期— service owner
P1实现缓存预热自动化脚本，支持手动触发— platform team
P0黑五前进行全链路压测，验证限流和扩容策略— SRE team
P1增加数据库连接池监控告警，设置更早的阈值— on-call SRE
P2评估数据库查询优化，添加必要索引— service owner

Similar past incidents

lexical match (pg_trgm)