RPOP 直接取值会导致消息丢失，因其无状态跟踪机制；BRPOPLPUSH 通过原子性“取出+暂存”到 Pending List 弥合缺口，但需手动清理超时项，而 Stream 原生支持 ACK、重试与元数据管理。
为什么 RPOP 直接取值会导致消息丢失
消费者用 RPOP 从 List 取出消息后，消息就从队列里彻底删除了。如果此时业务逻辑刚解析完消息、还没来得及处理，进程就因异常退出或机器宕机，这条消息就永远消失了——Redis 不知道它被“读过但没做完”。这不是 Redis 的 bug，而是 List 本身不带状态跟踪机制。
BRPOPLPUSH 怎么补上这道缺口
它把“取出”和“暂存”合并成一个原子操作：从源 List 取出一条消息，同时推入另一个 Pending List（比如 queue:task:pending），整个过程不可中断。消费者拿到消息后，处理成功再手动 LREM 或 LPOP 清掉 Pending 中的对应项；失败或崩溃后，重启时直接扫 queue:task:pending 重试即可。
- 必须用
BRPOPLPUSH，不能拆成RPOP+LPUSH，否则中间存在竞态窗口 - Pending List 的 key 名要有业务含义，避免多个消费者混用同一个 pending key 导致互相干扰
- 需要额外定时任务或看门狗机制清理长期卡在 pending 里的消息（比如超时 5 分钟未确认）
- 注意
BRPOPLPUSH的 timeout 参数，设为 0 表示无限阻塞，生产环境建议设具体值（如 30）防止单点卡死
什么时候该直接换 Stream
当你的场景开始出现这些信号，说明 List + BRPOPLPUSH 已经在强行缝合了：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 需要多个消费者协同处理同一组消息（比如按用户 ID 分片），List 只能靠自己轮询分发，容易重复或漏
- 要求消息处理后自动标记 ACK，而不是靠人工清 Pending 列表
- 想查某条消息是否被谁消费过、消费到哪一步了，List 没有内置元数据支持
- 消息积压后要跳过前 N 条重放，List 只能
LRANGE扫全部，性能随长度下降
Stream 原生支持 XREADGROUP、XACK、XCLAIM，能把“谁在处理哪条”“处理到哪了”“失败后怎么捞回来”全交给 Redis 管理。迁移成本主要在客户端适配，不是数据结构替换。
最容易被忽略的细节
即使用了 BRPOPLPUSH，Pending List 本身没有过期时间，也不自动清理。如果消费者处理逻辑里忘了调 LREM，或者 ACK 步骤抛异常没兜住，Pending List 就会越攒越多，最后吃光内存。别指望靠 TTL 解决——List 不支持对整个 key 设置过期，只能靠业务层主动维护生命周期。
