Go语言实现消息队列与异步处理教程

小伙伴们有没有觉得学习Golang很有意思？有意思就对了！今天就给大家带来《Go语言实现简单消息队列及异步处理示例》，以下内容将会涉及到，若是在学习中对其中部分知识点有疑问，或许看了本文就能帮到你！

使用无缓冲 channel 实现队列时，若生产者与消费者未协同启动（如仅生产无消费，或消费先阻塞等待），所有 goroutine 会因 channel 操作阻塞而休眠，触发“all goroutines are asleep - deadlock”错误。

用 chan 实现队列时，为什么一跑就报 fatal error: all goroutines are asleep - deadlock

这是最常踩的坑：裸用无缓冲 chan 且没配好生产者/消费者节奏。比如只启了生产者往 chan string 写，但没启消费者读，或消费者先启动却等不到数据，goroutine 全卡住，Go 运行时直接 panic。

• 必须确保至少一个 goroutine 在 range 或 等待读，另一个在 写（或用 select 防死等）
• 别用无缓冲 channel 做“队列”——它本质是同步点，不是缓存；要用就选带缓冲的：messages := make(chan string, 10)
• 如果要支持“空队列时等待”，不能只靠 ，得用 select + time.After 或配合 sync.Cond 手动管理状态

MessageQueue 结构体封装里，sync.Mutex 不是用来保护 chan 的

Go 的 channel 本身是并发安全的，sync.Mutex 在这里不是必需品。加它的真正目的是为后续扩展留钩子：比如加消息计数器、记录入队时间、统计积压量，或者将来把内存队列换成 Redis 后端时，统一加日志或重试逻辑。

• 当前仅用 channel 时，Enqueue 和 Dequeue 方法内部无需加锁
• 但如果结构体里加了 len 字段来实时统计长度，那每次读写就得用 mu.Lock() 保护
• 错误做法：给 channel 加锁后还用 len(ch) 判断是否满——这不可靠，因为 len 是瞬时快照，且对 buffered channel 才有意义

用 select 处理超时和非阻塞，比裸写 更健壮

真实场景中，你不能让生产者无限期卡在 messages 上，尤其当消费者处理慢、队列满时。用 select 可明确控制行为边界。

• 非阻塞入队（丢弃策略）：

  select {
  case messages 

• 带超时入队（降级策略）：

  select {
  case messages 

• 消费者侧同理：用 select 包裹 ，避免单个 goroutine 挂死导致整条消费链停滞

什么时候该从内存 chan 切到 Redis 或 Kafka

纯内存队列适合开发验证、单机轻量任务（如日志聚合、内部通知）。一旦出现以下任一情况，就得换：

• 需要消息持久化（进程重启不丢数据）→ 必须上 Redis（LPUSH/BRPOP）或 Kafka
• 消费者数量动态伸缩，或跨机器部署 → 内存 chan 无法共享，Redis 或 Kafka 提供中心化分发
• 要求精确一次（exactly-once）语义、死信队列、延时消息 → 内存方案几乎没法可靠实现
• 流量突发远超内存 buffer 容量（比如秒杀场景）→ Redis 的内存+磁盘混合模式或 Kafka 的分区机制更稳

别等到线上崩了才换——只要服务要长期运行、有外部依赖、或用户量破千，就该默认选 Redis 方案，哪怕只是本地 localhost:6379。

终于介绍完啦！小伙伴们，这篇关于《Go语言实现消息队列与异步处理教程》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布Golang相关知识，快来关注吧！