Golang实现Redis消息队列教程

本文深入剖析了在Golang中基于Redis实现可靠消息队列的关键陷阱与最佳实践：裸用BRPop极易导致消息丢失、重复消费和goroutine卡死，必须通过设置超时context、封装结构化消费者逻辑及统一错误处理来筑牢基础；真正符合FIFO语义的是BLPop+RPush组合，而非直觉上的BRPop；利用SETNX配合TTL可轻量级实现幂等去重；延迟任务须依赖Lua脚本原子迁移ZSet到List，杜绝竞态；同时强调context生命周期管理与redis.Client复用等易被忽视的生产级细节——每一步优化都直击线上稳定性痛点，帮你从“能跑通”迈向“扛得住”。

直接用 LPush + BRPop 能跑通，但线上扛不住——消息丢、重复消费、goroutine 卡死是大概率事件。必须加超时、封装结构体、统一错误处理，哪怕只做这三件事。

为什么裸调 BRPop 会丢消息

消费者拿到 BRPop 返回的 []string 后，若在反序列化或业务处理中 panic，进程退出，这条消息就永远消失了。Redis 不知道你没处理完，也不会重发。

• BRPop 只负责“弹出”，不负责“确认”，它不是 ACK 模型
• 返回值是 [key_name, payload]，写成 result[0] 就取错，静默失败
• 没设 context.WithTimeout，网络卡住或处理慢，goroutine 无限挂起
• 没做连接健康检查，rdb.Ping(ctx).Err() 成功不代表 BRPop 可用，得额外测 rdb.LLen(ctx, queueName)

BLPop + RPush 才是 FIFO 的安全组合

别被名字误导：BRPop 是从右端弹出，但如果你生产者用 RPush（尾插），那最新入队的反而最先被取——这不是队列，是栈。真正 FIFO 要靠 BLPop（左端弹出）+ RPush（尾插）。

• 生产者统一用 RPush，保证入队顺序；消费者用 BLPop，保证按插入顺序取出
• BLPop 和 BRPop 在 go-redis/v8 中函数签名完全一样，不能靠名字猜行为，得看文档确认弹出端
• 队列名建议加业务前缀，比如 order:pending，避免不同服务误监听同一 key
• 消息体必须含唯一 ID 字段，后续去重、日志追踪、幂等判断全靠它

怎么用最少代码防重复消费

不需要引入分布式锁或外部存储，Redis 自带 SETNX 就够用。核心是：消费前先尝试设一个带过期时间的标记，成功才处理，失败就跳过。

• 用 rdb.SetNX(ctx, "processed:"+msg.ID, "1", 24*time.Hour) 做轻量去重
• 必须设 TTL，否则崩溃后标记永久残留，导致漏消费
• 不要在处理完成后才写标记——万一写标记前 crash，还是重复
• 这个机制只能防“同一消息被多个 worker 同时取到”，不能替代消息重试逻辑

延迟任务别轮询 ZSet，用 Lua 迁移才安全

想让消息 5 秒后执行？List 不支持延迟。ZSet 存时间戳是标准做法，但迁移动作必须原子——否则多 worker 同时扫 ZSet，同一条消息可能被迁移到 List 两次。

• 迁移脚本必须用 Lua，通过 EVAL 提交，利用 Redis 单线程执行保障原子性
• 脚本内用 zrangebyscore ... WITHSCORES LIMIT 0 100 控制单次迁移数量，防大 key 阻塞
• score 必须用 redis.call("time") 取服务端时间，客户端时间不可信
• 迁移和消费要拆开：单独起一个调度协程跑 Lua，主消费者只从普通 List 拿，职责分离

最易被忽略的是 context 生命周期和 client 复用——每个 BRPop 调用都要带超时 context.Context，全局复用一个 *redis.Client 实例，但测试时记得 defer client.Close()，不然连接池会泄漏。

今天带大家了解了的相关知识，希望对你有所帮助；关于Golang的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~