Redis在Go中做消息队列的关键是用对命令、选对模式、避开阻塞陷阱：推荐BLPop+RPush实现FIFO队列，避免轮询；需保障超时控制、错误重试、消息去重与崩溃恢复闭环。
Redis 在 Go 里做消息队列，不是“能不能”，而是“用对命令、选对模式、避开阻塞陷阱”——否则看似跑通，上线后丢消息、乱序、CPU 狂飙。
用 LPush + BRPop 做最简可靠队列
这是生产环境最常用、也最不容易翻车的组合：生产者往列表尾部推（RPush），消费者从头部阻塞取（BRPop），天然 FIFO。别用 LPop 轮询，那等于自己写 busy-wait，白耗 CPU。
-
BRPop的第一个参数是超时时间，设为0表示永久阻塞；设为1 * time.Second可配合健康检查或 graceful shutdown - 返回值是
[]string，结构固定为[queue_name, value]，直接取result[1]，别用result[0]当消息 - 如果队列名带业务前缀（比如
order:pending），务必统一加命名空间，避免不同服务误消费
BLPop 和 BRPop 到底该用哪个？
取决于你希望“谁先来谁先得”还是“谁最后加谁最先被取”。BLPop 从左端弹出（即最早入队的），BRPop 从右端弹出（即最新入队的）——但注意：只要生产者统一用 RPush（尾插），BLPop 就是严格 FIFO；若生产者混用 LPush 和 RPush，顺序就不可控了。
- 绝大多数场景用
BLPop+RPush组合，语义清晰、顺序可预期 -
BRPop更适合实现“栈式任务”（比如撤销操作、最近优先处理），不是典型队列需求 - Go 客户端
go-redis/v8中两个函数签名一致，别靠名字猜行为，看文档或源码确认弹出端
为什么 Ping 成功不代表队列能用？
连接通 ≠ 队列逻辑稳。常见掉坑点：Redis 默认不持久化，进程挂了队列数据全丢；没设 timeout 导致消费者卡死在 BRPop；并发启多个消费者却没做幂等，同一消息被重复处理。
- 初始化 client 后，一定要跑一次
rdb.Ping(ctx).Err()，但更要加rdb.LLen(ctx, "test_queue").Val()测试列表命令可用 - 消费者必须用
context.WithTimeout包裹整个处理流程，防止某条消息卡住导致后续全堵住 - 消息体建议含唯一 ID（如
uuid），消费前先查SETNX processed:，失败则跳过，这是最轻量的去重保障
延迟消息？别硬轮询 ZSet，用 zrangebyscore + 定时迁移
Redis 本身没原生延迟队列，但用 ZSet 存时间戳当 score 是业界共识。关键不在存，而在“怎么安全地捞出来”——不能让所有 worker 同时扫全量 ZSet，也不能用 zpopbyscore（非原子，可能漏或重复）。
- 推荐做法：单独起一个「调度协程」，每 100ms 执行一次
ZRangeByScore(..., &redis.ZRangeBy{Min: "-inf", Max: fmt.Sprintf("%d", time.Now().Unix())}) - 捞到的消息用
ZRem删除，再RPush到普通队列，由主消费者处理——两步分离，避免竞争 - 注意时钟漂移：所有服务用 NTP 同步时间，score 用 Unix 秒级足够，毫秒级反而增加 ZSet 压力
真正难的从来不是 push 和 pop 这两行代码，而是超时控制、错误重试、消息去重、崩溃恢复这四件事有没有闭环。少一个，上线后就是凌晨三点的告警电话。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
