最近线上 Redis 老是隔三差五地抽风，时而响应时间飙到几百毫秒，时而又恢复正常，看监控 qps 也没暴涨啊。一开始我以为是网络抖动，后来发现根本不是那么回事，而是踩了几个非常隐蔽的坑。排查过程里我顺手写了个小脚本，一键就能把这些坑扫出来，省得每次都要手动敲一堆命令。今天就跟你聊聊我踩过的这些坑，顺便把脚本的核心逻辑拆一拆。
脚本大概长这样，我会随着坑一个个讲，把代码片段拆出来给你看。
第一个坑：慢查询在那儿慢慢积着，你没看见
很多时候 Redis 变慢并不是因为请求量大，而是某些命令执行时间太长了，比如对一个有几百万个元素的 set 做 SMEMBERS，或者 keys * 这种扫全库的操作。慢查询日志是 Redis 自带的东西，但好多人根本不看它。我脚本里第一件事就是去捞慢查询：
# 获取最近10条慢查询，超过1000微秒就算慢
slowlog=$(redis-cli slowlog get 10)
echo "$slowlog" | while read line; do# slowlog 输出格式：1) (integer) 123 2) (integer) 1620000000 3) (integer) 15234 4) 1) "KEYS" 2) "*"# 提取 id、时间戳、执行耗时(微秒) 和命令id=$(echo "$line" | awk 'NR==1{print $2}')timestamp=$(echo "$line" | awk 'NR==2{print $2}')duration=$(echo "$line" | awk 'NR==3{print $2}')cmd=$(echo "$line" | awk 'NR==4{$1=""; print $0}')if [ "$duration" -gt 10000 ]; thenecho "⚠️ 慢查询 id=$id，耗时 ${duration}μs，命令: $cmd"fi
done
这个片段就是拿 slowlog，然后把耗时超过 10 毫秒的揪出来。很多时候你会发现有那种不经意间跑出来的 KEYS 或者大集合的聚合操作，一抓一个准。
第二个坑：客户端输出缓冲区被撑爆了
Redis 是单线程处理命令的，如果某个客户端的输出缓冲区满了，它就会把这个客户端挂起，直到缓冲区有空间。这时候其他客户端的请求会被阻塞，表现出来就是延迟突然变高。排查这个得看 client list 里的 obl 和 oll 字段。脚本里我会抓一下有哪些客户端 buffer 快满了：
# 检查所有客户端的输出缓冲区使用情况
redis-cli client list | awk -F'[ =]' '{# 提取 obl（输出缓冲区长度）、oll（输出列表长度）、omem（输出缓冲区占用内存）for(i=1;i<=NF;i++){if($i=="obl") obl=$(i+1)if($i=="oll") oll=$(i+1)if($i=="omem") omem=$(i+1)}if(obl>0 || oll>0){printf "客户端 %s 输出缓冲区 obl=%s oll=%s omem=%s\n", $1, obl, oll, omem}
}'
一旦看到某个客户端的 omem 很大，比如几十 MB，那基本就是它在大量订阅频道或者批量取数据，把 Redis 给拖慢了。
第三个坑：RDB 持久化在后台偷偷 fork 导致卡顿
Redis 做 RDB 持久化时会 fork 一个子进程，如果内存很大（比如 10GB 以上），fork 操作本身会阻塞主线程几毫秒甚至更久。而且 COW（写时复制）机制下，如果父进程写入频繁，需要复制大量内存页，也会带来延迟。脚本里我会看最近的 bgsave 状态和用时：
# 获取最近一次 bgsave 的状态和耗时
info=$(redis-cli info persistence)
last_bgsave_status=$(echo "$info" | grep "rdb_last_bgsave_status" | cut -d: -f2)
last_bgsave_time=$(echo "$info" | grep "rdb_last_bgsave_time_sec" | cut -d: -f2)
if [ "$last_bgsave_time" -gt 30 ]; thenecho "⚠️ 最近一次 bgsave 耗时 ${last_bgsave_time} 秒，可能造成卡顿"
fi
# 顺便看看当前是否正在执行 aof 重写，也一样会 fork
aof_rewrite=$(redis-cli info persistence | grep "aof_rewrite_in_progress:1")
if [ -n "$aof_rewrite" ]; thenecho "⚠️ 当前 AOF 重写正在进行，可能影响性能"
fi
有时候运维在业务高峰期配了个自动备份，刚好和写入高峰撞上，那延迟就上去了。
第四个坑：大 key 把网络带宽和 CPU 都占满
大 key 的读取会占用大量网络带宽和 CPU 序列化时间，而且删除它也会阻塞 Redis。脚本里我用 redis-cli --bigkeys 的输出来解析，但那个命令本身是扫描的，可能加重负载，所以我会加个采样判断：
# 使用 scan 扫描 key 并粗略估算大小，仅输出超过 1MB 的 key
cursor=0
while true; doresult=$(redis-cli scan $cursor count 1000)cursor=$(echo "$result" | head -1)keys=$(echo "$result" | tail -n +2)for k in $keys; dosize=$(redis-cli memory usage "$k" 2>/dev/null)if [ "$size" -gt 1048576 ]; thenecho "大 key: $k 占用 ${size} 字节"fidone[ "$cursor" -eq 0 ] && break
done
注意 memory usage 命令需要 Redis 4.0 以上，它比 debug object 更准。扫出来一堆几 MB 的 hash 或者 list，就是导致网卡流量跑满的元凶。
第五个坑：内存碎片高得离谱，但内存又没满
Redis 的内存分配器（如 jemalloc）会产生碎片，当碎片率过高时，虽然内存够用，但实际上分配新内存会变慢，甚至触发 eviction 策略。脚本里会检查 mem_fragmentation_ratio：
frag=$(redis-cli info memory | grep "mem_fragmentation_ratio" | cut -d: -f2)
if [ "$(echo "$frag > 1.5" | bc)" -eq 1 ]; thenecho "⚠️ 内存碎片率: $frag，大于 1.5 建议考虑重启或启用 activedefrag"
fi
如果碎片率超过 1.5，尤其在频繁更新不同大小 value 的场景下，考虑开启 activedefrag 或者挑个低峰重启。
脚本把这些检测集成在一起，执行一下就把可疑点全列出来了，帮我省了不少时间。当然具体的阈值需要根据你的业务调整，比如慢查询的阈值、bgsave 耗时的容忍度等等。
实际生产里很多 Redis 突然变慢的锅，都是这些“藏得很深”的问题——慢查询不去看，客户端 buffer 满了不去查，fork 引起的卡顿被监控曲线平滑掉，大 key 带偏整个集群。希望这些经验和你看到的脚本片段能让你下次排查的时候有个方向，不用再猜来猜去。