RPOPLPUSH 是唯一能安全抢占 List 任务的原子操作，因其一步完成“从 source 弹出并推入 destination”，避免 LRPOP+LPUSH 组合导致的任务丢失、重复或空返回误判。
为什么 RPOPLPUSH 是唯一能安全抢占 List 任务的原子操作
因为 Redis 的 List 没有“带条件弹出并插入”的非原子替代方案。用 LRPOP + LPUSH 组合会丢失任务：消费者 A 弹出任务后崩溃，任务就彻底消失；而 RPOPLPUSH 一步完成“从 source 弹出、推入 destination”，中间无间隙，任务始终在某个 List 中。
常见错误现象：LRPOP 后没来得及 LPUSH 就断连，任务丢失；多个消费者同时 LRPOP 同一个 key，出现空返回却误判为“无任务”；重试逻辑把已处理任务重复塞回队列。
-
RPOPLPUSH是原子的，但 destination 必须是另一个 key（不能是自己），否则行为未定义 - 如果 destination 不存在，Redis 自动创建；如果 destination 是其他数据类型，命令报错
WRONGTYPE Operation against a key holding the wrong kind of value - 返回值是被转移的元素 —— 这是你唯一能拿到任务内容的地方，别忽略它
如何用 RPOPLPUSH 实现带超时的抢占式重试
单纯转移任务还不够：消费者拿走任务后可能卡住或崩溃，必须让任务在一定时间后自动回到就绪队列。靠客户端计时不可靠，要用 Redis 的过期机制配合结构设计。
使用场景：定时任务调度器、订单状态轮询、邮件重发队列。
- 不要给 destination List 设置
EXPIRE—— List 本身不支持过期，只能对整个 key 生效，而你还需要持续LPOP它 - 正确做法：把任务转到一个临时 List（如
task:processing:123），再用独立 key 记录它的过期时间（SET task:processing:123:ttl "300" EX 300） - 或者更轻量：用
RPOPLPUSH转移到一个带命名空间的 processing List，由后台守护进程定期扫描LRANGE+TTL判断是否超时，超时则LPUSH回原队列
RPOPLPUSH 在集群模式下的兼容性陷阱
Redis Cluster 要求所有涉及的 key 必须落在同一个 slot，否则直接报错 CROSSSLOT Keys in request don't hash to the same slot。而 RPOPLPUSH 涉及两个 key，极易踩中这个限制。
错误现象：单机跑得好好的，一上集群就抛 CROSSSLOT，日志里看不到明显原因。
- 解决方案只有两个：强制两个 key 哈希到同一 slot（用
{xxx}标签，例如RPOPLPUSH task:{123}:ready task:{123}:processing） - 或者改用单 key 结构：把“就绪”和“处理中”状态存在同一个 List 的不同区间，靠客户端逻辑区分 —— 但这丧失了原子性保障，不推荐
- 注意：Redis 7.0+ 的
MOVE命令仍不支持跨 slot，所以别指望靠它绕过
消费者怎么确认任务真正执行成功并清理
转移只是开始，最终要从 processing List 彻底删掉任务。但不能简单 LREM —— 如果多个消费者共用一个 processing List，LREM 可能误删别人正在处理的任务。
关键点在于：每个消费者必须拥有自己专属的 processing List，或用唯一标识绑定任务。
- 推荐方式：用消费者 ID 或进程 PID 作为 processing List 后缀，例如
task:processing:worker-abc123，这样LPOP后直接DEL整个 key 即可 - 如果必须共享 processing List，那就得在任务体里嵌入唯一 trace_id，并用 Lua 脚本做条件删除：
EVAL "if redis.call('LINDEX', KEYS[1], 0) == ARGV[1] then return redis.call('LPOP', KEYS[1]) else return nil end" 1 task:processing "trace-789" - 永远不要依赖客户端内存里的任务副本去匹配删除 —— 网络延迟、序列化差异都可能导致比对失败
最易被忽略的是：processing List 的生命周期管理。没人清理的 task:processing:xxx 会越积越多，且无法通过 KEYS 扫描（性能灾难），得靠命名规范 + 定期 SCAN + TTL 判断来回收。
