Golang 实现一个简单的高性能消息队列中间件-Golang-PHP中文网

go语言中chan不能替代消息队列，因其无持久化、跨节点、崩溃恢复能力；仅适用于单机内存级轻量场景，需结合sync.map、context等构建可控的本地消息管道。

golang 实现一个简单的高性能消息队列中间件

Go 语言本身不提供开箱即用的“高性能消息队列中间件”，chan 只能用于单进程内协程通信，无法持久化、跨节点、抗崩溃；所谓“用 Go 实现一个简单高性能 MQ”，实际是指：在**可控边界内（如单机、内存级、开发/测试场景）**，用 chan + sync.Map + context 构建一个轻量、低延迟、可观察的本地消息管道，而非替代 RabbitMQ/Kafka。

为什么不能直接用 `chan` 当消息队列？

很多人一上来就封装 chan 成 Push/Pop 接口，结果上线后发现：进程挂了消息全丢、消费者重启后收不到积压、多个 goroutine 并发写同一个 chan panic、满载后生产者被阻塞卡死……这些不是 bug，是 chan 的设计使然。

chan 没有容量动态伸缩能力，make(chan T, N) 固定缓冲区，N 太小易阻塞，太大吃内存
无消息确认机制：chan 成功 ≠ 消费者已处理，更不等于“处理成功”
无超时控制：接收端 会永久阻塞，除非配 <code>select + time.After
无路由/主题支持：所有消费者从同一 chan 读，无法按 topic 或 key 分流

`sync.Map` + `chan` 实现多队列隔离

若需支持多个逻辑队列（比如 "order"、"notify"），不要用全局 chan，而应为每个队列名维护独立的通道和状态。用 sync.Map 存储队列实例，避免锁竞争：

type QueueManager struct {
    queues sync.Map // map[string]*Queue
}
<p>type Queue struct {
ch     chan Message
closed chan struct{}
}</p><p>func (qm <em>QueueManager) GetOrCreate(name string, cap int) </em>Queue {
if q, ok := qm.queues.Load(name); ok {
return q.(*Queue)
}
q := &Queue{
ch:     make(chan Message, cap),
closed: make(chan struct{}),
}
qm.queues.Store(name, q)
return q
}
</p>

注意：sync.Map 不适合高频删除+重建，但对“启动时注册、运行中只读取”的队列管理足够高效；若需运行时销毁队列，改用 map + sync.RWMutex 更稳妥。

如何避免消费者意外退出导致消息丢失？

单纯 for msg := range ch 在消费者 panic 或提前 return 时，未消费的 chan 消息会永远滞留——因为没人再读它。必须加兜底：

Go语言（Golang）1.26.0

Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。

下载

所有消费者启动时，用 context.WithCancel 绑定生命周期，关闭时显式 close closed 信号通道
接收循环必须带 select，监听 ctx.Done() 和 ch，防止 goroutine 泄漏
若要求“至少一次”，需在处理成功后才 ；若要求“至多一次”，则先 <code> 再处理（失败即丢）

示例关键片段：

func (q *Queue) Consume(ctx context.Context, handler func(Message) error) {
    for {
        select {
        case msg, ok := <h3>性能陷阱：别在 hot path 上做 JSON 序列化</h3><p>很多“高性能 MQ 封装”在 <code>Push</code> 时自动 <code>json.Marshal</code>，这在高吞吐下成为 CPU 瓶颈。真实场景中，消息体类型往往固定（如 <code>struct{OrderID string}</code>），应由调用方自行序列化，中间件只负责传递 <code>[]byte</code> 或接口：</p>