nsq需按角色拆分部署，由nsqd、nsqlookupd和nsqadmin组成；生产者直连nsqd，消费者应连nsqlookupd实现服务发现；topic+channel决定广播或负载均衡行为；maxinflight影响吞吐与可靠性；须关注nsqd内存/磁盘队列水位防丢消息。
NSQ不是“接入”，而是按角色拆分部署
NSQ本身不提供“一键集成SDK”式的消息中间件能力，它由 nsqd（消息代理）、nsqlookupd（服务发现）和可选的 nsqadmin（UI）三个独立进程组成。微服务中引入NSQ，本质是让每个服务明确自己是生产者、消费者，还是两者兼有，并分别连接对应组件。
- 生产者只需直连
nsqd（如"127.0.0.1:4150"），不需要nsqlookupd - 消费者通常应连接
nsqlookupd（如"127.0.0.1:4161"），靠它自动发现所有已注册的nsqd实例，实现拓扑解耦 - 若只跑单机开发环境，可跳过
nsqlookupd，让消费者也直连nsqd，但线上必须启用nsqlookupd否则无法水平扩展
Topic 和 Channel 的命名不是随意的，它决定广播/负载均衡行为
NSQ 的广播能力完全依赖于 Topic + Channel 的组合逻辑：同一 Topic 下，不同 Channel 名称代表独立消费队列；同一 Channel 名称下，多个消费者实例自动负载均衡（非广播）。
- 要实现“一个消息被多个服务实例同时收到”，每个服务需用**不同 Channel 名**订阅同一个 Topic，例如：
"order_topic"+"sms_channel"、"email_channel"、"log_channel" - 要实现“多个 worker 协同消费同一类任务”，所有 worker 必须用**相同 Channel 名**，例如：
"payment_process"+"worker_channel"，NSQ 会自动轮询分发 - Channel 名不能含点号（
.）、斜杠（/）等特殊字符，否则nsqd会拒绝创建
go-nsq 客户端的 MaxInFlight 配置直接影响吞吐与可靠性
MaxInFlight 是消费者端最关键的性能参数，它控制“最多有多少条消息处于“已发送但未 finish/req/requeue”状态”。设得过大，可能压垮下游处理逻辑；设得太小，又浪费并发能力。
- 默认值是 1，意味着串行消费 —— 安全但极慢
- 设为 100 时，客户端最多缓存 100 条待响应消息；若某条消息处理超时或 panic，NSQ 会重发，但重发前会等待
msg.RequeueDelay（默认 90s） - 真实场景建议从 20–50 开始调优，配合业务平均处理时长评估：比如平均耗时 200ms，设 50 可维持约 250 QPS 持续吞吐
- 注意：该值是 per-consumer 实例生效，不是全局；多个 consumer 实例各自维护自己的
MaxInFlight窗口
别忽略 nsqd 的磁盘队列阈值，否则内存爆掉就静默丢消息
nsqd 默认在内存中缓存消息，当内存满（默认 --mem-queue-size=10000 条）后，会把新消息写入磁盘队列。但磁盘队列也有上限（--disk-queue-max-writes-per-fsync 等参数影响刷盘节奏），一旦磁盘也满，nsqd 就会开始**拒绝新消息并返回 413 错误**，而 go-nsq 客户端默认不校验 HTTP 状态码，错误会被吞掉。
- 启动
nsqd时务必显式设置--max-rdy-count=2500（匹配客户端MaxInFlight）和--mem-queue-size=5000（避免内存堆积） - 生产环境必须监控
nsqd的mem_queue_size和disk_queue_depth指标，这两个值持续上涨说明消费者跟不上或处理卡死 - go-nsq 的
Publish方法返回 error 时，大概率是网络不通或nsqd拒绝（比如 413），不要只打日志，要触发告警或降级逻辑
MaxInFlight 与处理延迟的匹配、nsqd 内存/磁盘队列水位，这三个点任一失控都会导致消息积压、重复或静默丢失 —— 它们不在代码里显眼，却藏在部署和配置的缝隙中。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
