Kafka 太重？试试 NSQ：一个优雅到极致的消息队列

发布日期: 2026-07-02

文章字数: 3.2k

阅读时长: 12 分钟

阅读次数:

今天想和大家聊一个既老牌又实用的开源项目——NSQ。如果你是做后端开发，特别是跟 Go 语言打交道比较多的话，对这个名字应该不会陌生。即使你没用过，在消息队列这个技术选型里，NSQ 也绝对是个值得了解的存在。

本文会详细介绍 NSQ 的核心概念、优缺点、与其他消息队列的对比，并通过 Docker 快速搭建环境，最后给出完整的 Go 代码示例。

话不多说，咱们这就直接开始！

1. 为什么要关注 NSQ？

不知道大家有没有遇到过这样的情况：某个瞬间，你的业务系统迎来流量波峰，数据库瞬间被打爆，请求直接超时。这时候，你就需要消息队列来削峰填谷。

NSQ 是一个由 Bitly 公司开源的、实时分布式消息平台 。它用 Go 语言编写，于 2013 年正式开源，最初用于支撑 Bitly 短链接服务的高吞吐需求，后来逐渐被 Docker、Stripe 等企业采用。

NSQ 的设计目标是大规模地处理每天数以十亿计级别的消息，具有分布式和去中心化拓扑结构，该结构具有无单点故障、故障容错、高可用性以及能够保证消息的可靠传递的特征。

2. NSQ 的三大核心组件

在正式动手之前，我们得先认识一下 NSQ 家族中的三个关键角色。可以把 NSQ 想象成一个现代化的物流中心：

nsqd：负责接收、排队、投递消息给客户端。它是一个守护进程，可以独立运行，通常一个服务节点部署一个 nsqd 实例。它会向 nsqlookupd 注册自己的元数据信息（topic、channel、服务信息）。
nsqlookupd：管理拓扑信息并提供最终一致性的发现服务。nsqd 节点会将自己的地址信息广播给 nsqlookupd，客户端通过查询 nsqlookupd 来发现指定 topic 的生产者。
nsqadmin：一套 Web UI，可以实时查看集群状态，甚至可以在页面上直接发送消息。

3. 核心概念：Topic & Channel

在写代码之前，理解 NSQ 的灵魂设计——Topic 和 Channel 至关重要：

Topic（主题）：可以理解为“消息的分类”。例如处理订单的 topic 叫 order，处理用户日志的叫 log。
Channel（通道）：可以理解为“订阅组”。每个 Channel 都会从 Topic 那里拷贝一份完整的消息流。也就是说，消息是从 topic -> channel（每个 channel 接受该 topic 的所有消息的副本）多播的，但是从 channel -> consumers 是均匀分布（每个消费者接受该 channel 的一部分消息）。

这样的设计带来一个很大的好处：不同的 channel 之间相互隔离。即使某个 channel 的消费者处理缓慢，也不会影响其他 channel 的正常消费。

4. NSQ 的优缺点分析

4.1 核心优势

根据官方文档和社区反馈，NSQ 具有以下显著优势：

优势	说明
去中心化架构	没有单点故障（SPOF），支持分布式拓扑
水平扩展	没有中心代理，可无缝添加更多节点到集群
低延迟	采用推模式，消息实时性非常好
部署简单	编译后的二进制文件没有运行时依赖，所有参数在命令行指定
自带管理界面	nsqadmin 提供直观的 Web 监控和管理
数据格式无关	消息可以是 JSON、MsgPack、Protocol Buffers 等任意格式
多语言支持	官方提供 Go 和 Python 库，社区提供多种客户端
内存+磁盘混合存储	超过内存水位线的消息透明地保存在磁盘上

4.2 局限性

当然，NSQ 也不是万能的，它有一些设计上的权衡需要注意：

局限性	说明
消息默认不持久化	主要是一个内存中的消息平台，但可配置为持久化
至少一次投递	消息可能会被重复投递，需要消费者做幂等处理
不保证顺序	消息可能乱序，因为涉及 requeue、内存和磁盘存储等
无消息复制	没有内置的复制机制，节点故障可能导致数据丢失
无死信队列	对于消费失败的消息，没有内置的死信处理机制
消息不可回溯	消息消费确认后即删除，不能像 Kafka 那样回溯消费

