nsq高可用依赖nsqd与nsqlookupd协同，nsqlookupd是强制服务发现组件；多nsqd未注册到nsqlookupd将成孤岛；消费者需配置多个lookupdhttpaddresses并合理设置maxinflight以平衡吞吐与延迟。
NSQ 不是靠“集群配置”来实现高可用的，而是靠多个独立 nsqd 实例 + nsqlookupd 服务发现协同工作。直接硬凑多台 nsqd 却不配 nsqlookupd，消费者根本找不到主题位置，消息会丢或卡死。
nsqlookupd 是服务发现的强制依赖，不是可选组件
很多新手启动了多个 nsqd，但只跑了一个 nsqlookupd，就以为“集群”建好了——其实只是多个孤岛。每个 nsqd 必须通过 --lookupd-tcp-address 主动注册到 nsqlookupd，否则它对外不可见。
-
nsqd启动时若未指定--lookupd-tcp-address，它不会广播自己，go-nsq消费者调用LookupdHTTPAddress也查不到该节点 - 一个
nsqlookupd可支撑上百个nsqd，但生产环境建议部署至少 2 个nsqlookupd（用不同端口或机器），避免单点故障 - 消费者初始化时必须传入
LookupdHTTPAddresses切片，不能只写一个地址；go-nsq 会轮询这些地址获取 topic→nsqd 映射
go-nsq Consumer 的 RDY 机制决定吞吐上限
消费者不是“连上就能狂收”，go-nsq 默认 RDY=1，意味着每次只允许 nsqd 发 1 条消息，等你调用 Finish() 或 Requeue() 后才发下一条——这在高并发场景下等于自缚手脚。
- 必须显式设置
config.MaxInFlight = 200（或更高），它控制 RDY 值上限，也影响内存占用 -
MaxInFlight不是越大越好：若消费者处理慢，大量消息堆积在内存中未确认，可能触发 nsqd 的mem-queue-size限制而落盘，延迟升高 - 真实压测中，
MaxInFlight=500+ 每条消息处理耗时
Topic 和 Channel 的误用会导致消息重复或丢失
Topic 是写入维度，Channel 是读取维度；一个 Topic 下多个 Channel 是“广播复制”，不是“分片”。搞混这个，微服务间消息语义就全乱了。
- 不要为每个微服务实例创建独立 Channel 名（如
"order_service_123"）：Channel 名是静态配置，动态生成会导致 nsqd 无法复用连接，且监控难追溯 - 正确做法：所有订单服务消费者订阅同一 Channel（如
"order_process"），靠 nsqd 内部负载均衡分发；需要隔离时，用不同 Topic（如"order_created"vs"order_paid"） - Channel 没有消费者时，消息会在内存排队（默认
mem-queue-size=10000），超限后写磁盘；但若整个 Channel 长期无人订阅，磁盘队列也不会自动清理，需手动调用DELETE /channel/...HTTP 接口
nsqd 启动参数直接影响微服务稳定性
本地测试用默认参数能跑通，一上生产就抖动——大概率是 nsqd 的磁盘和内存策略没对齐业务节奏。
-
--mem-queue-size=50000：提高内存队列容量，减少落盘频率；但别设太高，否则 OOM 风险上升 -
--max-body-size=8MB：默认 5MB，若微服务间传结构化日志或小文件，必须调大，否则Producer.Publish()直接返回"E_BAD_BODY" -
--msg-timeout=60s：消息最大处理时间，必须 ≥ 消费者最慢业务路径耗时，否则未 Finish 的消息会被 nsqd 自动 requeue，造成重复消费 - 务必加
--broadcast-address：容器或云环境里，nsqd自动上报的 IP 往往是内网 Docker 网桥地址，外部消费者根本连不上
真正卡住 NSQ 集群性能的，往往不是代码逻辑，而是 nsqd 落盘时机、go-nsq 的 RDY 控制粒度、以及 nsqlookupd 地址列表是否被消费者正确加载——这些细节在日志里不报错，但会让吞吐量掉一半以上。
