RabbitMQ

简介：

MQ全称为Message Queue，消息队列（MQ）是⼀种应用程序对应用程序的通信方法。应用程序通过读写出入队列的消息（针对应用程序的数据）来通信，而无需专用连接来链接它们。消息传递指的是程序之间通过在消息中发送数据进行通信，而不是通过直接调用彼此来通信，直接调用通常是用于诸如远程过程调用的技术。

排队指的是应用程序通过队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求。其中较为成熟的MQ产品有IBM WEBSPHERE MQ等等。 ​

RabbitMQ是⼀个在AMQP基础上完成的，可复用的企业消息系统。他遵循Mozilla Public License开源协议。 ​ AMQP，即Advanced Message Queuing Protocol，⼀个提供统⼀消息服务的应用层标准⾼级消息队列协议，是应用层协议的⼀个开放标准，为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同的开发语⾔等条件的限制。Erlang中的实现RabbitMQ等。

spring 对 amqp 做了支持，但是当前只实现了 rabbitmq 。

rabbitmq、rocketmq、activemq、kafka（处理大数据比较好）：消息队列

可以把消息队列理解为邮局：

queue：Many producers can send messages that go to one queue and many consumers can try to receive data from one queue.

消息

• 简单模式

In the diagram below, "P" is our producer and "C" is our consumer. The box in the middle is a queue - a message buffer that RabbitMQ keeps on behalf of the consumer.

Our overall design will look like：

生产者将消息发到队列，消费者从队列中取消息；一条消息对应一个消费者

• work模式

In the first tutorial we wrote programs to send and receive messages from a named queue. In this one we'll create a Work Queue that will be used to distribute time-consuming tasks among multiple workers.

一条消息可以被多个消费者尝试接收，但是最终只能有一个消费者获取

消息的确认模式：

模式1：自动模式，不管消费者后获取到消息后是否成功处理消息，服务端都认为是成功的

模式2：手动模式，消费者获取到消息后，服务器会将消息标记为不可用，等待消费者反馈，如果不反馈，则一直标记为不可用

• 订阅模式

Instead, the producer can only send messages to an exchange. An exchange is a very simple thing. On one side it receives messages from producers and the other side it pushes them to queues. The exchange must know exactly what to do with a message it receives.

一条消息可以被多个消费者同时获取

生产者将消息发送到交换机，消费者将自己对应的队列注册到交换机，当发送消息后，所有注册的队列的消费者都可以收到消息

• 路由模式：

In this setup, we can see the direct exchange X with two queues bound to it. The first queue is bound with binding key orange, and the second has two bindings, one with binding key black and the other one with green.

生产者将消息发送到了 type 为 direct 模式的交换机，消费者的队列在将自己绑定到路由的时候会给自己绑定一个 key，只有消费者发送对应 key 格式的消息的时候，队列才会收到消息。如果监听了相同的 key，可以一起收到消息

• 通配符模式

• * (star) can substitute for exactly one word.
• # (hash) can substitute for zero or more words.

将路由键和某模式进行匹配，此时队列需要绑定到一个模式上，符号“#”匹配一个或多个词，符号“*”匹配一个词

eg：“audit.#” 能够匹配到“audit.irs.corporate”，但是“audit.*”只会匹配到“audit.irs”

• RPC 模式：

• When the Client starts up, it creates an anonymous exclusive callback queue.
• For an RPC request, the Client sends a message with two properties: reply_to, which is set to the callback queue and correlation_id, which is set to a unique value for every request.
• The request is sent to an rpc_queue queue.
• The RPC worker (aka: server) is waiting for requests on that queue. When a request appears, it does the job and sends a message with the result back to the Client, using the queue from the reply_to field.
• The client waits for data on the callback queue. When a message appears, it checks the correlation_id property. If it matches the value from the request it returns the response to the application.

生产者发送一条带有标签（消息ID（correlation_id）+回调队列名称）的消息到发送队列，消费者（也称RPC服务端）从发送队列获取消息并处理业务，解析标签的信息将业务结果发送到指定的回调队列，生产者从回调队列中根据标签的信息获取发送消息的返回结果。 

• 总结：

Simple Queues 和 Work Queues 本质上都是解决 生产者（集群） 和 消费者（集群）一对一的问题。只是 Simple Queues 只能有一个消费者，Work Queues 可以有多个。但两者都是处理同一队列。

Publish/Subscribe 和 Routing 乃至 Topics 都是处理 生产者（集群） 和 消费者（集群）一对多的问题。Publish/Subscribe 只能为多消费者提供相同数据，可以对消费者承载量进行设置，但对不同消费者没有数据区分，可以给同一集群的多缓存服务器同时更新数据，也可以在数据更新时做搜索服务器和 redis 服务器的数据同步。Routing 增加了对不同消费者有不同的数据区分的功能，更加灵活，可以使搜索服务器和 redis 服务器同步更新不同数据。Topics 在功能上做了进一步加强，在数据分流时引入通配符。

以上皆为单向的消息传递，生产者将消息发送给消费者之后就不再管后续的业务处理了。实际业务中，有的时候我们还需要等待消费者返回结果给我们，或者是说我们需要消费者上的一个功能、一个方法或是一个接口返回给我们相应的值，而往往大型的系统软件，生产者跟消费者之间都是相互独立的两个系统，部署在两个不同的电脑上，不能通过直接对象调用的方法的形式获取想要的结果，这时候我们就需要用到RPC（Remote Procedure Call）远程过程调用方式。