5. 与其他消息队列的简单对比

为了让大家更清楚地了解 NSQ 的定位，这里和几个主流的消息队列做个简单对比：

特性	NSQ	Kafka	RabbitMQ	NATS
开发语言	Go	Scala/Java	Erlang	Go
消息模型	Topic-Channel	Topic-Partition	Exchange-Queue	Subject
推送/拉取	推 (Push)	拉 (Pull)	推 (Push)	推 (Push)
持久化	内存+磁盘	全部磁盘	内存/磁盘	内存/JetStream
顺序保证	不支持	分区内有序	队列内有保证	单连接有序
交付保证	至少一次	至少一次/精确一次	至少一次	最多一次/至少一次
延迟消息	支持（内存优先队列，最多2小时）	不支持	支持（需插件）	不支持
死信队列	不支持	无（通过 offset 管理）	支持	支持
管理界面	内置 nsqadmin	需第三方工具	内置	内置
适用场景	实时推送、微服务解耦	日志收集、大数据流处理	企业级应用、复杂路由	云原生、高性能实时通信

从上表可以看出，NSQ 的优势在于简单、低延迟、易部署，适合对实时性要求高、不要求消息严格有序的中小规模场景。

6. 通过 Docker 一键搭建 NSQ 环境

6.1 准备工作

确保你的电脑上已经安装了 Docker 和 Docker Compose。

6.2 编写 docker-compose.yml

我们将在同一台机器上启动三个服务，模拟一个小型集群：

version: '3'
services:
  # 服务发现与协调中心
  nsqlookupd:
    image: nsqio/nsq:latest  # 使用官方镜像
    container_name: nsqlookupd
    command: /nsqlookupd      # 启动 lookupd 服务
    ports:
      - "4160:4160"           # tcp 端口，给 nsqd 使用
      - "4161:4161"           # http 端口，给 admin 和客户端查询使用
    networks:
      - nsq-network

  # 消息核心守护进程
  nsqd:
    image: nsqio/nsq:latest
    container_name: nsqd
    command: /nsqd --lookupd-tcp-address=nsqlookupd:4160  # 告诉 nsqd 去哪里注册
    ports:
      - "4150:4150"           # tcp 端口，收发消息
      - "4151:4151"           # http 端口，可直接通过 API 发消息
    depends_on:
      - nsqlookupd            # 确保 lookupd 先启动
    networks:
      - nsq-network

  # Web 管理界面
  nsqadmin:
    image: nsqio/nsq:latest
    container_name: nsqadmin
    command: /nsqadmin --lookupd-http-address=nsqlookupd:4161 # 连接 lookupd 的 http 端口
    ports:
      - "4171:4171"           # 浏览器访问的端口
    depends_on:
      - nsqlookupd
    networks:
      - nsq-network

networks:
  nsq-network:
    driver: bridge

6.3 启动并验证

# 在 docker-compose.yml 所在目录下执行
docker-compose up -d

# 查看容器状态
docker ps

看到三个容器状态为 Up，说明启动成功。此时打开浏览器访问 http://localhost:4171，应该能看到 NSQAdmin 的漂亮界面了。

7. 实战：完整的 Go 代码示例

7.1 准备工作

首先安装 Go 客户端库：

go get -u github.com/nsqio/go-nsq

7.2 生产者代码

下面是一个完整的生产者示例，它会从标准输入读取消息并发送到 NSQ ：

// producer/main.go
package main

import (
	"bufio"
	"fmt"
	"os"
	"strings"

	"github.com/nsqio/go-nsq"
)

// NSQ Producer Demo

var producer *nsq.Producer

// 初始化生产者
func initProducer(addr string) (err error) {
	config := nsq.NewConfig()
	// 可以配置一些参数
	// config.MaxAttempts = 5
	
	producer, err = nsq.NewProducer(addr, config)
	if err != nil {
		fmt.Printf("create producer failed, err:%v\n", err)
		return err
	}
	
	// 检查连接是否正常
	err = producer.Ping()
	if err != nil {
		fmt.Printf("producer ping failed, err:%v\n", err)
		return err
	}
	
	return nil
}

