blocked_clients > 0 不一定表示故障，需结合idle时长、cmd类型、addr/name定位异常阻塞；验证客户端连接状态与Redis timeout配置，避免误杀，长期应优化客户端超时逻辑和连接池管理。
blocked_clients 值持续大于 0 怎么确认是否真阻塞
不是所有 blocked_clients > 0 都代表故障——它只是说明有客户端正在等待阻塞命令返回，比如业务正常用 BLPOP 消费队列时，这个值就天然非零。关键看是否「异常升高」或「长期不降」。
先执行 redis-cli info clients | grep blocked_clients 获取当前值；再结合 client list 筛出阻塞连接：redis-cli client list | grep "flags=b"。重点检查：
-
idle字段：如果阻塞连接的idle超过你业务预期的等待时长（比如队列通常 1s 内有数据，但某连接idle=120），大概率是消费者挂了或逻辑卡死 -
cmd字段：确认是不是blpop/brpop/brpoplpush这类合法阻塞命令；如果出现cmd=eval或cmd=script且 flags=b，说明 Lua 脚本里用了阻塞操作（非法） -
addr和name：快速定位是哪个应用 IP 或连接名，方便联系对应服务负责人
为什么 BLPOP 后客户端没及时唤醒
常见原因不是 Redis 本身问题，而是上游生产者断流、下游消费者崩溃，或网络中间件（如 SLB、Proxy）悄悄断开了空闲连接但没通知 Redis。
Redis 不会主动探测客户端是否存活，只依赖 TCP keepalive（默认 2 小时）或客户端主动发包。所以即使消费者进程已退出，只要连接没被 OS 关闭，Redis 仍认为它在等待。
验证方式：
- 在客户端机器上执行
ss -tnp | grep :6379，看对应addr的连接状态是不是ESTABLISHED—— 如果是CLOSE_WAIT或已消失，说明客户端已断，但 Redis 还没清理 - 检查 Redis 的
timeout配置：config get timeout。若为 0，Redis 永远不会主动断开空闲连接，blocked_clients就可能越积越多 - 注意：Linux 内核的
tcp_fin_timeout（默认 60s）和连接池的maxIdleTime设置，可能比 Redis 的timeout更早终结连接，造成状态不一致
临时止血：kill 阻塞连接要避开哪些坑
直接 client kill 能快速释放连接，但容易误杀正在处理关键任务的连接，尤其是用了 BRPOPLPUSH 做可靠队列时，kill 可能导致消息丢失。
安全操作顺序：
- 先确认该连接没有关联未完成事务：
redis-cli client list | grep -A5 "id=12345"，看multi字段是否为 -1（-1 表示未进事务，可安全 kill） - 避免用
client kill addr=xxx，改用client kill id=12345，精确到连接 ID，防止 IP 端口复用冲突 - 不要批量 kill：
client list | grep "flags=b" | head -n 10 | awk '{print $2}' | xargs -I{} redis-cli client kill {}这类脚本风险极高，可能干掉刚建立的健康连接 - 如果
blocked_clients突然从个位数跳到几百，优先查客户端日志——大概率是某台应用节点的连接池配置崩了（比如blockWhenExhausted=false导致疯狂重连）
长期治理：从客户端代码和 Redis 配置双侧控制
单纯靠运维 kill 是治标。真正要收敛 blocked_clients 异常，得让客户端“借得明白、还得干净、等得有度”。
客户端侧必须检查：
- Jedis/Lettuce 连接池是否启用
testOnBorrow=true？它会让每次取连接都发PING，在高并发下压垮 Redis 单线程，间接导致阻塞命令排队延迟上升 - 消费逻辑是否有兜底超时：比如
BLPOP key 30中的 30 秒不能写死成 0（无限等待），也不能设太大（如 300），否则一个卡住就拖住整个连接池 - 是否监听了连接关闭事件？应用重启或异常退出时，应显式调用
close()或destroy()，而不是依赖 GC
Redis 侧建议加固：
- 把
timeout从 0 改为合理值（如 300），让空闲阻塞连接能被自动回收 - 开启慢查询日志：
slowlog log-slower-than 10000，确认有没有BLPOP因大 key 或磁盘 I/O 被拖慢 - 监控链路里加一层判断：当
blocked_clients / connected_clients > 0.3且持续 2 分钟，才触发告警——过滤掉瞬时抖动
最易被忽略的一点：阻塞客户端数量本身不是根因，它是客户端行为失当在 Redis 上的投影。盯着指标不如翻客户端连接池配置和消费逻辑日志。
