Golang微服务异步通信首选NATS JetStream，因其轻量、Go原生友好且开箱支持持久化；次选RabbitMQ，具备强ACK、死信队列和灵活路由；Kafka仅用于事件回放或对接大数据场景；避免用Redis Streams作核心消息通道，因其不保证At-Least-Once投递。
直接说结论：Golang微服务异步通信，首选 NATS JetStream（轻量、Go原生友好、开箱持久化），次选 RabbitMQ（强ACK+死信+路由灵活），Kafka 仅当需要事件回放或对接大数据栈时才上；别用纯 Redis Streams 做核心业务消息通道，它不保证 At-Least-Once 投递。
为什么不用 HTTP 调用而必须上消息队列
HTTP 调用是同步阻塞的——订单服务调库存服务，库存一卡，订单接口就超时。而消息队列把“我做了”变成“我发了”，下游处理慢、宕机、升级，都不影响上游返回成功。这不只是性能问题，更是系统韧性的分水岭。
- 削峰：秒杀流量打进来，先写入
orders.created主题，库存服务按自身吞吐能力慢慢消费，不会被瞬时压垮 - 解耦：订单服务完全不知道风控、积分、物流是谁在跑，只管发
OrderCreatedEvent；新增一个审计服务？加个订阅就行，零代码改订单服务 - 失败隔离：库存扣减失败，消息可重试或进死信队列；HTTP 调用失败，你得自己实现重试+幂等+状态补偿，容易漏
生产端怎么发才不丢消息（常见错误：fire-and-forget 后连日志都没）
很多人写完 js.Publish("order.created", data) 就以为完事了，但网络抖动、JetStream 拒绝、序列化失败都会静默失败。真正可靠的发送必须带错误分支和兜底。
- 永远检查
err：NATS JetStream 的Publish()返回error，不是 nil 就代表没发出去，必须记录log.Error("failed to publish order.created", "err", err) - 本地暂存兜底：对关键事件（如支付成功），失败时写入本地
pending_events表，由后台 goroutine 定期扫描重发（注意加唯一索引防重复） - 别在 HTTP handler 里同步等确认：用户下单接口响应时间要 go publisher.Publish(...) 异步，且确保 goroutine panic 不崩主流程（用
recover()包裹）
消费端如何做到“处理一次，仅一次”（幂等不是可选项）
消息可能重复（网络重传）、乱序（多消费者实例）、延迟（几秒到几分钟），消费者逻辑若没幂等，同一笔订单扣两次库存、发两封邮件就是常态。
立即学习“go语言免费学习笔记（深入）”；
- 用业务唯一键去重：比如
order_id，处理前查 DB：SELECT COUNT(*) FROM inventory_locks WHERE order_id = ?，存在则直接Ack()跳过 - Redis SETNX 是快捷方案：但必须带
EX 300（5分钟过期），否则 Redis 故障会导致永久锁死；别用无过期时间的 key - ACK 必须在业务逻辑**完全成功后**才调：RabbitMQ 的
msg.Ack(false)或 NATS 的msg.Ack()写在数据库 commit 之后，不能提前 - 失败重试要可控：NATS JetStream 设置
max_deliver = 5，第 6 次自动进$JS.API.CONSUMER.MSG.NAK死信流；别让消息无限重试占满内存
消息契约怎么定义才不翻车（JSON 结构体比字符串强十倍）
用 map[string]interface{} 解析 JSON 是自找麻烦——字段名拼错、类型错（"total": "99.9" 字符串 vs float64）、缺字段全靠 runtime panic 报错。
- 强制定义 Go struct：
type OrderCreatedEvent struct { OrderID string `json:"order_id"` UserID int64 `json:"user_id"` Total float64 `json:"total"` Timestamp int64 `json:"timestamp"` Version string `json:"version"` // 必加，v1 → v2 升级时兼容 } - 消费时用
json.Unmarshal(data, &event)+ 显式错误检查，失败就Nack()进重试队列，别让脏数据污染下游 - 主题名带版本：
events.order.created.v1，别用order_created这种裸名；升级时发 v2，老消费者继续读 v1，新消费者读 v2，平滑过渡
最容易被忽略的一点：消息队列不是万能胶布。如果两个服务间有强事务语义（比如转账必须同时更新 A 账户扣款+B 账户入账），消息队列只能做最终一致性，得靠 Saga 模式或本地消息表补救；想靠发个消息就解决分布式事务，迟早掉坑里。