func main() {
	// nsqd 的 TCP 地址
	nsqdAddr := "127.0.0.1:4150"
	err := initProducer(nsqdAddr)
	if err != nil {
		fmt.Printf("init producer failed, err:%v\n", err)
		return
	}
	
	fmt.Println("producer started, please input messages (input 'Q' to quit):")
	
	reader := bufio.NewReader(os.Stdin) // 从标准输入读取
	for {
		data, err := reader.ReadString('\n')
		if err != nil {
			fmt.Printf("read string from stdin failed, err:%v\n", err)
			continue
		}
		data = strings.TrimSpace(data)
		if strings.ToUpper(data) == "Q" { // 输入 Q 退出
			break
		}
		
		// 向 'topic_demo' publish 数据
		topicName := "topic_demo"
		err = producer.Publish(topicName, []byte(data))
		if err != nil {
			fmt.Printf("publish msg to nsq failed, err:%v\n", err)
			continue
		}
		
		fmt.Printf("published message: %s\n", data)
	}
	
	// 停止生产者
	producer.Stop()
	fmt.Println("producer stopped")
}

7.3 消费者代码

下面是一个完整的消费者示例，它会从 NSQ 接收消息并处理：

// consumer/main.go
package main

import (
	"fmt"
	"log"
	"os"
	"os/signal"
	"syscall"
	"time"

	"github.com/nsqio/go-nsq"
)

// NSQ Consumer Demo

// MyHandler 是一个消费者类型，需要实现 HandleMessage 接口
type MyHandler struct {
	name string
}

// HandleMessage 处理消息
// 当有消息推送到这个消费者时，此函数会被调用
func (h *MyHandler) HandleMessage(message *nsq.Message) error {
	// 消息内容在 message.Body 中，是 []byte 格式
	// message.ID 是消息的唯一 ID
	// message.Attempts 是消息的重试次数
	
	log.Printf("[%s] received message: %s (id: %s, attempts: %d)", 
		h.name, string(message.Body), message.ID, message.Attempts)
	
	// 模拟业务处理耗时
	time.Sleep(100 * time.Millisecond)
	
	// 返回 nil 表示消息处理成功，NSQ 会将其标记为完成
	// 如果返回 error，NSQ 会根据配置进行重试
	return nil
}

func main() {
	// 1. 配置消费者
	config := nsq.NewConfig()
	// 设置最大 inflight 消息数
	config.MaxInFlight = 100
	// 设置重试延迟
	config.MaxAttempts = 5
	
	// 2. 创建消费者实例
	// 参数: topic 名称, channel 名称, 配置
	// 注意：即使 channel 不存在，订阅时也会自动创建
	topicName := "topic_demo"
	channelName := "channel_demo"
	consumer, err := nsq.NewConsumer(topicName, channelName, config)
	if err != nil {
		log.Fatal(err)
	}
	
	// 3. 添加我们自定义的处理器
	handler := &MyHandler{name: "Worker-1"}
	consumer.AddHandler(handler)
	
	// 也可以添加多个处理器（不建议）
	// consumer.AddHandler(&MyHandler{name: "Worker-2"})
	
	// 4. 设置日志级别
	consumer.SetLoggerLevel(nsq.LogLevelInfo)
	
	// 5. 连接到 nsqlookupd (推荐的方式，可以自动发现所有的 nsqd 生产者)
	// 这里连接我们之前 Docker 启动的 nsqlookupd 地址
	lookupdAddr := "127.0.0.1:4161"
	err = consumer.ConnectToNSQLookupd(lookupdAddr)
	if err != nil {
		log.Fatal(err)
	}
	
	// 也可以直接连接 nsqd（不推荐用于生产环境）
	// err = consumer.ConnectToNSQD("127.0.0.1:4150")
	// if err != nil {
	//     log.Fatal(err)
	// }
	
	fmt.Println("consumer started, waiting for messages...")
	
	// 6. 监听退出信号
	sigChan := make(chan os.Signal, 1)
	signal.Notify(sigChan, syscall.SIGINT, syscall.SIGTERM)
	<-sigChan
	
	// 7. 优雅停止
	fmt.Println("stopping consumer...")
	consumer.Stop()
	
	// 等待消费者完全停止
	<-consumer.StopChan
	fmt.Println("consumer stopped")
}

