redis-cli --bigkeys仅能识别大Key，无法定位阻塞源头，因其不提供调用方、频次及上下文信息；须结合CLIENT LIST查高qbuf连接、SLOWLOG捕获慢命令，并回溯应用线程栈确认具体代码位置。
redis-cli --bigkeys 只能发现大Key，不能定位阻塞源头
很多人一看到 Redis 响应变慢，第一反应就是跑 redis-cli --bigkeys。它确实能扫出 String 超 10KB、Hash 元素超 5000 个这类典型大 Key，但问题在于：它不告诉你「谁在调用」、「调用频次」、「调用时上下文」。一个被高频读取的中等大小 Hash，也可能因 HGETALL 拖垮主线程，而 --bigkeys 完全不会标记它。
真正要定位外部系统调用引发的阻塞，得从「客户端行为反推服务端压力」入手，而不是只盯着 Key 本身。
用 CLIENT LIST + SLOWLOG 找出高耗时连接和命令
Redis 自身提供了两个关键命令，组合使用就能锁定可疑客户端：
-
CLIENT LIST查看所有活跃连接，重点关注idle（空闲秒数）、cmd（最近执行命令）、qbuf（查询缓冲区字节数）——如果某个连接qbuf持续 >1MB，大概率是客户端发了一个巨量请求后卡住了没读响应 -
SLOWLOG GET 10拉最近 10 条慢日志，注意看duration（微秒级）和argv（完整命令参数）。若出现LRANGE 0 -1或HGETALL且duration > 1000000（即 >1ms），基本可判定该调用来自某业务方未做分页或懒加载
特别注意：SLOWLOG 默认只记录 >10ms 的命令，生产环境建议提前设为 CONFIG SET slowlog-log-slower-than 1000（1ms），否则很多毛刺会被漏掉。
结合应用层线程栈确认调用来源
Redis 端只能看到「哪个 IP 和端口」在发慢命令，但无法知道是哪个服务、哪个线程、哪行代码。这时候必须回溯到应用进程：
- Java 服务：用
jstack -l <pid></pid>抓线程快照，过滤出处于java.net.SocketInputStream.socketRead0或redis.clients.jedis.Connection.getInputStream状态的线程，它们往往正卡在等待 Redis 响应 - 看这些线程的上层调用栈，通常会暴露具体类名和方法名，比如
UserService.getUserFeed()或CacheService.batchLoadKeys() - 如果线程栈里反复出现
UNSAFE.park+ThreadPoolExecutor$Worker，说明线程池里有任务在等 Redis 返回，而 Redis 正被大 Key 阻塞——这是典型的「阻塞传递」现象
别依赖日志里那句“JedisConnectionException: java.net.SocketTimeoutException”，它只是结果；真正要抓的是超时前 2 秒内正在执行什么逻辑。
警惕那些不报错却持续占着连接的客户端
最麻烦的不是报错的调用，而是「不报错但不读响应」的客户端。比如一个 Go 服务用 redis.Client.Do() 发了 SMEMBERS huge_set，但没加 context 或 timeout，自己先 panic 了，却没关闭连接。这个连接会一直挂在 Redis 里，CLIENT LIST 显示 idle 时间不断增长，qbuf 却越堆越大，最终拖慢整个实例。
这类问题不会触发 SLOWLOG，也不会被 --bigkeys 扫到，唯一线索是 INFO clients 中 connected_clients 持续高于正常水位，且 blocked_clients 为 0 ——说明不是 Redis 主线程卡住，而是客户端侧出了问题。
