Go语言实现消息队列简单教程

本文深入剖析了Go语言中使用无缓冲channel实现简单消息队列时最典型的死锁陷阱——当生产者与消费者启动节奏不匹配（如仅生产无消费、或消费者提前阻塞等待），所有goroutine会因channel操作永久阻塞，触发“all goroutines are asleep - deadlock”致命错误；文章直击初学者高频踩坑点，强调协同调度的必要性，并指出必须确保至少一个goroutine处于接收或遍历状态，才能让channel真正流动起来。

用 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。

今天带大家了解了的相关知识，希望对你有所帮助；关于Golang的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~