7.4 运行测试

启动消费者：

cd consumer
go run main.go

你会看到输出：”consumer started, waiting for messages…”

启动生产者（新开一个终端）：

cd producer
go run main.go

在生产者终端输入消息：

hello NSQ!
published message: hello NSQ!

this is my first message
published message: this is my first message

Q
producer stopped

观察消费者终端：

2025/03/09 15:30:45 [Worker-1] received message: hello NSQ! (id: 7fd8e2a1b3c4d5e6, attempts: 1)
2025/03/09 15:30:45 [Worker-1] received message: this is my first message (id: 8fe9f3b2c4d5e6f7, attempts: 1)

7.5 通过 HTTP 接口发送消息

NSQ 的一个很方便的特性是支持 HTTP 接口，无需客户端库即可发送消息：

# 向 topic_demo 发送消息
curl -d 'Hello from HTTP!' 'http://127.0.0.1:4151/pub?topic=topic_demo'

观察消费者终端，应该能看到这条消息被接收。

8. 可视化监控

在浏览器中刷新 http://localhost:4171，你会看到：

在 Nodes 页面可以看到注册的 nsqd 节点
在 Topics 页面可以看到 topic_demo 以及它的 channel_demo
可以清晰地看到 Depth（积压消息数）、In-Flight（正在处理的消息数）、Deferred（延迟消息数）等关键指标
可以查看每个 channel 上的消费者连接情况

9. 生产环境使用建议

如果你打算在生产环境中使用 NSQ，以下几点建议供参考：

消息持久化配置：如果不想丢失消息，可以设置 --mem-queue-size=0，这样所有消息都会保存到磁盘。
部署多个 nsqlookupd：虽然 nsqlookupd 节点之间不协调，但部署多个可以提高发现服务的可用性。
消费者幂等处理：由于 NSQ 保证”至少一次”投递，消费者要做好幂等处理。
及时清理无用 topic/channel：topic 和 channel 一旦创建就会一直存在，要及时在管理台或通过代码清除无效的，避免资源浪费。
监控告警：通过 nsqadmin 实时监控 Depth 指标，设置积压告警。

10. 总结

通过本文，我们不仅深入了解了 NSQ 的架构、核心概念、优缺点，还与其他主流消息队列做了对比，并通过 Docker 快速搭建了一套可用的开发环境，最后给出了完整的 Go 代码示例。

NSQ 虽然不是最年轻的消息队列，但它的简单、稳定、高性能使其在中小团队和实时性要求高的场景中依然占有一席之地。特别是对于 Go 技术栈的团队，NSQ 是一个值得认真考虑的消息队列选项。

希望这篇文章能帮你跨过门槛，在实际项目中多一个可靠的选项。如果你有任何问题或经验分享，欢迎在评论区留言讨论！

Alex

https://pudongping.github.io/posts/6afc65a6.html

本博客所有文章除特別声明外，均采用 CC BY 4.0 许可协议。转载请注明来源 Alex !

Go Golang NSQ 消息队列

本篇

Kafka 太重？试试 NSQ：一个优雅到极致的消息队列

2026-07-02 Go

Go Golang NSQ 消息队列

RabbitMQ 太重，Kafka 太复杂？Go 开发者：Asynq分布式任务队列就刚刚好

2026-07-02 Go

Go Golang Asynq 分布式消息队列

Kafka 太重？试试 NSQ：一个优雅到极致的消息队列

1. 为什么要关注 NSQ？

2. NSQ 的三大核心组件

3. 核心概念：Topic & Channel

4. NSQ 的优缺点分析

4.1 核心优势

4.2 局限性

5. 与其他消息队列的简单对比

6. 通过 Docker 一键搭建 NSQ 环境

6.1 准备工作

6.2 编写 docker-compose.yml

6.3 启动并验证

7. 实战：完整的 Go 代码示例

7.1 准备工作

7.2 生产者代码

7.3 消费者代码

7.4 运行测试

7.5 通过 HTTP 接口发送消息

8. 可视化监控

9. 生产环境使用建议

10. 总结

你的赏识是我前进的动力