「Redis 变慢」怎么定位
先定义慢：是单条命令延迟高、整体请求超时，还是某个业务接口偶发卡顿。定义清楚再分层排查——慢命令、大 key 与热 key、持久化与 fork、服务端延迟事件、网络与客户端连接池，逐层排除比盲目重启有效。
基本信息
| 慢命令 | SLOWLOG GET，阈值由 slowlog-log-slower-than 控制，单位微秒 |
|---|---|
| 延迟事件 | LATENCY LATEST 与 LATENCY RESET，覆盖 fork、过期、命令等 |
| 客户端视角 | redis-cli --latency 与 --latency-history 直接测往返延迟 |
| 大 key | redis-cli --bigkeys 为抽样扫描，建议业务低峰执行 |
| 开关 | latency-monitor-threshold 默认 0 表示关闭，排查前临时打开 |
常见四类原因
- 慢命令类：大集合上的聚合、KEYS、SORT、复杂 Lua，单线程下会阻塞所有请求
- 后台任务类：fork、AOF 重写、fsync 抖动，表现为周期性尖刺而非持续变慢
- 数据类：单个大 key 读写、热 key 集中、大量键在同一时刻集中过期
- 外部类：网络抖动、客户端连接池打满、宿主机 CPU 被其他进程争抢
分层排查命令
分层排查命令
redis-cli SLOWLOG GET 20 # 最近的慢命令及耗时
redis-cli SLOWLOG RESET # 处理完清空，避免干扰下次分析
redis-cli CONFIG SET latency-monitor-threshold 50 # 打开 50 毫秒延迟监控
redis-cli LATENCY LATEST # 服务端记录的延迟事件
redis-cli LATENCY RESET # 排障结束复位统计
redis-cli --latency # 客户端视角的实时延迟
redis-cli INFO persistence | grep rdb_last_bgsave_status现象与嫌疑对照
| 现象 | 优先怀疑 | 下一步动作 |
|---|---|---|
| 周期性每秒尖刺 | RDB 快照或 AOF 重写 | 看最新 fork 耗时与持久化状态 |
| 持续高延迟 | 慢命令或大 key | 查慢日志与键规模，改访问模式 |
| 单接口偶发慢 | 热 key 或客户端池 | 看连接明细与超时重试设置 |
| 整体抖动 | 宿主机资源争抢 | 看 CPU 与磁盘等待，核对备份任务 |
慢日志只记录命令耗时，dump、fsync 这类阻塞不进去，必须配合延迟事件统计才能覆盖全貌。
生产环境不要用 KEYS 或全量键扫描做排查：本身就会把实例压慢，应放在从库或业务低峰窗口执行。
先问的三个问题
- 慢的范围有多大：全部请求慢说明实例级问题，少数请求慢更像数据分布问题
- 什么时候开始慢：与发布、备份、扩容等变更时间点对齐能立刻缩小嫌疑范围
- 慢之前改了什么：参数、键结构、客户端版本这三类变更最容易引发性能变化