17370845950

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() 包裹）

消费端如何做到“处理一次，仅一次”（幂等不是可选项）

消息可能重复（网络重传）、乱序（多消费者实例）、延迟（几秒到几分钟），消费者逻辑若没幂等，同一笔订单扣两次库存、发两封邮件就是常态。

• 用业务唯一键去重：比如 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 模式或本地消息表补救；想靠发个消息就解决分布式事务，迟早掉坑里。