1. 什么是Redis慢日志？

想象你开着一辆跑车在高速路上飞驰，突然仪表盘亮起故障灯——这就是Redis慢日志的作用。它会记录执行时间超过指定阈值的命令操作，像汽车的黑匣子一样完整记录每个"异常操作"的细节。

Redis默认配置的慢查询阈值是10000微秒（10毫秒），这意味着任何执行时间超过这个值的命令都会被记录到慢日志中。但真实的线上环境可能需要更严格的监控标准，我们稍后会讨论如何调整。

2. 配置你的慢日志雷达

让我们先准备实验环境：

docker run -d --name redis-slowlog -p 6379:6379 redis:7.0

# 连接Redis客户端
docker exec -it redis-slowlog redis-cli

在Redis客户端中配置慢日志参数：

# 设置慢查询阈值为5毫秒（5000微秒）
CONFIG SET slowlog-log-slower-than 5000

# 保留最近的200条慢查询记录
CONFIG SET slowlog-max-len 200

# 查看配置是否生效
CONFIG GET slowlog*

输出示例：

1) "slowlog-log-slower-than"
2) "5000"
3) "slowlog-max-len"
4) "200"

3. 实战案例：制造和观察慢查询

我们模拟一个复杂查询场景：

# 生成测试数据（插入10万条hash数据）
EVAL "for i=1,100000 do redis.call('hset', 'bigkey', 'field'..i, 'value'..i) end" 0

# 执行可能触发慢查询的操作
HGETALL bigkey

# 立即查看慢日志
SLOWLOG GET 2

输出结果示例：

1) 1) (integer) 1               # 日志条目ID
   2) (integer) 1659345678      # 时间戳
   3) (integer) 15432           # 执行耗时（微秒）
   4) 1) "HGETALL"              # 命令及参数
      2) "bigkey"
   5) "127.0.0.1:43210"         # 客户端地址
   6) "client-name"             # 客户端名称（如有）

4. 慢日志分析的四大实战场景

场景一：大Key排查

# 危险操作示例
KEYS *模糊匹配*

慢日志中出现大量SCAN类命令时，通常意味着存在不合理的大Key遍历操作。

场景二：复杂命令滥用

# 时间复杂度O(N)的操作
ZUNIONSTORE result 3 set1 set2 set3 WEIGHTS 1 2 3

当发现ZINTERSTORE、SINTER等集合操作频繁出现在慢日志中，需要考虑数据结构优化。

场景三：网络瓶颈识别

# 客户端IP显示频繁变更的地址
"client": "10.0.0.5:63452"

结合客户端地址分析，可以定位到具体的应用服务器或异常客户端。

场景四：热点Key追踪

# 相同Key频繁出现
1) "GET"
2) "hot_product_123"

连续出现的相同Key操作，提示可能存在缓存穿透或热点Key问题。

5. 慢日志分析的三大工具技巧

技巧一：日志持久化

# 定期将慢日志写入文件
redis-cli SLOWLOG GET 100 > /var/log/redis/slowlog-$(date +%Y%m%d).log

技巧二：实时监控脚本

import redis
import time

r = redis.Redis()
last_id = 0

while True:
    logs = r.slowlog_get()
    for log in logs:
        if log['id'] > last_id:
            print(f"[警报] 慢查询：{log['command']} 耗时 {log['duration']}微秒")
            last_id = log['id']
    time.sleep(5)

技巧三：自动化分析命令

# 统计最耗时的Top5命令
SLOWLOG GET 100 | grep "3) (integer)" | sort -k3 -n -r | head -5

# 查找高频命令
SLOWLOG GET 100 | awk -F '"' '{print $2}' | sort | uniq -c | sort -nr

6. 技术方案的优劣辩证

优势：

  • 零成本：原生功能无需额外依赖
  • 实时性：毫秒级响应延迟捕获
  • 完整性：记录客户端信息和完整命令

局限：

  • 无可视化：需要自行处理原始数据
  • 无历史存储：重启后日志丢失（需自行持久化）
  • 单点视角：集群环境需要逐个节点检查

7. 性能优化的黄金法则

配置建议：

  • 生产环境阈值建议：1-5毫秒
  • 日志长度至少保留500条
  • 定期归档日志（每小时归档一次）

避坑指南：

  1. 避免在慢日志分析期间执行SLOWLOG RESET导致日志丢失
  2. 当发现CONFIG SET频繁出现在日志中，说明存在过多动态配置变更
  3. 对FLUSHALL命令要保持高度警惕，可能是误操作信号

8. 真实案例分析

某电商平台大促期间出现接口超时，通过慢日志发现：

[记录1] SORT product_list BY weight_* GET # GET price_* → 耗时48ms
[记录2] EVAL "复杂Lua脚本" → 耗时32ms

问题定位：

  1. 滥用SORT命令的多字段排序
  2. Lua脚本未使用SCRIPT LOAD优化

优化方案：

  • 改用ZSET实现排序需求
  • 将Lua脚本预加载为SHA1摘要
  • 增加客户端本地缓存

优化后效果：API响应时间从平均50ms降至8ms，慢日志条目减少90%。

9. 总结与展望

通过Redis慢日志分析，我们就像拥有了系统性能的X光机。记住三个关键数字：5毫秒（监控阈值）、200条（最小日志容量）、每周一次（定期分析频率）。当遇到性能问题时，慢日志应该是你的第一张排查清单。

未来可以结合Prometheus+Grafana搭建监控体系，但慢日志始终是问题定位的"第一现场"。就像老司机不仅看仪表盘，还要会听发动机声音——慢日志就是Redis引擎的声纹记录器。