BLPOP可替代while True+RPOP轮询，通过服务端挂起连接实现零CPU空转、低延迟、高效率；其timeout单位为秒，返回[key,value]二元组或null/None，多key监听按从左到右优先级消费，需严格统一配置。
BLPOP 怎么替代 while True + RPOP
直接用 RPOP 轮询空队列，每秒发几十次命令，Redis QPS 拉高、客户端 CPU 白跑、消息延迟不可控——BLPOP 就是来砍掉这层无效循环的。它让连接在服务端挂起，不占 CPU、不刷网络、数据一到立刻唤醒。
关键区别在于：轮询是「我主动问，你答没有」；BLPOP 是「我等你通知，有才叫我」。
-
BLPOP的 timeout 参数单位是秒，不是毫秒（常见误填为1000导致等 1000 秒） - 返回值永远是
[key, value]形式的二元数组（或[null, null]表示超时），不是单个字符串，别直接取get(1)或调.toString() - 超时返回
None（Python）或null（Java），不是空列表，判空必须检查整个返回对象是否为null/None
多 key 优先级队列必须用 BLPOP 顺序监听
想实现高/中/低三级任务队列？别用一个 List 加字段判断优先级，那会破坏原子性。正确做法是拆成三个 key：queue:high、queue:medium、queue:low，然后用一条 BLPOP 同时监听：
BLPOP queue:high queue:medium queue:low 30
Redis 会严格从左到右扫描，只要 queue:high 有数据，就立刻弹出，不会跳过；所有都空才阻塞 30 秒后返回 [null, null]。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 入队方向必须匹配：高优任务用
LPUSH queue:high "task"，对应出队必须是BLPOP（不能混用BRPOP） - 多个消费者同时执行同一句
BLPOP是线程安全的，Redis 内部保证只有一个能拿到数据 - 所有消费者配置的 key 列表顺序、timeout 值必须完全一致，否则会出现「高优队列有数据却没人消费」的静默故障
Python redis-py 中 BLPOP 的异常兜底怎么写
很多人写 while True: r.blpop("q", 0)，看似简洁，但网络断开、Redis 重启、连接超时都会让程序直接崩溃。
生产环境必须包在 try/except 里，并做连接重建和退避：
import redis
import time
<p>r = redis.Redis()</p><p>while True:
try:
res = r.blpop("task_queue", timeout=5)
if res is None:
continue # 超时，继续下一轮
key, payload = res
handle(payload)
except redis.ConnectionError:
time.sleep(1)
r = redis.Redis() # 重连
except KeyboardInterrupt:
break- 永远不用
timeout=0上生产，设为5～30秒，避免连接僵死 - 收到
None时加日志（比如logging.debug("BLPOP timeout on task_queue")），否则问题无法定位 -
ConnectionError不代表永久失败，sleep 后重连即可，别直接退出进程
Java RedisTemplate 调用 BLPOP 的两个硬坑
RedisTemplate 默认封装层不支持阻塞命令，必须穿透到底层原生连接，且字节处理极易出错。
- 必须用
redisTemplate.getConnectionFactory().getConnection()获取RedisConnection，不能用opsForList() -
connection.bLPop(timeout, key.getBytes())的timeout单位是秒，传30000就等于等 30000 秒 - 返回值是
List<byte></byte>，长度可能为 0 或 2；超时时返回null，不是空List，判空要写if (result == null) - 结果解码需手动：用
new String(result.get(1), StandardCharsets.UTF_8)，别依赖默认字符集
真正难的从来不是写出那条 BLPOP 命令，而是确保所有生产者严格遵守 LPUSH 入队、所有消费者监听的 key 名/顺序/timeout 完全一致——这些配置一旦分散在不同服务里，故障就会无声无息地发生。
