nsq高可用必须分离部署nsqd与nsqlookupd，因单实例下消息易丢失、服务发现失效、无法扩容且监控失真；需显式指定地址、确保注册时序、严格约束命名。
nsqd 和 nsqlookupd 必须分离部署，否则无法实现真正的高可用——单点故障会直接导致整个消息链路中断。
为什么不能只跑一个 nsqd 实例？
NSQ 的可靠性不来自单个 nsqd 的持久化能力，而来自 topic → channel → 多 consumer 的扇出机制和节点冗余。单实例下：
– 消息仅在内存排队，进程崩溃即丢失（即使启用了 -mem-queue-size=0，磁盘队列也依赖进程存活）
– nsqlookupd 无法做服务发现，consumer 连接硬编码地址后失去故障转移能力
– 所有 consumer 都挤在一个 channel 上，无法横向扩容处理能力
– nsqadmin 监控面板显示的“1 node”状态会掩盖真实拓扑风险
nsqlookupd 启动时必须指定 -tcp-address 和 -http-address
默认绑定 0.0.0.0:4160 和 0.0.0.0:4161 看似省事，但在多网卡或容器环境中极易引发连接失败：
– consumer 调用 ConnectToNSQLookupd("127.0.0.1:4161") 会连不上实际监听在 192.168.x.x:4161 的实例
– nsqd 向 lookupd 发送心跳时若广播地址未对齐，会导致 lookupd 认为该 nsqd “离线”
– 正确做法是显式指定：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
nsqlookupd -tcp-address=192.168.1.10:4160 -http-address=192.168.1.10:4161
– 对应地，
nsqd 启动时必须配 -lookupd-tcp-address=192.168.1.10:4160 和 -broadcast-address=192.168.1.10Golang consumer 连接 nsqlookupd 前必须检查 nsqd 是否已注册
常见错误是 consumer 启动快于 nsqd 注册完成，导致 ConnectToNSQLookupd 成功但后续收不到消息：
– nsqd 启动后需约 15–30 秒才完成向 nsqlookupd 的首次心跳注册（受 -statsd-interval 和网络延迟影响）
– consumer 不应直接调用 ConnectToNSQLookupd 后就进入 select{}，而应轮询 GET /nodes 接口确认目标 topic 已出现在返回列表中
– 示例检查逻辑：
for { resp, _ := http.Get("http://192.168.1.10:4161/nodes") // 解析 JSON，检查 topics 数组是否含 "test_topic" if hasTopic(resp, "test_topic") { break } time.Sleep(2 * time.Second)}
– 否则 consumer 会静默“假连接”，日志无报错但消息永不抵达
channel 名称里不能含点号（.）或斜杠（/）
NSQ 内部用 . 分隔 topic.channel，用 / 构造 HTTP 路由路径。若 channel 名为 order.v1：
– nsqadmin 页面中该 channel 会显示为空白或 404
– nsq_to_file 工具无法正确匹配路由规则
– consumer 初始化时可能触发 invalid channel name 错误但不 panic，只默默跳过订阅
– 安全命名建议：仅使用字母、数字、下划线、短横线，如 order_v1 或 order-v1
– topic 同理，避免 user.profile，改用 user_profile
NSQ 的高可靠不是靠某个配置开关打开的，而是靠组件间地址对齐、注册时序可控、命名约束严格这三件事卡死。漏掉任意一环，系统看起来在跑，其实消息早就在某处静默丢弃了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
