一文带你理解最简消息队列实现

最近在看公司的 redis queue 时，发现底层使用的是 go-zero 的 queue 。本篇文章来看看 queue 的设计，也希望可以从里面了解到 mq 的最小型设计实践。

使用

结合其他 mq 的使用经历，基本的使用流程：

1. 创建 producer 或 consumer

2. 启动 mq

3. 生产消息/消费消息

对应到 queue 中，大致也是这个：

创建 queue

我们看看 NewQueue 需要什么构建条件：

1. producer constructor

2. consumer constructor

将双方的工厂函数传递给 queue ，由它去执行以及重试。

这两个需要的目的是将生产者/消费者的构建和消息生产/消费都封装在 mq 中，而且将生产者/消费者的整套逻辑交给开发者处理：

1. 其实也就是将生产者的逻辑交个开发者自己完成，mq 只负责生产者/消费者的消息传递和之间的调度。

2. 工厂方法的设计，是将生产者本身和生产消息，这两个任务都交给 queue 自己来做调度或者重试。

生产msg

生产消息当然要回到生产者本身：

queue 中的生产者编写都必须实现：

• Produce()：由开发者编写生产消息的逻辑

• AddListener()：生产者

消费msg

和生产者类似：

启动 queue

启动，然后验证我们上述的生产者和消费者之间的数据是否传输成功：

以上就是 queue 最简易的入门使用代码。开发者可以根据自己的业务实际情况：自由定义生产者/消费者已经生产/消费逻辑。

整体设计


整体流程如上图：

1. 全体的通信都由 channel 进行

2. 通过加入监听器 listener ，以及事件触发 event ，相当于将触发器逻辑分离出来

3. 生产者有 produceone ，这个是生产消息的逻辑，但是其中的 Produce() 是由开发者编写【上面的 interface 中正是这个函数】

4. 同理消费者，Consume()

基本的消息流动就入上图以及上述描写的，具体的代码分析我们就留到下一篇，我们