Redis Pub/Sub 不支持优先级，仅为瞬时广播；真正优先级队列需用 List + BRPOP 多键轮询，按 queue:high→queue:medium→queue:low 顺序原子消费，Pub/Sub 仅作轻量通知触发器。
Redis Pub/Sub 本身不支持优先级
Pub/Sub 是纯广播模型，PUBLISH 发出去的消息会立刻推给所有 SUBSCRIBE 该频道的客户端，没有队列缓冲、没有顺序保证、也不支持重试或延迟。最关键的是：它压根没有「优先级」概念——你不能指定某条 PUBLISH 消息要先被消费，也不能让订阅者按权重拉取。一旦消息发出，要么被实时收到，要么就彻底丢失（无持久化）。
用 List + BRPOP 实现真正的优先级队列
真正可控的优先级处理必须依赖 Redis 的 List 结构和阻塞弹出命令。核心逻辑是：把不同优先级的任务写入不同 key，再用 BRPOP 按顺序轮询这些 key。
-
BRPOP支持传入多个 key，从左到右依次检查，只在最左边非空的 list 中弹出元素 - 高优先级任务写入
queue:high，中优先级写入queue:medium，低优先级写入queue:low - 消费者执行
BRPOP queue:high queue:medium queue:low 0，永远优先处理queue:high中的任务 - 如果
queue:high为空，才会去queue:medium取；全空才落到queue:low
注意：BRPOP 是原子操作，不会出现「检查 high 为空 → 切换到 medium → high 突然来了新任务」这种竞态，安全可靠。
Pub/Sub 只适合做「通知触发器」，别当队列用
想让优先级队列更灵活？可以把 Pub/Sub 当作轻量通知层：比如有新高优任务入库时，PUBLISH task:priority:high "ready"，监听这个频道的服务立刻触发一次 BRPOP 轮询，避免长轮询等待。但别指望靠 SUBSCRIBE task:priority:high 直接拿到任务内容——任务本体必须存在 List 里，Pub/Sub 只负责喊一嗓子。
- 错误做法：
PUBLISH task:high '{"id":123}'然后让 worker 直接处理这条消息 → 消息可能丢失，且无法重试 - 正确做法：
LPUSH queue:high '{"id":123}'+PUBLISH notify:high "new"→ worker 收到通知后执行BRPOP queue:high ... - 订阅者收到的
PUBLISH消息只是信号，不是载荷；真实数据始终落在 List 中
多个消费者共用同一组优先级队列时要注意
多个 worker 同时执行同一个 BRPOP queue:high queue:medium queue:low 0 是安全的，Redis 保证每次只有一个 client 能成功弹出元素。但要注意两点：
- 如果高优队列长期积压，低优任务可能永远得不到处理——这不是 bug，是设计使然。需要监控
LLEN queue:low，必要时降级或告警 -
BRPOP的 timeout 设为0时，client 会永久阻塞，对连接数和超时配置有要求；生产环境建议设为30秒并手动重连，避免连接僵死 - 别用
BLPOP替代BRPOP来“反向优先”——虽然语义上是从左往右，但实际行为一致，BLPOP只是出队方向相反，不影响优先级判定逻辑
真正容易被忽略的点是：Pub/Sub 的「瞬时性」和 List 的「可靠性」必须严格分层。混用时若把业务逻辑耦合进订阅回调，很容易在服务重启后丢消息——因为 Pub/Sub 不存历史，而 List 里的任务还在。
