Redis 延迟监控深度指南

1 为什么需要内建延迟监控？

Redis 单线程＋磁盘持久化＋多种算法复杂度共存，一旦：

遇到 O(N) 大命令
AOF fsync / fork 挂起主线程
大量 Key 同秒过期 / 主动淘汰
宿主机抖动，导致系统调用耗时飙升

就会让所有客户端排队等待，出现毫秒到秒级 "雪崩"。

Latency Monitor 将这些 "卡点" 做成事件钩子并存储时间序列，让你可精确回放 spike 发生的时刻与持续时间，配合 LATENCY DOCTOR 产出可读结论。

2 事件模型与时间序列

事件名	监控对象	典型根因
`command`	所有命令	KEYS / ZINTERSTORE 等 O(N) 阻塞
`fast-command`	O(1)/O(logN) 命令	基线抖动
`fork`	`fork()` 复制页表	BGSAVE / BGREWRITEAOF
`aof-write` / `aof-fsync-*`	`write()` & `fsync()`	磁盘 IO / 共振
`expire-cycle`	主动过期采样	同批 EXPIREAT
`eviction-*`	内存淘汰	高频淘汰、热点 key 巨大
`active-defrag-cycle`	在线碎片整理	大碎片 + defrag aggressiveness

记录规则

每类事件独立 160 个桶：(timestamp, cost_ms)

同 1 秒内多次 spike 取最大，保证最少 160 秒历史

额外维护 "历史最大值" 方便基准比较

3 一键启用监控

bash 复制代码

127.0.0.1:6379> CONFIG SET latency-monitor-threshold 100   # 只记录 ≥100 ms
OK

阈值 = SLA-可接受延迟。例如业务要求"单条 ≤80 ms"，阈值可设 50 ms，提前预警。
线上零成本；禁用只需 CONFIG SET latency-monitor-threshold 0。

4 LATENCY 指令族速查表

子命令	作用	常用姿势
`LATEST`	输出最近一次 spike 格式：`[event ts cost]`	Dashboard 抓最新高延迟项
`HISTORY <event>`	取整条时间序列	时序图 / Promotheus Export
`GRAPH <event>`	终端 ASCII 图	SSH 即时观测
`RESET [event ...]`	清空某事件历史	回收内存 / 做 A/B 测试
`DOCTOR`	智能诊断报告	快速定位+给出 tuning 建议

样例：fork 事件图

bash 复制代码

127.0.0.1:6379> LATENCY GRAPH fork

复制代码

fork: (microseconds)
% > (msec) 999th cummulative latency distribution
99.4% ██████████████████████████████████████████████████ 44
 ...
100%  ██████████████████████████████████████████████████ 68

5 实战排障流程

5.1 高频命令延迟

LATENCY LATEST 出现 command > SLA
SLOWLOG GET 10 找具体指令
如果是
- SCAN 替代 KEYS
- 把大集合运算放到 Replica / 后台脚本
- 引入 Lua + 分批写，避免长事务

5.2 fork 卡顿

LATENCY GRAPH fork 有 50-500 ms 峰
INFO persistence 查看 latest_fork_usec
动作：
- 使用 HVM / 物理机、关闭 THP
- 大实例开启 linux-readahead 0, 避免写时极端 COW
- 避开业务高峰做持久化/重写

5.3 AOF fsync 峰值

aof-fsync-always or aof-write-pending-fsync spikes
解决：
- 改为 appendfsync everysec + no-appendfsync-on-rewrite yes
- 独立 NVMe 盘、开启 direct-io
- 若不要求秒级丢失，可用 appendfsync no + 双机热备

5.4 过期/淘汰抖动

expire-cycle 抖高：大量 key 同时过期，做 TTL 随机抖动
eviction-del 抖高：
- 优化 maxmemory 策略 → allkeys-lfu
- 检查是否有超大 value 导致单次 DEL 久

6 监控 & 告警集成

bash 复制代码

# example: 导出为 Prometheus 指标
redis-cli --raw LATENCY LATEST \
 | awk '{printf "redis_latency_spike{event=\"%s\"} %d\n", $1, $3}'

结合 redis_exporter 可自动拉取 LATENCY LATEST 指标。
建议对以下事件配置告警：command、fork、aof-fsync-always、expire-cycle。
触发后自动执行 LATENCY DOCTOR，邮件/钉钉输出诊断。

7 总结 & 最佳实践

阈值 = SLA 提前量 ，建议 TPS 高时 <1/2 SLA。
日常持续开 latency-monitor-threshold，日志轮转保留 7-30 天。
spike 首先看 事件类型→慢日志→系统调用 三步定位。
fork 与 fsync 难免有抖动 → 减峰就靠 磁盘隔离 + 业务错峰。
用 LATENCY RESET 在每次调优后清零，再观测新曲线。

有了 Latency Monitor，你能把 Redis 从黑盒变成可观测白盒 ------ 慢在那里、卡多久、为何卡，一查便知，助你稳稳守住延迟红线。祝线上永不宕，"毫"无压力！