引言
在 Redis 运维和性能调优中，慢查询和延迟毛刺是最常见的两类问题。很多面试题都会围绕这两个话题展开，例如：“Redis 慢查询日志怎么用？”“Latency Monitor 能解决什么问题？”“慢查询日志和 latency monitor 有什么区别？”本文将从实战角度出发，系统讲解这两个工具的原理、配置、使用方法和常见面试考点。
一、Redis 慢查询日志
1.1 什么是慢查询日志
Redis 的慢查询日志（Slow Log）用于记录执行时间超过指定阈值的命令。它记录的是命令执行阶段的耗时，不包括网络传输和排队等待时间。注意，这里的“执行时间”指的是 Redis 从开始处理命令到返回结果的时间，不包含 I/O 多路复用等待和客户端网络延迟。
1.2 相关配置参数
在 redis.conf 中有两个关键参数：
slowlog-log-slower-than：阈值，单位微秒（1 秒 = 1,000,000 微秒）。默认 10000，即 10 毫秒。设置为 0 会记录所有命令，设置为负数则关闭慢查询日志。slowlog-max-len：慢查询日志的最大条数，默认 128。当超过这个数量时，最旧的记录会被删除。
可以通过 CONFIG SET 动态修改：
CONFIG SET slowlog-log-slower-than 5000
CONFIG SET slowlog-max-len 256
1.3 常用命令
SLOWLOG GET [n]：获取最近 n 条慢查询记录，不指定 n 则返回全部。SLOWLOG LEN：获取慢查询日志的条数。SLOWLOG RESET：清空慢查询日志。
每条慢查询记录包含以下字段：
- 日志 ID
- 命令执行的时间戳
- 命令耗时（微秒）
- 命令及其参数
- 客户端 IP 和端口（Redis 4.0+）
- 客户端名称（Redis 4.0+）
示例输出：
1) 1) (integer) 14
2) (integer) 1690000000
3) (integer) 15000
4) 1) "keys"
2) "*"
5) "127.0.0.1:52344"
6) ""
1.4 慢查询日志的底层结构
Redis 使用一个链表（list）来保存慢查询日志，新记录插入头部，超过 slowlog-max-len 时从尾部删除。慢查询日志保存在内存中，不会持久化到磁盘，重启后丢失。因此生产环境建议定期通过 SLOWLOG GET 采集并落盘分析。
1.5 面试常见问题
问：慢查询日志会记录哪些命令？
答：只记录命令执行时间超过阈值的命令，不记录网络延迟和排队时间。另外，SLOWLOG 命令本身不会被记录。
问：为什么慢查询日志条数建议不要设置太大？
答：慢查询日志保存在内存中，条数过多会占用内存；同时 SLOWLOG GET 返回大量数据会阻塞 Redis。建议设置为几百到一千左右，并定期采集清理。
问：keys * 为什么是慢查询常客？
答：keys * 会遍历所有键，时间复杂度 O(N)，在键数量大时会严重阻塞 Redis 单线程。生产环境应使用 SCAN 替代。
二、Latency Monitor（延迟监控）
2.1 为什么需要 Latency Monitor
慢查询日志只能记录命令执行本身的耗时，但 Redis 的延迟可能来自其他环节，例如：
- 网络 I/O 阻塞
- fork 子进程（RDB/AOF 重写）
- 过期键集中删除
- 大 key 删除
- 内存交换（swap）
- 操作系统调度
这些延迟不会体现在慢查询日志中，但会直接影响客户端体验。Latency Monitor 正是为此设计的，它从事件层面监控 Redis 内部各种可能造成延迟的事件。
2.2 配置参数
latency-monitor-threshold：延迟阈值，单位毫秒，默认 0（关闭）。只有超过该阈值的事件才会被记录。
动态开启：
CONFIG SET latency-monitor-threshold 100
2.3 常用命令
LATENCY LATEST：返回所有最近发生延迟的事件。LATENCY HISTORY <event>：返回指定事件的历史延迟记录。LATENCY RESET [event ...]：重置延迟数据。LATENCY DOCTOR：给出延迟问题的诊断建议。
示例：
127.0.0.1:6379> LATENCY LATEST
1) 1) "command"
2) (integer) 1690000000
3) (integer) 150
4) (integer) 200
字段含义：事件名、最后发生时间戳、最新延迟毫秒数、历史最大延迟毫秒数。
2.4 常见延迟事件类型
command：普通命令执行fast-command：O(1) 或 O(log N) 命令fork：fork 子进程耗时expire-cycle：过期键删除周期eviction-del：内存淘汰删除键eviction-cycle：内存淘汰周期
2.5 面试常见问题
问：Latency Monitor 和慢查询日志的区别？
答：慢查询日志关注“命令执行时间”，Latency Monitor 关注“Redis 内部事件造成的延迟”，覆盖范围更广，包括 fork、过期删除、淘汰等。两者互补，不能互相替代。
问：Latency Monitor 会影响性能吗？
答：开启后会有少量性能开销，但影响很小。建议生产环境设置合理阈值（如 100ms）长期开启，便于事后排查。
问：LATENCY DOCTOR 有什么用？
答：它会根据当前延迟数据给出人类可读的诊断建议，例如提示“fork 耗时过长，建议检查内存和持久化配置”，是排查延迟问题的好帮手。
三、实战排查思路
当出现 Redis 延迟问题时，建议按以下步骤排查：
- 查看慢查询日志：
SLOWLOG GET 10，确认是否有慢命令。 - 查看延迟监控：
LATENCY LATEST和LATENCY DOCTOR，确认延迟来源。 - 检查大 key：使用
redis-cli --bigkeys或MEMORY USAGE。 - 检查持久化：关注 fork 耗时、AOF 重写频率。
- 检查系统层面：内存 swap、CPU 负载、网络状况。
四、总结
| 对比项 | 慢查询日志 | Latency Monitor |
|---|---|---|
| 监控对象 | 命令执行时间 | 内部事件延迟 |
| 单位 | 微秒 | 毫秒 |
| 默认状态 | 开启（阈值 10ms） | 关闭 |
| 持久化 | 否 | 否 |
| 典型用途 | 发现慢命令 | 发现延迟毛刺 |
掌握这两个工具，不仅能应对面试中关于 Redis 性能调优的问题，更能在实际生产环境中快速定位性能瓶颈。建议在测试环境先熟悉命令，再在生产环境设置合理阈值长期监控，做到有备无患。
未经允许不得转载：任鹏个人博客 » Redis 慢查询日志与 Latency Monitor 使用详解
