nsq 是轻量级消息队列，启动简单、无需依赖组件，适合日志分发等场景；本地开发需正确配置 --broadcast-address 和 --lookupd-tcp-address 避免注册失败；deferredpublish 基于内存延迟队列，不支持持久化与重复定时；消费者应按部署模型选直连 nsqd 或通过 nsqlookupd 发现服务。

nsqd 启动就跑，go-nsq 两行代码就能发收消息——NSQ 不需要 ZooKeeper、不依赖数据库、没鉴权层，真就是“二进制扔上去，TCP 连上就干活”。它不适合强顺序、跨集群复制或金融级事务，但对日志分发、订单异步通知、事件广播这类场景，够用、快、稳。

怎么启动 nsqd 和 nsqlookupd 才不踩坑

本地开发时最常犯的错是 nsqd 没正确注册到 nsqlookupd，导致消费者连不上 Topic。关键不是端口通不通，而是广播地址是否可被其他节点解析。

• nsqlookupd 只需执行一条命令：nsqlookupd（默认监听 127.0.0.1:4160）
• nsqd 必须显式指定 --lookupd-tcp-address 和 --broadcast-address：nsqd --lookupd-tcp-address=127.0.0.1:4160 --broadcast-address=127.0.0.1
• --broadcast-address 不能写 localhost 或留空——Docker 容器里会解析成容器内网 IP，外部 Go 程序连不上；必须填宿主机能路由到的地址，比如 192.168.1.100 或 host.docker.internal（macOS/Windows）
• 如果只跑单机、不走服务发现，可以直接跳过 nsqlookupd，让生产者/消费者直连 nsqd 的 4150 端口，此时 ConnectToNSQD 就够用

go-nsq 生产者：Publish 和 DeferredPublish 的实际区别

Publish 是立即投递，DeferredPublish 是延迟投递，但它们底层走的是完全不同的命令路径：PUB vs DPUB。这不是客户端 sleep 后再发，而是 nsqd 在内存中维护一个最小堆优先级队列，到期才把消息注入 Topic 队列。

Go语言（Golang）1.26.0

Go语言（Golang）1.26.0版本官方下载，版本号 1.26.0，适合旧项目维护、兼容性测试和指定版本开发环境搭建。

下载

• DeferredPublish 的 delay 参数单位是 time.Duration，但最终会被转成毫秒传给服务端；超过约 49 天（int32 最大值）会溢出，变成负延迟 → 消息立刻投递
• 延迟消息不支持重试语义：一旦 DPUB 发送成功，就进入调度队列；若 nsqd 崩溃，未触发的延迟消息会丢失（因为只存在内存中，除非开启 --mem-queue-size=0 强制落盘，但性能下降明显）
• 不要用 DeferredPublish 实现“定时任务”：它没有 cron 表达式、不支持重复触发、也不保证准时（误差在几十毫秒级），只适合“N 秒后发一次”的简单场景，比如订单 30 分钟未支付自动关闭

消费者连接模式选 ConnectToNSQD 还是 ConnectToNSQLookupd？

选哪个，取决于你是否要动态扩缩容或容忍单点故障。不是“高级功能才用 lookupd”，而是部署模型决定的。

• 直连 nsqd（ConnectToNSQD）：适合单机调试、CI 测试、或固定节点数的边缘服务。优点是链路短、无额外依赖；缺点是消费者硬编码了 nsqd 地址，加机器得改配置、重启
• 通过 nsqlookupd 发现（ConnectToNSQLookupd）：消费者只连 4161 HTTP 接口查 Topic 路由，nsqd 自动心跳上报。哪怕你启 10 个 nsqd 实例，消费者完全无感；挂掉一个，nsqlookupd 几秒后就剔除，流量自动切走
• MaxInFlight 必须设：默认是 1，意味着同一时间最多处理 1 条消息。高吞吐场景下不调这个值，消费者会卡死——它本质是 TCP 窗口大小 + 内存缓冲上限，建议从 25 开始压测调整
• Channel 名不能含 .、/、 等特殊字符，否则 nsqd 会拒绝创建；Topic 名同理，但更宽松些

为什么消息看起来“丢了”？三个最隐蔽的原因

NSQ 默认“至少一次”投递，但丢消息往往不是 bug，而是配置或使用方式没对上。

• nsqd 进程被 kill -9：内存中未刷盘的消息（包括 mem-queue 里的、延迟队列里的、channel 里待分发的）全丢；必须用 kill -15 让它优雅退出，触发 flush
• 消费者没调 msg.Finish()：NSQ 不像 Kafka 那样靠 offset 提交，而是靠显式 Finish/Requeue。忘了 Finish，消息会在 message-timeout（默认 60s）后自动重入 channel，看起来像“重复消费”，其实是“没确认”
• Topic/Channel 名大小写不一致：Go 客户端传 "order"，但 nsqadmin 里看到的是 "Order" ——NSQ 对名字是大小写敏感的，连错名字就等于连了另一个空 Topic

NSQ 的轻量，是拿某些能力换来的：它不保证全局顺序、不做跨节点复制、不内置鉴权。用之前先想清楚——你要的到底是“消息管道”，还是“分布式事务协调器”。前者它做得干净利落，后者请换别的轮子。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！