Golang如何用NATS消息系统_Golang NATS教程【指南】

Golang NATS 客户端配置：从“能跑”到“稳如磐石”的关键几步

直接调用 nats.Connect(nats.DefaultURL)，在本地开发环境跑通测试，感觉一切良好。但一旦部署到生产环境，问题就接踵而至：连接动不动就断且不恢复、消息顺序错乱、消费者收不到历史数据。先别急着怀疑NATS服务端，很多时候，问题的根源在于客户端配置与NATS服务端的核心能力没有对齐。

怎么连上 NATS 服务器又不被网络抖动搞崩

默认的连接配置其实相当“脆弱”：它不重试、不设超时、也不做健康检查。这意味着任何一次轻微的网络波动，都可能导致连接卡死或静默断开，而客户端却毫无察觉。要让连接具备韧性，必须显式地配置一系列策略：

• nats.MaxReconnects(60)：这里有个关键点，避免使用-1（无限重连）。无限重连在服务端临时故障时，会形成海量的重连请求，反而可能压垮正在恢复的服务端。
• nats.ReconnectWait(2 * time.Second)：设置固定的重连等待间隔是基础，但略显生硬。
• nats.ReconnectJitter(100*time.Millisecond, time.Second)：这才是点睛之笔。为重连间隔增加一个随机抖动，可以有效避免所有客户端实例在同一时刻发起重连，从而平滑请求压力。
• 凭证安全：切勿将密码直接写在连接URL中。更专业的做法是使用 nats.UserCredentials(“user.creds”) 来加载独立的凭证文件。
• TLS陷阱：如果服务端启用了TLS，连接URL必须使用 tls:// 前缀，并且服务端的证书链必须受客户端信任。否则，Connect() 调用可能会阻塞而不返回明确的错误，给排查带来很大困扰。

JetStream 初始化必须在启动阶段完成，不能等 publish 时才触发

很多开发者第一次调用 js.Publish() 时遇到panic，会下意识检查消息体格式。但其实，更常见的原因是 jetstream.Context 根本没有被正确初始化。NATS客户端库不会自动为你准备JetStream上下文。

• 立即初始化：在NATS连接（nc）建立成功后，应立即执行 js, err := jetstream.New(nc)，并务必检查错误。
• 健康检查：一个良好的实践是，在应用启动阶段调用一次 js.AccountInfo()。这不仅能确认JetStream上下文可用，还能提前发现权限或账户配置问题，避免运行时才出错。
• 流非热更新：需要明确的是，流（Stream）的创建是一次性操作。后续如果需要修改流的配置（如主题匹配规则、保留策略），通常需要删除旧流后重新创建，而不是动态热更新。

消息“不丢”不是默认行为，得靠 JetStream + 正确的 Stream 配置

核心认知需要厘清：纯NATS Core协议是基于内存的发布订阅，消息在路由后如果没有在线消费者，就会被直接丢弃——这是其追求极致性能的设计哲学，而非缺陷。要实现消息的持久化与至少一次投递，必须依赖JetStream，并且以下三件事缺一不可：

立即学习“go语言免费学习笔记（深入）”；

• 显式创建流：仅仅建立JetStream上下文（js）是不够的，必须调用 js.AddStream() 来显式定义一个流，并指定它监听的Subject（主题）。
• 选对保留策略：流的 RetentionPolicy 至关重要。例如，jetstream.InterestPolicy 只保留当前仍有活跃消费者关注的消息；而 jetstream.WorkQueuePolicy 则确保每条消息只被投递给一个消费者一次，适用于任务队列场景。
• 订阅策略决定起点：创建消费者订阅时，默认行为是从此刻开始接收新消息，历史消息会被跳过。如果需要从头消费，必须指定 nats.DeliverPolicy(nats.DeliverAll)。
• 记住消费位置：对于持久化消费者，必须使用 nats.Durable(“processor-name”) 选项赋予一个唯一的名称。这样，JetStream才能跟踪其消费进度（ACK位置）。否则，每次启动都会被视为一个全新的消费者，从而可能重复消费或丢失位置。

去重和顺序不是 JetStream 自动保证的，关键控制权在客户端手里

另一个常见的误解是：开启了JetStream就等于获得了天然的幂等性和全局顺序保证。实际上，重复扣款、状态处理乱序等问题，往往是因为消息发布没有遵循规范。

• 去重关键在MsgID：JetStream的消息去重功能要生效，发布消息时必须携带 nats.WithMsgID(“order-12345”) 选项。这里的ID必须是业务上的唯一标识符（例如订单ID、支付流水号），使用随机UUID是无效的，因为每次重试都会生成新的ID，无法去重。
• 理解去重窗口：在流配置中设置的 Duplicates: 2*time.Minute，表示JetStream会记住最近2分钟内出现过的MsgID。这只是一个时间窗口，如果某条消息的处理时间超过了2分钟，其间重发的具有相同MsgID的消息仍会被视为新消息。
• 发布顺序性：多个goroutine并发调用 js.Publish() 向同一个Subject发送消息，并不能保证消息在流中的存储顺序与发送顺序完全一致。对于顺序敏感的业务，应在客户端层面控制串行发布，例如使用单个goroutine配合Channel进行缓冲和发送。
• 最终保证在消费端：NATS JetStream提供的是“至少一次（at-least-once）”投递语义。这意味着在极端情况下，重复投递是可能的。因此，消费者端必须实现业务层的幂等处理，例如通过数据库唯一索引、或使用Redis的SETNX命令来拦截重复处理。

最容易忽略的一点是：JetStream的可靠性是一个整体工程。流的定义、消息的发布方式、消费者的订阅策略，这三者必须严格对齐设计。任何一个环节的参数配置不当，其表现可能就是“消息莫名丢失”或“不该重复的重复了”，而系统日志里往往找不到任何直接错误，排查起来异常困难。