---

## 8. 给自己留条活路：Redis 故障时的“交易链路应急预案”

我特别建议把下面这份清单写进 runbook（别只放在脑子里，脑子在凌晨三点会 404）：

### 8.1 读链路（商品/规则）

- **P99 延迟飙升**：立刻把读超时下调，触发降级（本地缓存 / 静态兜底）。

- **命中率下降**：优先怀疑缓存重建策略（互斥锁等待、逻辑过期重建失败）。

- **出现大量回源**：先限流，再补预热；不要一边被打，一边“边跑边修车”。

### 8.2 写链路（库存/限购）

- Redis 不可用时：

- **强一致链路**（库存扣减）优先走排队/熔断（第 4 篇的队列化方案）；

- **可补偿链路**（限购统计）写 DB 或消息队列，异步修正。

- **禁止无脑重试**：重试只会把抖动放大成雪崩，交易系统最怕“自我感动式的可靠性”。

### 8.3 必备监控（最低配）

- 应用侧：Redis 调用 P95/P99、错误率、超时率、降级次数。

- Redis 侧：CPU、网络带宽、连接数、慢查询、keyspace hits/misses。

- 业务侧：下单成功率、库存扣减失败原因分布、队列堆积长度。

---

## 9. 结尾彩蛋：两种“缓存观”

- 初级：缓存是性能优化。

- 高级：缓存是故障隔离。

真正的架构不是把 QPS 写上去，而是把**坏消息**关在它该待的房间里。