Redis 消息队列运维中 Slow Log 查询耗时高怎么优化？

Redis 消息队列运维中遇到 Slow Log 记录命令耗时高的问题，本质是某些命令执行时间超过了阈值，而非查询日志功能本身慢。优先通过 SLOWLOG 定位具体命令，再结合业务场景评估是否涉及大键或阻塞操作，避免直接调整阈值掩盖问题。

先说结论：慢查询通常由特定命令或大键引起，优化重点在于找出耗时命令并调整数据结构或调用方式，而非单纯修改日志阈值。

先定位：使用 SLOWLOG GET 抓取耗时命令及参数
先调整：针对大键进行拆分或替换耗时命令
再验证：观察慢日志增长趋势及业务延迟变化

问题澄清与诊断

Redis Slow Log 记录的是执行时间超过指定阈值的命令，而非查询日志本身耗时。在消息队列场景中，常用的 List 或 Stream 结构如果元素过多，执行 LPUSH、BRPOP 或 XREAD 等命令时可能因数据量过大导致耗时增加。此外，持久化策略（如 AOF 重写）或内存淘汰也可能在主线程中产生短暂阻塞，被记录为慢查询。

redis-cli slowlog get 10

查看当前慢查询阈值设置（单位微秒）：

redis-cli config get slowlog-log-slower-than

安全排查大键

1. 大键定义标准

社区通常建议 String 值大于 10KB 或集合元素超过 5000 个视为大键，具体需结合业务吞吐量评估。单个 Key 元素数量控制在万级以下较为安全。

2. 安全扫描方式

警告：生产环境主节点直接运行 redis-cli `--bigkeys` 可能阻塞单线程，引发雪崩。建议采取以下安全方案：

方案 A（推荐）：在从节点（Replica）执行 redis-cli `--bigkeys`，避免影响主节点读写。
方案 B：导出 RDB 文件，使用离线分析工具（如 rdb-tools）分析大键。
方案 C：使用 SCAN 命令配合脚本在低峰期逐步遍历，避免使用 KEYS。

消息队列优化实操

1. List 队列分片示例

如果是因为 List 过长导致弹出慢，考虑拆分队列（如按用户 ID 哈希分片）。以下是客户端分片逻辑示例（Python）：

import hashlib
def get_queue_shard(user_id, shard_count=10):
    hash_val = hashlib.md5(str(user_id).encode()).hexdigest()
    return int(hash_val, 16) % shard_count

# 写入时
def push_message(user_id, message):
    shard = get_queue_shard(user_id)
    key = f"queue:{shard}"
    redis_client.lpush(key, message)

# 消费时需轮询所有分片
def consume_messages():
    for i in range(10):
        key = f"queue:{i}"
        msg = redis_client.brpop(key, timeout=1)

2. Stream 消费者组积压排查

如果是 Stream 消费慢，检查消费者组是否积压。使用以下命令组合查看 pending 消息数和消费者状态：

# 查看消费者组积压情况
redis-cli XINFO GROUPS mystream

# 查看具体 Stream 长度和基数
redis-cli XINFO STREAM mystream

# 调整 XREAD 的 COUNT 参数，避免一次性拉取过多
redis-cli XREADGROUP GROUP group1 consumer1 COUNT 100 STREAMS mystream >

3. 检查持久化配置

查看 appendfsync 配置。若设置为 always，每次写入都会同步磁盘，可能增加耗时。一般建议设置为 everysec。

redis-cli config get appendfsync

怎么验证是否生效

优化后，持续运行 SLOWLOG LEN 观察慢日志数量是否不再快速累积。同时监控业务侧的消息消费延迟，确认是否有明显改善。

# 观察慢日志长度变化
redis-cli slowlog len

# 清空慢日志（仅在确认问题已解决且需要重新统计时使用）
redis-cli slowlog reset

常见坑

1. 不要为了消除报警而调大 slowlog-log-slower-than 阈值，这只会掩盖问题。

2. 线上禁用 SLOWLOG RESET，除非你需要清空日志重新开始统计，否则会导致历史问题丢失。

3. 注意集群模式下的慢查询，需要连接到具体分片节点查看，代理节点可能无法显示全部信息。

4. 避免在生产环境主节点使用 KEYS 命令或直接运行 `--bigkeys`，可能导致服务不可用。

参考来源

Redis 官方文档 - Slow Log: https://redis.io/docs/management/optimization/slowlog/
Redis 官方文档 - Latency Optimization: https://redis.io/docs/management/optimization/latency/