大家好呀，我是楼仔。

RabbitMQ 的文章之前写过，但是当时给的示例是 Demo 版的，这篇文章主要是结合之前写的理论知识，将 RabbitMQ 集成到技术派项目中。

不 BB，上文章目录：

下面我们先回顾一下理论知识，如果对这块知识已经清楚的同学，可以直接跳到实战部分。

1. 消息队列

1.1 消息队列模式

消息队列目前主要 2 种模式，分别为“点对点模式”和“发布/订阅模式”。

点对点模式

一个具体的消息只能由一个消费者消费，多个生产者可以向同一个消息队列发送消息，但是一个消息在被一个消息者处理的时候，这个消息在队列上会被锁住或者被移除并且其他消费者无法处理该消息。

需要额外注意的是，如果消费者处理一个消息失败了，消息系统一般会把这个消息放回队列，这样其他消费者可以继续处理。

发布/订阅模式

单个消息可以被多个订阅者并发的获取和处理。一般来说，订阅有两种类型：

• 临时（ephemeral）订阅：这种订阅只有在消费者启动并且运行的时候才存在。一旦消费者退出，相应的订阅以及尚未处理的消息就会丢失。
• 持久（durable）订阅：这种订阅会一直存在，除非主动去删除。消费者退出后，消息系统会继续维护该订阅，并且后续消息可以被继续处理。

1.2 RabbitMQ 特征

• 消息路由（支持）：RabbitMQ可以通过不同的交换器支持不同种类的消息路由；
• 消息有序（不支持）：当消费消息时，如果消费失败，消息会被放回队列，然后重新消费，这样会导致消息无序；
• 消息时序（非常好）：通过延时队列，可以指定消息的延时时间，过期时间TTL等；
• 容错处理（非常好）：通过交付重试和死信交换器（DLX）来处理消息处理故障；
• 伸缩（一般）：伸缩其实没有非常智能，因为即使伸缩了，master queue还是只有一个，负载还是只有这一个master queue去抗，所以我理解RabbitMQ的伸缩很弱（个人理解）。
• 持久化（不太好）：没有消费的消息，可以支持持久化，这个是为了保证机器宕机时消息可以恢复，但是消费过的消息，就会被马上删除，因为RabbitMQ设计时，就不是为了去存储历史数据的。
• 消息回溯（支持）：因为消息不支持永久保存，所以自然就不支持回溯。
• 高吞吐（中等）：因为所有的请求的执行，最后都是在master queue，它的这个设计，导致单机性能达不到十万级的标准。

2. RabbitMQ 原理初探

RabbitMQ 2007 年发布，是使用 Erlang 语言开发的开源消息队列系统，基