RPOP后崩溃会导致消息永久丢失，因其“读即删”特性：消息被取出即从List中彻底删除，而Redis无状态跟踪、无ACK机制，消费者崩溃后无法重试或回滚。
Redis List 本身不丢消息，LPUSH 和 RPOP 也不会主动删数据——丢消息的根源在于「业务逻辑没兜住」+「操作非原子」+「无状态跟踪」这三者叠加，在高并发下被迅速放大。
为什么RPOP后崩溃会导致消息永久丢失
因为 RPOP 是“读即删”：它返回元素的同时，该元素就从 List 中彻底消失了。如果消费者拿到返回值后、还没开始处理就 panic / kill / 网络中断 / 写 DB 失败，这条消息就再无踪迹。Redis 不知道它曾被谁取走、是否完成、是否该重发——List 没有 ACK、没有 pending 状态、没有重试队列。
-
RPOP返回的是值，不是引用；返回后 Redis 就不管了 - 没有超时自动回滚机制，也不支持事务回滚（即使包在
EXEC里，RPOP已执行完） - 单靠应用层 try-catch 无法覆盖进程级崩溃（如 OOM Kill、SIGKILL）
为什么多个消费者同时 RPOP 会漏判或空转
高并发下多个客户端几乎同时对同一个 List 执行 RPOP，最后一个执行的必然拿到 nil。但很多代码把 nil 当作“队列空”，直接跳过或退出循环，而不是继续等待新消息——这既造成漏处理（若刚有新 LPUSH 还没来得及被轮到），也引发 CPU 空转或休眠延迟问题。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 单纯用
LLEN+RPOP判断仍存在竞态窗口：LLEN返回长度 > 0 后，另一客户端抢先RPOP成功，当前客户端再RPOP就是nil - 用
BRPOP可避免空转，但它只解决“等待”问题，不解决“取到后崩溃即丢失”的核心缺陷 - 集群环境下，
BRPOP若超时断连又未做重连+续读，也会漏掉刚好在断连瞬间入队的消息
为什么不用 BRPOPLPUSH 就很难补救
真正能堵住“取到即丢”这个缺口的，只有原子性转移命令：BRPOPLPUSH 或 RPOPLPUSH。它们把“取出”和“暂存”压进一个不可分割的操作里，确保任务始终落在某个 List 中（就绪 or 处理中），哪怕消费者当场死机，重启后也能从 pending List 捞回来重试。
- 千万别拆成
RPOP+LPUSH：中间任意一步失败，任务就蒸发 -
BRPOPLPUSH的 timeout 参数别设 0，生产环境建议 10–30 秒，防止单点卡死阻塞整个消费线程 - pending List 的 key 必须带业务隔离前缀（如
queue:order:pending:{shard}），否则多消费者混用会互相覆盖或误删 - Redis Cluster 下必须用
{xxx}标签保证 source 和 destination 落在同一 slot，否则报CROSSSLOT
最常被忽略的一点：即使上了 BRPOPLPUSH，pending List 本身不带 TTL，也不自动清理。一旦消费者 ACK 步骤异常（比如 LREM 报错、网络超时、逻辑 bug），pending 里的任务就会永远堆积——这不是丢消息，而是让消息“卡住不动”，等同于业务侧不可见的丢失。
