延迟排查的分层地图
定位 Redis 延迟问题的第一步是分层：客户端到服务端的网络往返、客户端连接池排队、服务端单线程前的请求排队、命令自身执行耗时、后台任务（持久化、过期回收、淘汰、槽迁移）干扰，以及系统层资源（CPU 抢占、内存换出、磁盘 IO、容器配额）。每一层都有对应的观测手段，跨层跳跃排查往往会得出错误结论。实践统计里，报「Redis 变慢」的工单有相当一部分最终落在网络链路或业务侧调用方式，而不是命令执行本身。
基本信息
| 网络层 | ping / mtr / redis-cli --latency |
|---|---|
| 客户端层 | 连接池等待与重试日志 |
| 服务端排队 | INFO clients 的 blocked_clients |
| 执行层 | SLOWLOG / LATENCY LATEST / latencystats |
| 后台任务 | INFO persistence 与 fork 相关指标 |
| 系统层 | vmstat / iostat / CPU steal |
| 目标 | 先定性到层，再定量到命令 |
典型使用场景
- 业务侧 P99 上升，需要先判断是链路问题还是实例问题
- 同一实例上多业务互相指责，用分层证据划清责任边界
- 压测结果与线上表现不一致，核对是否忽略了客户端排队
- 排查周期性抖动，区分持久化 fork 与过期回收的贡献
- 容器环境延迟偏高，确认是否存在 CPU 限流与配额争抢
- 给延迟治理排优先级，先解决影响面最大的一层
分层取证的常用命令
分层取证的常用命令
redis-cli --latency # 从客户端测服务端往返延迟
redis-cli --latency-history # 按时间窗看延迟波动
redis-cli --intrinsic-latency 100 # 测本机自身调度延迟基线
redis-cli SLOWLOG GET 10 # 看是否有慢命令
redis-cli LATENCY LATEST # 看各类事件的最新尖峰
redis-cli INFO cpu # 主线程与后台线程的 CPU 分布
vmstat 1 5 # 系统层 CPU 等待与换页
iostat -x 1 3 # 磁盘层是否成为瓶颈分层证据对照
| 层 | 观测手段 | 典型信号 |
|---|---|---|
| 网络 | ping、mtr、--latency | 往返稳定但业务延迟高 |
| 客户端 | 连接池指标与重试 | 获取连接排队时间变长 |
| 服务端排队 | blocked_clients、连接数 | 命令积压在主线程前 |
| 执行 | SLOWLOG、latencystats | 个别命令耗时突出 |
| 后台任务 | fork 相关指标与日志 | 周期性尖峰与持久化时间吻合 |
| 系统 | vmstat、iostat、steal | CPU 被抢或磁盘饱和 |
先分层再下钻，避免一上来就在错误的层面消耗时间：命令级工具看不到网络抖动，网络工具也解释不了单核打满。
多租户实例上，把延迟时间轴与各业务的调用量曲线对齐，通常能快速锁定是哪个业务改变了负载结构。