如何通过Redis Slowlog分析复杂业务逻辑的性能瓶颈_导出慢查询并聚类-Redis-PHP中文网

slowlog get 导出需经结构化转换：用 redis-cli slowlog get n | jq -r '... ' 生成 csv，字段含 id、时间戳、耗时(μs)、命令名、参数、客户端地址、db 编号；参数中换行/引号已转义，避免解析错位。

如何通过redis slowlog分析复杂业务逻辑的性能瓶颈_导出慢查询并聚类

怎么用 SLOWLOG GET 导出可分析的原始数据

直接在 redis-cli 里执行 SLOWLOG GET 返回的是 Redis 协议格式（带嵌套数组），不适合 Excel 或 Python 直接处理。你需要先转成结构化文本，比如 CSV 或 JSON。

推荐用这个一行命令导出最近 1000 条（注意：必须连到每个节点单独执行）：

redis-cli -h node1 -p 7001 SLOWLOG GET 1000 | jq -r '.[] | "(.["1"]|tonumber),(.["2"]|tonumber),(.["3"]|tonumber),(.["4"][0]|tostring),(.["4"][1:]|join(" ")|gsub("
";" ")|gsub(""";"\"")),(.["5"]|tostring),(.["6"]|tostring)"' > slowlog_node1.csv

jq 是必须的，没装就先 brew install jq（macOS）或 apt install jq（Linux）
字段顺序是：ID,时间戳,耗时(μs),命令名,参数字符串,客户端地址,数据库编号
参数字符串里换行和引号会被转义，避免 CSV 解析错位
别漏掉 -h 和 -p ——集群里连错节点，导出来的日志跟业务完全对不上

为什么不能只看“耗时最长”的那几条命令

真实业务中，单次耗时 500ms 的 HGETALL 很吓人，但可能一天只发生 3 次；而平均耗时 8ms 的 INCR 每秒调用 2000 次，累积 CPU 占用反而更高。慢查询日志本身不带频次统计，必须补上聚合维度。

导出 CSV 后，用 pandas 做简单聚类（Python 示例）：

import pandas as pd
df = pd.read_csv("slowlog_node1.csv", names=["id","ts","us","cmd","args","client","db"])
# 按命令 + 参数模式粗粒度分组（例如把 "user:1001" "user:1002" 都归为 "user:*"）
df["pattern"] = df["args"].str.replace(r":d+", ":*", regex=True).str.slice(0, 64)
grouped = df.groupby(["cmd", "pattern"]).agg({"us": ["count", "mean", "max"], "id": "count"}).round(1)
print(grouped.nlargest(10, ("us", "count")))

关键不是 max(us)，而是 count 高 + mean(us) 超过 5ms 的组合
args 截断到 64 字符，防止 key 太长导致内存爆炸或分组散列失效
如果发现大量 pattern 是 "*"（比如 KEYS *），立刻停用 —— 这是集群级危险操作

如何关联到具体业务代码位置

SLOWLOG 不记录 trace_id、线程名或调用栈，但你可以通过两个线索反查：

Playground AI

一款集AI图像生成和图片编辑于一体的视觉创作工具，帮助用户制作、修改和组合图片，适合多种创意设计任务。

下载

第一，用客户端 IP + 端口（client 字段）去查服务日志。例如某条慢查询显示 "10.20.30.40:56789"，就在对应应用的 access.log 或 debug 日志里搜 56789，通常能定位到 Controller 或 Service 方法名。

第二，对高频慢命令加监控埋点。比如在 Java 里封装一层 Jedis.execute()，记录：

调用方类名 + 方法名（用 Thread.currentThread().getStackTrace() 抽最上层业务栈）
实际执行的完整命令（含所有参数）
是否在事务/ pipeline 内

这样下次再看到 HMGET user:123 profile:name profile:avatar 耗时高，就能直接跳转到 UserProfileService.getBasicInfo() 方法里看有没有缓存穿透或 N+1 查询。

聚类后仍无法定位根因？检查这三处隐藏配置

导出、分组、关联都做了，但还是找不到为什么某个 ZRANGE 总是慢——问题往往不在命令本身，而在环境配置：

slowlog-log-slower-than 被设成 0（记录所有命令），导致日志里混入大量本不该算“慢”的短命令，稀释了真瓶颈。确认当前值：CONFIG GET slowlog-log-slower-than
latency-monitor-threshold 没开（默认 0），无法捕获事件循环卡顿。它和 SLOWLOG 是互补的：前者抓 Redis 内部卡顿（如 AOF fsync），后者只抓命令执行耗时。建议设为 100（毫秒）并用 LATENCY LATEST 辅助验证
客户端用了 MGET 但 key 分布在多个 slot，触发了跨节点重定向（-MOVED）。这种请求在 SLOWLOG 里显示为单次长耗时，实际是多次网络往返叠加。用 CLUSTER KEYSLOT {key} 检查 key 分布是否集中