Redis Streams 是 Go 中最实用的轻量级分布式队列方案：支持消费者组、ACK、水平扩展；需注意 XADD 限长、XGROUP 预创建、XCLAIM 处理 pending 消息。
用 Redis Streams 做轻量级分布式队列最实际
Go 里没有开箱即用的“分布式队列”标准库，硬造一个 TCP 协议 + 存储 + 调度的轮子既难维护又容易出错。生产中真正跑得稳的，往往是复用成熟中间件——Redis Streams 就是当前最匹配 Go 生态的选择：原子性好、支持消费者组（consumer group）、有消息确认（ACK）、天然支持多实例水平扩展。
关键不是“能不能”，而是“怎么避免踩坑”：
-
XADD时别手抖写成XADD key * field value——*是自增 ID，但若并发高且没设MAXLEN，内存会持续涨；建议加~ MAXLEN 10000限长 - 用
XREADGROUP拉消息时，必须先XGROUP CREATE创建组，否则报错NOGROUP No such key 'xxx' or consumer group - 消费者处理失败后，别直接丢弃消息；用
XCLAIM把 pending 消息抢过来重试，否则它会一直卡在PENDINGS状态，导致堆积
为什么不用 RabbitMQ 官方 Go 客户端？
Go 的 streadway/amqp 库功能全，但对分布式语义支持弱：它默认不保证消息只被一个消费者处理（需手动设 autoAck=false + channel.Qos），且连接断开后未 ACK 消息的恢复逻辑要自己补全。更麻烦的是，RabbitMQ 的集群模式（如镜像队列）和 Go worker 的生命周期很难对齐——比如 worker 重启时，旧 channel 可能还在 hold 着 unack 消息，新 worker 拉不到活。
除非你已有 RabbitMQ 运维团队、且业务强依赖 AMQP 协议（比如要和 Python/Java 服务共用 exchange），否则在纯 Go 项目里，为它引入额外的运维复杂度和故障面并不划算。
etcd + Watch 实现简单任务分发可行吗？
可以，但只适合低频、非严格顺序、允许重复执行的场景，比如“触发一次配置热更新”或“广播清理缓存”。etcd 本身不是消息队列，它没有消息回溯、没有消费位点管理、没有重试语义。常见翻车点：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 多个 worker 同时
Watch同一 key，收到相同事件后都执行一遍——这不是“负载均衡”，是“重复执行” - worker crash 后，期间错过的 watch 事件完全丢失，
etcd不保存历史 - 想模拟 ACK？得靠自己写
Put一个done_key，再加 TTL 清理，这已经是在重复造轮子了
真要用 etcd 做分发，至少配合一个中心化调度器（比如用 leader election 选出唯一 sender），否则不如直接上 Redis Streams。
自研基于 gRPC 的队列框架风险在哪？
见过几个团队用 gRPC + SQLite 或 BadgerDB 自建队列，初衷是“可控、无外部依赖”。结果上线后暴露三个硬伤：
- 消息投递可靠性难保障：gRPC 流式调用中途断连，server 端已写 DB、client 端却没收到响应，变成“幽灵消息”
- 横向扩缩容卡在存储层：SQLite 不支持并发写，BadgerDB 的
View和Write冲突频繁，压测时 QPS 上不去 - 运维黑洞：没监控消息积压、没告警消费延迟、没工具查某条消息卡在哪——最后全靠
ssh进机器sqlite3 queue.db "select * from messages"手动排查
分布式队列的难点从来不在“怎么把字节发出去”，而在于“怎么让每条消息在各种异常下都有确定性状态”。这个状态机设计，比网络协议本身重得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
