第三世界的妖孽做后端这几年，消息队列几乎是绕不开的坎。不管是订单系统、日志收集、还是异步任务处理，你总会遇到"需要解耦""需要削峰"这种需求，然后就会接触到Kafka、RabbitMQ、RocketMQ这些重型武器。但工具用久了，很多人其实没想过，一个消息队列底层到底是怎么跑起来的？生产者消费者模式又是怎么落地的？
我之前在一个内部项目里，因为不能引入额外的中间件依赖，只能从零用Go写一个内存版的高并发消息队列系统，用来在服务内部做异步解耦。那段时间踩了不少坑，也对消息队列的核心机制有了更深的理解。这篇文章就把这个实战过程完整记录下来，从需求拆解、并发设计、代码实现到性能调优和踩坑排查全流程走一遍。适合对Go并发已经有一些基础、想深入理解消息队列原理的开发者，也适合准备面试、想弄明白"生产者消费者模式到底怎么应用"的人。
1. 项目需求拆解：这个消息队列到底要做什么
1.1 "高并发"这三个字背后到底意味着什么
我们在提需求的时候经常把"高并发"挂在嘴边，但落到这个项目里，得先把指标拆清楚。我给自己定的目标是：在8核16G的普通机器上，单个消息队列实例能稳定支撑每秒3万条以上的消息吞吐，消息从写入到被消费者拉取的平均延迟控制在10毫秒以内，并且要支持多消费者并行消费。
这个目标听着不算夸张，但真正做的时候就会发现难点不在"快"，而在"稳定"。高并发场景下最怕的不是性能不够，而是并发控制出问题导致死锁、数据错乱、goroutine泄漏，这些故障在低并发时根本测不出来，一旦流量上来就瞬间崩盘。所以这个项目的核心不是写多少代码，而是围绕并发模型和数据结构做好设计。
另外，高并发消息队列的另一个隐含要求是"削峰填谷"。生产者可能瞬间涌入大量消息，比如秒杀活动开始的一秒钟内有十万条请求进来，但消费者的处理能力是有限的，可能一秒钟只能处理一万条。消息队列需要在中间起到缓冲作用，让生产者不受消费者速度制约，同时保证消息不会因为缓冲区溢出而丢失。这就是我选择实现一个有界队列而不是无界队列的原因，后面会详细讲。
1.2 技术选型：为什么选Go，为什么不直接上Kafka
先说结论：这个项目用Go实现，是因为Go的并发模型跟消息队列的天然契合度太高了。传统语言里，Java做并发要靠线程池、锁、阻塞队列这一整套东西，写起来要小心的细节非常多。而Go直接把goroutine和channel做成了语言级特性，创建几万个goroutine毫无压力，channel又天然就是"生产者和消费者之间的管道"，这几乎就是为消息队列量身定做的。
但为什么不用Kafka呢？因为Kafka虽然功能强大，但它是一个完整的分布式系统，需要部署Zookeeper或KRaft、管理分区和副本、处理磁盘和网络。在单机内部做异步解耦这种场景，引一个Kafka太重了，光维护成本就超过收益。而且Kafka的延迟通常在几十毫秒这个量级，对于进程内部的异步任务分发来说太慢了。我需要的是一个轻量的、能嵌入业务进程的消息队列组件，而不是一个独立部署的服务。
当然，Kafka的设计思路给了我很重要的参考。它通过Partition来并行消费的思路，本质上就是多个消费者分别处理不同分区的消息。我在设计消费者组的时候借鉴了这个模型，用多个goroutine并发从队列里取消息处理，从而实现水平扩容。
1.3 整体模块划分
整个系统在模块层面我拆成了四块。第一块是消息封装层，定义Message结构，包含消息ID、业务数据、时间戳、重试次数这些字段。第二块是队列存储层，负责消息的存储和调度，这里是最核心的并发控制区域。第三块是生产者接口层，对外提供Push方法，让业务方可以往队列里塞消息。第四块是消费者接口层，负责管理消费者goroutine、分发消息、处理ACK和重试。
这四个模块的依赖关系是单向的：生产者只依赖队列层，消费者也只依赖队列层，生产者和消费者之间完全解耦。这正是生产者消费者模式的核心价值——两个角色不直接通信，通过中间的缓冲容器间接协作。我在写代码的时候会特别注意控制依赖方向，这个习惯在项目变大以后会省很多事。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Go并发原语：搭建消息队列的积木
2.1 goroutine：你不是一个人在执行
Go语言最吸引我的地方就是goroutine。底层是协程，初始栈只有2KB，可以动态扩容，创建和销毁的代价极小。所以在Go里开几万个goroutine是常事，这在Java里是不可想象的，一个线程默认栈就是1MB，一万个线程得吃掉10G内存。
消息队列的消费者怎么做并发？最简单的思路就是启动N个goroutine，每个goroutine不停地从队列里取消息处理。这个模型叫消费者组，每个消费者之间是竞争关系，同一条消息只会被其中一个消费者处理。这种模式的好处是，随着消费者数量增加，整体消费能力可以线性扩展。
但goroutine本身也有它的脾气。它的调度是协作式的，如果一个goroutine里发生了阻塞操作，比如等锁、等IO，调度器会把它挂起，把CPU让给其他goroutine。这意味着你不能假设某个goroutine一定会"马上"执行，在高并发场景下，对执行顺序有要求的逻辑必须依靠channel或锁来同步，而不是靠goroutine的启动顺序。
2.2 channel：官方提供的天然生产者消费者模型
channel在Go里的地位太重要了。它本身就是"一个有容量限制的并发安全队列"，从这个角度看，Go官方早就把消息队列的内核提供给我们了。无缓冲channel的每次发送和接收都会阻塞，直到配对成功，这其实就是一个同步的生产者消费者模型。有缓冲channel则相当于一个有界队列，生产者可以连续往里面塞数据，直到缓冲区满。
用channel实现消息队列，最直接的方式就是make(chan *Message, size)，然后生产者往channel里发送，消费者从channel里接收。而且channel本身是并发安全的，内部有锁机制，多个goroutine同时发送或接收都不会出问题。
但channel有一个局限：它只支持"先进先出"的简单队列语义。如果你要实现延迟队列（消息到时间才能被消费）、优先级队列（高优消息先处理）、批量拉取等高级功能，channel就不好使了，因为channel不提供"查找、删除、按条件取"这种操作。所以我的方案是：第一版先用channel快速跑通整个流程，后续引入更灵活的数据结构来替代channel作为底层的存储容器。
2.3 sync包：Mutex、Cond与WaitGroup的配合
当底层的存储容器换成自定义的数据结构之后，就离不开sync包了。Mutex用来保护共享数据，这是基本功。关键在Cond条件变量，它是用来处理"等待某个条件成立"的场景的。
比如消费者要从一个空队列里取消息，这时候队列为空，消费者不应该空转，而应该阻塞等待，直到生产者往队列里放了消息再唤醒。这个场景用Mutex做不了，因为Mutex只能保证互斥，不能实现"等待通知"。Cond就是干这个事的：Wait()会释放锁并挂起当前goroutine，Signal()或Broadcast()会唤醒一个或所有等待的goroutine。
WaitGroup在这个项目里主要用在两个地方。一个是主流程要等所有消费者goroutine优雅退出，另一个是压测时要等所有生产者和消费者执行完来统计数据。它本质上是一个计数器，Add(n)增加计数，Done()减少计数，Wait()阻塞直到计数归零。这三个工具配合起来，就可以实现一个完整的内存消息队列内核。
3. 第一版实现：用channel搭一个能跑的内存队列
3.1 消息结构设计：Message不只是个字符串
消息结构是整个系统的基础，字段设计的好坏直接影响后续功能的扩展。第一版我只设计了最基础的字段，但随着项目深入，我逐步加上了重试次数、投递时间等字段，最后稳定下来的结构大概是这样的：
go复制type Message struct {
ID string
Payload []byte
Timestamp time.Time
RetryCount int
MaxRetry int
NextRunTime time.Time
}
ID字段是全局唯一标识，这个很重要。它不只是用来做日志追踪的，更是后面做幂等去重的关键——消费者把消息ID记录下来，如果ID已经处理过就跳过，这就能解决"重复消费"问题。Payload是业务数据，用[]byte而不是string是为了兼容二进制数据，也能减少内存拷贝。Timestamp是消息生产时间，用来统计端到端延迟。RetryCount和NextRunTime是给延迟队列和重试机制预留的。
很多人设计消息结构时只放一个字符串内容，等到要加延迟投递、重试次数这些功能时再反反复复改结构体，导致调用方代码跟着改。我在第一版就把这些字段预留好，后面写的时候会发现少踩很多坑。
3.2 生产者与消费者核心实现
第一版代码很简单，核心就几十行。消息队列直接基于有缓冲channel实现：
go复制type MemoryQueue struct {
ch chan *Message
}
func NewMemoryQueue(bufferSize int) *MemoryQueue {
return &MemoryQueue{
ch: make(chan *Message, bufferSize),
}
}
func (q *MemoryQueue) Publish(msg *Message) {
q.ch <- msg
}
func (q *MemoryQueue) Consume(handler func(*Message)) {
for msg := range q.ch {
handler(msg)
}
}
生产者调Publish会往channel里发消息，如果缓冲区满了会阻塞，这就是天然的反压机制。消费者调Consume会传入一个处理函数，然后开启一个for循环不断从channel里取消息，range会持续读取直到channel被关闭。
这个版本的优点是简洁，而它的简洁正是来自channel的语义完备。for msg := range q.ch这个写法是官方推荐的消费方式，它会正确处理channel关闭后的退出逻辑，不会panic也不会死循环。写完这个版本之后，我花了几分钟就验证了整个流程能跑通。不过这个版本的问题也显而易见：不能多消费者并行消费，不能做延迟投递，消息一旦被取走就无法确认是否处理成功，更不要说重复消费控制。
3.3 主流程组装与初步验证
我把生产者、消费者和主流程串起来，构造了一个简单的测试场景：三个生产者goroutine往队列里各发一万条消息，同时启动两个消费者goroutine处理，消息处理只是打印索引和内容。验证的结果是：消息没有丢失，没有重复，消费者之间不会同时处理同一条消息。
这个验证结果主要是确认了channel的并发安全性。多个生产者goroutine同时往channel里写，多个消费者goroutine同时读，channel内部的锁机制保证了所有操作的原子性。如果是自己实现的数据结构，要做到同样的并发安全得多花不少功夫。
不过在这个阶段我也发现了一个隐患：当消费者处理速度跟不上生产速度时，channel缓冲区很快会满，生产者的Publish方法会一直阻塞。这其实是一种好的背压行为，因为内存队列的资源是有限的，如果无限制地让生产者往队列里塞消息，最终会把内存打爆。但这个背压行为在我后续对消费者并发度要求提高以后就不够用了，因为单个for-range消费循环限制了消费能力只能有一个goroutine，提升不了吞吐。
4. 进阶演进：支持多消费者与可靠投递
4.1 从单消费者到消费者组
第一版的瓶颈太明显了，一个消费者goroutine的消费速度就是整条链路的消费上限。我把Consume方法改造一下，升级成消费者组模式：
go复制type WorkerPool struct {
queue *MemoryQueue
workers int
handler func(*Message)
wg sync.WaitGroup
}
func (wp *WorkerPool) Start() {
for i := 0; i < wp.workers; i++ {
wp.wg.Add(1)
go func() {
defer wp.wg.Done()
for msg := range wp.queue.ch {
wp.handler(msg)
}
}()
}
}
func (wp *WorkerPool) Stop() {
close(wp.queue.ch)
wp.wg.Wait()
}
这里我启用了N个消费者goroutine，同时从同一个channel里取消息。channel的特性保证了同一条消息只会被其中一个消费者取走，所以不需要额外加锁。这个消费者组模型跟Kafka里同一个消费组内多个消费者分担分区的思路是类似的，区别在于Kafka是分区级别的并行，这里我们是消息级别的并行。
启动消费者组的时候记得用WaitGroup管理goroutine，否则程序退出的时候消费者可能还在跑，导致资源泄漏。我把Stop方法设计成先关闭channel再等待所有goroutine退出，for-range会感知到channel关闭并退出循环，从而实现优雅停止。这里有个细节：关闭channel的操作只能由生产者方负责，消费者不应该主动关闭channel，否则会引发panic，我后面会专门讲这个问题。
4.2 手动ACK与重试机制
第一版的消息被取走就算"被处理了"，不管handler里是否发生panic，消息都不会再出现。这在生产环境是不可接受的——如果消费者处理消息时依赖的外部服务暂时不可用，消息就丢失了。所以第二个升级就是加入手动ACK机制。
具体做法是我放弃了直接使用channel做存储，改用"待处理队列 + ACK队列"双队列结构。消费者从待处理队列取出消息后，不会立刻从系统里抹掉这条消息，而是先把消息放入ACK队列，同时启动一个延迟任务。如果消费者在超时时间内调用Ack(msgID)，说明消息处理成功，就可以从ACK队列移除。如果超时未确认，就把消息重新放回待处理队列，并且重试次数加一。如果消息的重试次数超过了最大阈值，就把它丢进死信队列，记录错误日志，防止无限重试。
这个机制的核心是"至少一次投递"语义。它不能保证消息绝对不重复（这是"恰好一次"语义），但能保证消息不丢。实际业务中大多数场景都是"至少一次"就够了，再加上幂等操作来抵消重复的影响。
go复制func (wm *WaitQueue) Ack(msgID string) {
wm.mu.Lock()
defer wm.mu.Unlock()
if item, ok := wm.acking[msgID]; ok {
delete(wm.acking, msgID)
close(item.done)
}
}
我在代码里用了一个map[string]*ackItem来记录正在等待确认的消息，每一条消息都有一个done channel，这样等待超时的逻辑就可以用select加time.After来实现。这比轮询检查要高效得多，因为大部分消息都是在超时之前就正常ACK掉了，不会触发额外的扫描开销。
4.3 处理重复消费：幂等与去重
重复消费是消息队列绕不开的话题，我项目中真的遇到过消息被同一个消费者处理了两次的情况。原因很简单：消费者处理完消息还没来得及发送ACK，goroutine就崩溃了，这条消息在下一次扫描时又被重新投递，于是被处理了两遍。
解决重复消费的标准方案是"幂等+去重"。幂等是说同样的操作执行多次结果一样，比如把余额设为100元，执行一百次结果还是100元。如果业务操作天然幂等，重复消费就直接不用管。但如果业务操作不是幂等的，比如扣减库存这种，就必须做去重。方法是给每条消息一个全局唯一的ID，消费者在处理之前先查一下这个ID是否出现在已处理记录的集合里，出现了就跳过。我项目里用一个LRU缓存存最近一万条已处理消息的ID，因为消息ID是唯一的，重复消息就会被直接过滤掉。
但这里有个细节要注意：判断重复和执行业务操作不是原子的，可能存在两个goroutine同时判断"没处理过"，然后同时执行的情况。所以更稳妥的做法是给加锁，或者用Redis的SET NX命令实现分布式锁。在我这个内存版本里，我用一个sync.Mutex保护去重集合的读写，这样至少在同一进程内是安全的。如果你用的是Kafka这类分布式消息队列，通常是用Redis的Set或数据库的唯一索引来做跨节点的去重。
4.4 延迟队列的实现思路
延迟队列是另一个高频需求，比如订单超过15分钟未支付自动关闭。我一开始想用轮询扫描整个队列来判断每条消息是否到期，但这样做效率太低，每次扫描都要遍历队列里所有消息。后来我换成了时间堆的方案：用一个最小堆来按到期时间排序，每次从堆顶取出到期时间最早的消息，如果发现堆顶还没到期，就知道队列里没有消息需要处理，可以让消费者休眠到那个时间点再醒来。
Go标准库里的container/heap可以直接实现最小堆。核心结构是：
go复制type delayQueue struct {
heap []
*Item
}
每次生产者往延迟队列里投递消息时，会带上要延迟的时长，消息实际要等到time.Now().Add(delay)之后才能被消费。投递消息时顺手往一个定时信号量里发个通知，负责调度的goroutine收到通知后检查堆顶消息是否到期，到期就把消息从堆里弹出来，转发到普通队列让消费者组消费。
这个方案比轮询高效的地方在于，它把复杂度从O(n)降到了O(log n)，而且大部分时间调度goroutine都在休眠，不占用CPU。我在实际压测中发现，在大量延迟消息同时存在的场景下，这个时间堆方案的表现非常稳定，调度延迟保持在毫秒级。
5. 压测与性能调优实录
5.1 用WaitGroup写一个简单的压测工具
功能和可靠性都做完了，接下来就到了最关键的环节：验证"高并发"这个目标到底达没达到。我写了一个压测工具，思路是用多个goroutine模拟高并发生产，用多个消费者并行消费，通过WaitGroup等待所有任务结束，然后统计总耗时和吞吐量。
压测工具的核心代码如下：
go复制func Benchmark() {
queue := NewMessageQueue(10000)
var wg sync.WaitGroup
consumerCount := 4
for i := 0; i < consumerCount; i++ {
wg.Add(1)
go func(id int) {
defer wg.Done()
queue.StartConsume(func(msg *Message) {
// 模拟处理耗时
time.Sleep(50 * time.Microsecond)
})
}(i)
}
start := time.Now()
total := 100000
for i := 0; i < total; i++ {
queue.Publish(&Message{ID: strconv.Itoa(i)})
}
elapsed := time.Since(start)
fmt.Printf("吞吐量: %.0f msg/s\n", float64(total)/elapsed.Seconds())
}
第一次压测结果我记得很清楚：在4个消费者并发的情况下，整体吞吐只有大约1万条/秒，远远没有达到我之前定的3万条/秒目标。而且更奇怪的是，我增加消费者数量到8个的时候，吞吐量几乎没有提升，这就说明系统存在瓶颈，而且瓶颈不在消费者的处理能力上。
排查下来发现，问题出在队列存储层上。当时我用Mutex和Cond来实现消息的取放，每次生产者往队列里追加消息时都要加锁、更新切片、发信号；消费者取消息时要加锁、从切片头部删除元素。从切片头部删除元素会导致后续所有元素往前移动一位，这是一个O(n)的复制操作，在高并发场景下开销非常大。找到这个原因之后，我决定用环形队列来代替切片。
5.2 瓶颈分析与参数调整
环形队列的核心思路是用一个固定长度的数组，配合头尾两个指针，存储和读取数据时只需要移动指针，而不需要复制元素。这个改造带来了质的飞跃，同样是4个消费者，吞吐从1万每秒提升到了5万每秒，一下子就达标了。但这也暴露了另一个问题：队列有界后，缓冲区满的时候生产者会被迫阻塞，这会导致生产者被反压拖慢，整体吞吐又会掉下来。
我在压测的时候测试了不同缓冲区大小的表现。缓冲区太小，比如只有1000，生产者和消费者的耦合变强，消费者稍微慢一点生产就会被阻塞。缓冲区太大，比如10万，内存占用会很大，而且极端情况下消息的端到端延迟会升高。最后我选的参数是2万，在消息大小1KB左右的时候，内存占用控制在20MB左右，同时能非常好的吸收突发流量。当然这个参数不是固定的，得根据实际业务的消息大小和消费能力来调。
还有一个容易被忽视的瓶颈是锁竞争。我统计了goroutine的等待时间，发现消费者和生产者对同一个Mutex的竞争相当激烈。后来我把匹配器Mutex分成了两个——生产者写入用一把锁，消费者读取用另一把锁——但由于环形队列本身是一个共享结构，这个优化效果有限。真正有效的方案是使用多队列分片：把队列拆成多个物理队列，比如16个分片，消息根据ID哈希到不同的分片，每个分片有自己独立的锁。生产者往不同分片写的时候，锁竞争分布到不同锁上，整体吞吐几乎可以乘以分片数。这个思路跟Redis Cluster的分片原理其实是一样的。
5.3 对比Kafka的启发
压测过程中我又重新翻了翻Kafka的资料，发现它的高性能设计给了我很多启发。Kafka用顺序写磁盘、页缓存、零拷贝来提升IO效率，用分区来水平扩展，这些设计思想其实可以借鉴到我们的内存消息队列里。
具体来说，Kafka为什么用日志追加的方式而不是索引方式？因为磁盘的顺序写比随机写快几个数量级。我在设计内存队列的存储层时也有类似的考虑：环形队列本质上就是"顺序写、顺序读"，比切片头部删除方案在缓存友好性上强太多了。另外，Kafka的分区概念对应到我的多队列分片优化上，也是同一个思路——让不同的数据块独立并发，互不干扰。
这些对比让我意识到，所谓"高性能"不是说用了某个牛的技术，而是在每个层面都把不必要的工作去掉。消息队列的核心工作就是"存"和"取"，把这两个动作的复杂度降到最低，性能自然就上来了。
6. 实战踩坑记录：这些问题我debug了很久
6.1 关闭channel引发的panic
有段时间我的程序在退出时会随机崩溃，报错信息是send on closed channel。排查了半天，原因是关闭channel的时机和生产者发送消息的时机产生了竞争：一个goroutine在关闭channel之后，另一个goroutine还尝试往channel里发送消息，这个操作会直接panic。
解决方案是引入sync.Once来保证关闭操作只执行一次，同时在发送端检查队列是否已经被关闭。但更关键的是想清楚谁有权关闭channel。channel的关闭原则是"不要在接收方关闭，也不要在多个发送方同时关闭"，应该由唯一的发送方或者在所有发送方都停止发送之后关闭。我在设计Stop方法时，先把所有生产者的生命周期管理好，确保没有新的消息再进来之后，才执行关闭操作。这个问题本质上是goroutine生命周期管理的问题，不只是channel的问题。
6.2 消费者goroutine泄漏
排查另一个bug的时候，我用pprof查看goroutine数量，发现程序跑了几个小时后，goroutine数量一直在增长，很明显有goroutine泄漏。定位到最后发现是消费者goroutine陷入了一个死循环等待，永远无法退出。
原因是我在实现手动ACK机制时引入了一个map来跟踪待确认消息，消费者取出消息后，如果没人调用ACK，这条消息就会一直挂在map里，对应的done channel就永远没有数据可读。同时消费者goroutine在等done通知时没有设置超时，于是它永远地阻塞了。也就是说，我从"消息丢失"的坑里爬出来之后，又因为"永远不会超时"的机制掉进了"消息泄漏"的坑。
修复方法是给等待ACK的过程加一个超时时间，超时之后主动把消息重新放入待处理队列，同时把这次投递的上下文信息清干净。这里我还学到了一条经验：凡是等待某个事件的地方，最好都加超时，哪怕是内部调用，因为外部依赖的响应时间是不可控的。没有超时的等待，就是潜在的goroutine泄漏源头。
6.3 生产速度远超消费速度怎么办
我把压测的模型改成"突刺型"——生产者一秒钟内猛灌10万条消息，然后休息十秒钟。结果发现内存占用飙升到将近1GB，消费者完全消费不过来，队列被塞满了，生产者直接被阻塞住，导致上游业务跟着卡顿。
这个地方其实体现了消息队列的"削峰"作用，但它必须有配套手段，否则削峰就变成了把上游的问题传导到消息队列内部。我的应对策略是第一设置合理的缓冲区大小，第二增加消费者实例数，第三如果消费能力实在跟不上，就启用丢弃旧消息策略或者把消息批量合并。在真实业务里，生产者如果返回阻塞太长时间，会拖垮整个链路，所以更合理的做法是让生产者在队列满时快速失败，返回一个限流信号，让上游自己做降级。
6.4 条件变量的假唤醒问题
在我用Cond实现队列时，还踩过一个隐蔽的坑。当时消费者等待消息的逻辑写了类似这样的代码：
go复制for {
if len(queue.items) == 0 {
c.cond.Wait()
} else {
msg := queue.items[0]
break
}
}
看起来逻辑没问题，但生产环境跑了一段时间后发现，偶尔会有消费者取到重复的消息。原因是Cond的Wait被唤醒后，并不一定是因为条件真的满足了，可能是一个signal被多个等待的goroutine同时唤醒，也就是所谓的"惊群效应"。多个消费者同时醒来，都发现队列里有消息，都去取，但因为取消息的操作没有在锁保护范围内同步好，最终出现了重复消费。
正确的做法是唤醒之后必须重新检查条件，并且整个检查加取数据的操作必须在同一个锁里面。我后来改成：
go复制c.cond.L.Lock()
for len(q.items) == 0 {
c.cond.Wait()
}
msg := q.items[0]
q.items = q.items[1:]
c.cond.L.Unlock()
把for而不是if来包住Wait，是Cond编程的基本功，这个点我在读文档的时候就知道，但真正踩坑以后才理解它到底为什么重要。Go的channel封装了这些复杂性，所以第一版用channel完全没遇到这个问题，一旦自己用Cond实现队列，就必须亲自处理这些细节。
7. 写在最后的个人体会
这个项目做下来，我最深的感受是：消息队列本身并不复杂，复杂的是在并发和内存之间找到那个平衡点。早期直接拿channel当队列用的时候，代码很简单，但功能受限；后来自己用Mutex、Cond、环形队列去实现底层存储，功能灵活了，但并发控制的复杂度直线上升。每一步演进都是在跟系统的瓶颈对话，反复压测、定位、优化，最后才得到一个稳定可靠又高性能的结果。
如果你问我能不能在生产环境直接使用这个内存版消息队列，我的答案是不会。因为真正的生产系统还需要考虑持久化、故障恢复、分布式协调这些复杂的工程问题，这些正是Kafka这些成熟中间件的价值所在。但这个项目让我真正理解了那些中间件为什么这么设计，再去看Kafka的文档时，很多东西就变得顺理成章了。
如果你也想动手练练，我建议先从第一版channel方案开始，然后逐步往更深的方向演进，试着自己实现ACK机制、延迟队列、分片存储，每走一步都会踩到不一样的坑，而这些坑就是最值钱的学习材料。