## 8）给交易平台的 Redis Checklist（可直接贴到变更评审里）

1) **TTL 必须抖动**（避免雪崩）

2) 热点 Key 评估：是否需要本地缓存 / 分片 / 批量化

3) 回源必须可控：熔断/限流/降级策略写清楚

4) 关键 Key 的空值策略：占位符 + 短 TTL

5) 大 Key 禁止：单 Key 超过阈值（例如 256KB）要拆

6) 序列化统一：JSON 也好 Kryo 也罢，别混着来

7) 指标到位：命中率、p99、连接数、慢命令采样

---

## 9）收个尾：凌晨告警之后，我们学到的“硬道理”

那天凌晨我们做了三件事，服务就稳了：

1) 订单缓存 TTL 加抖动（雪崩直接止血）

2) 热点回源加互斥锁（击穿不再羊群）

3) 支付成功页增加本地 2 秒缓存 + pipeline（把 Redis 压力降下来）

最后在群里留下了一个很职业的总结：

> Redis 不是万能药，它只是让你在“快”和“稳”之间有了更多选择。

> 选择得不好，它也会让你更快地见到凌晨。

下一篇（第 7 篇）我们会把这些事故变成**可观测性**：链路追踪、日志、指标怎么“拧成一根绳”，让你在告警响之前就看到风险在长大。

——

**彩蛋**：那天我同事说“我只改了个 TTL”，我说“没事，反正 TTL 也改了你的寿命（睡眠版）”。