BRPOPLPUSH是唯一支持阻塞读取与原子性备份的命令，确保消息移出source后必入destination，避免丢失；需配合唯一ID、时间戳等字段实现可靠重试与清理。
BRPOPLPUSH 是 Redis 中唯一能同时完成「阻塞读取 + 原子性备份」的命令，它才是实现可靠消息队列（带 pending 重试能力）的实际核心——不是 BRPOP，也不是 RPOPLPUSH。
BRPOPLPUSH 的原子性到底保什么
它保证：只要客户端收到返回值，那个元素一定已从 source 列表移除，并且一定已推入 destination 列表。中间不会出现“取到了但没存进 pending”的空档。
这意味着：即使消费者进程在收到消息后立刻崩溃，这条消息仍完好存在于 pending 队列中，重启后可直接扫描重试。
常见错误现象：
- 用
BRPOP+LPUSH手动组合 —— 网络中断或进程崩溃时，消息可能已出队但未入 pending，永久丢失 - 把
timeout设为非零值（比如 5），而消费者处理耗时超过 5 秒，导致重复拉取同一条消息（因超时返回 null 后重试） -
destination和source用同一个 key —— 命令会成功但逻辑错乱，消息在原地打转
生产者和消费者必须约定的消息结构
BRPOPLPUSH 只搬运原始字节，不解析内容。要支持重试、ACK、去重，消息体里必须自带可识别字段：
- 全局唯一 ID（如 UUID 或雪花 ID），用于幂等判断和日志追踪
- 时间戳（
ts），便于监控延迟或清理超时 pending 消息 - 重试次数（
retry_count），防止死循环重试（例如限制最多 3 次）
示例消息格式（JSON 字符串）：{"id":"a1b2c3","ts":1725372000,"retry_count":0,"payload":"order_123"}
注意：Redis List 不校验 JSON 合法性，生产者必须确保序列化正确；消费者需做 try-catch 解析，失败则应主动 LREM 掉该 pending 消息并告警，避免卡住整个 pending 队列。
pending 队列怎么清理才算安全
消费者处理成功后，不能只靠「记得删」，必须用 LREM 显式删除对应消息，且要匹配完整内容（或至少匹配 id 字段）：
- 用
LREM pending_key 0 "完整消息字符串"—— 最精确，但要求字符串完全一致（含空格、顺序） - 更实用的是先用
LRANGE pending_key 0 -1扫描，提取所有id，再用LREM pending_key 1 "id:xxx"（需消息里 id 有固定前缀） - 严禁用
DEL pending_key清空 —— 会误删其他消费者尚未 ACK 的消息
性能提示：如果 pending 队列长期堆积，LRANGE 全量扫描会变慢。此时应改用 Sorted Set 存 pending（按 ts 排序），但那就超出 List 方案范畴了。
超时与连接中断的真实影响
BRPOPLPUSH source destination 0 中的 0 表示无限等待，但它挡不住网络层断连。实际部署中：
- TCP 连接空闲超时（如负载均衡器设为 60 秒）会导致命令提前中断，返回空结果 —— 消费者必须识别这种「伪超时」，不能当作消息处理失败
- 推荐加一层心跳检测，或使用连接池自动重连（如 Jedis 的
setTestOnBorrow(true)） - 若业务允许轻微延迟，可设
timeout=30，配合客户端重试逻辑，比死等更可控
最易被忽略的一点：BRPOPLPUSH 的 destination 列表是「追加写入」，但它的读取端（比如人工排查或监控脚本）如果用 LRANGE pending_key 0 -1，看到的是最新 pending 消息在末尾 —— 而不是最先入队的在开头。顺序和直觉相反，查问题时容易看错。
