REDIS · INCIDENT DESK
--:--:--
证据优先 / 变更克制

半夜告警排障决策树

先别重启 Redis,
先确认是谁在变慢。

从告警现象进入,用现有监控和只读命令回答每一步。每个选择都会缩小故障域,并在终点生成「立即止血、继续取证、明确禁忌」清单。

INCIDENT / TRIAGE
CLIENTioredis 连接池、事件循环、重试
NETWORK链路延迟、丢包、DNS、代理
REDIS慢命令、内存、持久化、容量
等待选择告警入口

00 / 选择入口

你现在看到的是哪一条告警?

不要从“Redis 肯定坏了”出发。先选最先触发值班响应的信号,再把应用、链路和服务端的时间线对齐。

客户端层

Redis 指标平稳,但应用侧排队、超时或连接重建明显。

查 ioredis error/reconnecting/end、事件循环延迟、连接复用和重试放大。

网络层

服务端命令很快,客户端往返却慢,而且同机房/跨机房表现不同。

查 TCP 重传、DNS、代理/LB、跨可用区路径;用正常客户端复现,不靠高压探测。

Redis 服务端

SLOWLOG、LATENCY、CPU、内存或 commandstats 与告警时间吻合。

先限流和隔离高代价流量,再处理数据模型、容量、持久化或淘汰策略。