RabbitMQ

一、RabbitMQ能为你做些什么？

消息系统允许软件、应用相互连接和扩展．这些应用可以相互链接起来组成一个更大的应用，或者将用户设备和数据进行连接．消息系统通过将消息的发送和接收分离来实现应用程序的异步和解偶．

或许你正在考虑进行数据投递，非阻塞操作或推送通知。或许你想要实现发布／订阅，异步处理，或者工作队列。所有这些都可以通过消息系统实现。

RabbitMQ是一个消息代理 - 一个消息系统的媒介。它可以为你的应用提供一个通用的消息发送和接收平台，并且保证消息在传输过程中的安全。

1.1 开发中消息队列通常有如下应用场景

1、任务异步处理：
高并发环境下，由于来不及同步处理，请求往往会发生堵塞，比如说，大量的insert，update之类的请求同时到达MySQL，直接导致无数的行锁表锁，甚至最后请求会堆积过多，从而触发too many connections错误。通过使用消息队列，我们可以异步处理请求，从而缓解系统的压力。将不需要同步处理的并且耗时长的操作由消息队列通知消息接收方进行异步处理。减少了应用程序的响应时间。
2、应用程序解耦合：
MQ相当于一个中介，生产方通过MQ与消费方交互，它将应用程序进行解耦合。

1.2 AMQP和JMS

AMQP(高级消息队列协议)是一个网络协议。它支持符合要求的客户端应用(application)和消息中间件代理(messaging middleware broker)之间进行通信。

MQ是消息通信的模型，并发具体实现。现在实现MQ的有两种主流方式：AMQP、JMS。
两者间的区别和联系：
JMS是定义了统一的接口，来对消息操作进行统一；AMQP是通过规定协议来统一数据交互的格式
JMS限定了必须使用Java语言；AMQP只是协议，不规定实现方式，因此是跨语言的。
JMS规定了两种消息模型；而AMQP的消息模型更加丰富。

RabbitMQ是由erlang语言开发，基于AMQP(Advanced Message Queue 高级消息队列协议)协议实现的消息队列，它是一种应用程序之间的通信方法，消息队列在分布式系统开发中应用非常广泛。

二、RabbitMQ工作原理

Broker：消息队列服务进程，此进程包括两个部分：Exchange和Queue
Exchange：消息队列交换机，按一定的规则将消息路由转发到某个队列，对消息进行过虑。
Queue：消息队列，存储消息的队列，消息到达队列并转发给指定的
Producer：消息生产者，即生产方客户端，生产方客户端将消息发送
Consumer：消息消费者，即消费方客户端，接收MQ转发的消息。

三、RabbitMQ的六种消息模型

3.1 基本消息模型

在上图的模型中，有以下概念：
P：生产者，也就是要发送消息的程序
C：消费者：消息的接受者，会一直等待消息到来。
queue：消息队列，图中红色部分。可以缓存消息；生产者向其中投递消息，消费者从其中取出消息。

3.2 work消息模型

work queues与入门程序相比，多了一个消费端，两个消费端共同消费同一个队列中的消息，但是一个消息只能被一个消费者获取。
这个消息模型在Web应用程序中特别有用，可以处理短的HTTP请求窗口中无法处理复杂的任务。
P：生产者：任务的发布者
C1：消费者1：领取任务并且完成任务，假设完成速度较慢(模拟耗时)
C2：消费者2：领取任务并且完成任务，假设完成速度较快

3.3 Publish/subscribe(交换机类型：Fanout，也称为广播 )

和前面两种模式不同：
1) 声明Exchange，不再声明Queue
2) 发送消息到Exchange，不再发送到Queue

publish/subscribe与work queues有什么区别。
区别：
1)work queues不用定义交换机，而publish/subscribe需要定义交换机。
2)publish/subscribe的生产方是面向交换机发送消息，work queues的生产方是面向队列发送消息(底层使用默认交换机)。
3)publish/subscribe需要设置队列和交换机的绑定，work queues不需要设置，实际上work queues会将队列绑定到默认的交换机 。

在前面的工作队列中，每个任务都只会传递给一个消费者。
而在发布/订阅模式下，我们会向多个消费者传递信息。
在这种模式下，发布的消息将被广播给所有的消费者。

3.4 Routing 路由模型(交换机类型：direct)

P：生产者，向Exchange发送消息，发送消息时，会指定一个routing key。
X：Exchange(交换机)，接收生产者的消息，然后把消息递交给 与routing key完全匹配的队列
C1：消费者，其所在队列指定了需要routing key 为 error 的消息
C2：消费者，其所在队列指定了需要routing key 为 info、error、warning 的消息

3.5 Topics 通配符模式(交换机类型：topics)

每个消费者监听自己的队列，并且设置带统配符的routingkey,生产者将消息发给broker，由交换机根据routingkey来转发消息到指定的队列。

Routingkey一般都是有一个或者多个单词组成，多个单词之间以“.”分割，例如：inform.sms

通配符规则：
/#：匹配一个或多个词
*：匹配不多不少恰好1个词

举例：
audit.#：能够匹配audit.irs.corporate 或者 audit.irs
audit.*：只能匹配audit.irs

从示意图可知，我们将发送所有描述动物的消息。消息将使用由三个字(两个点)组成的Routing key发送。路由关键字中的第一个单词将描述速度，第二个颜色和第三个种类：“<speed>.<color>.<species>”。

我们创建了三个绑定：Q1绑定了“.orange.”，Q2绑定了“...rabbit”和“lazy.＃”。

Q1匹配所有的橙色动物。
Q2匹配关于兔子以及懒惰动物的消息。

假如生产者发送如下消息，会进入哪个队列：
quick.orange.rabbit Q1 Q2 routingKey="quick.orange.rabbit"的消息会同时路由到Q1与Q2
lazy.orange.elephant Q1 Q2
quick.orange.fox Q1
lazy.pink.rabbit Q2 (值得注意的是，虽然这个routingKey与Q2的两个bindingKey都匹配，但是只会投递Q2一次)
quick.brown.fox 不匹配任意队列，被丢弃
quick.orange.male.rabbit 不匹配任意队列，被丢弃
orange 不匹配任意队列，被丢弃

3.6 RPC

基本概念：
Callback queue 回调队列，客户端向服务器发送请求，服务器端处理请求后，将其处理结果保存在一个存储体中。而客户端为了获得处理结果，那么客户在向服务器发送请求时，同时发送一个回调队列地址reply_to。

Correlation id 关联标识，客户端可能会发送多个请求给服务器，当服务器处理完后，客户端无法辨别在回调队列中的响应具体和那个请求时对应的。为了处理这种情况，客户端在发送每个请求时，同时会附带一个独有correlation_id属性，这样客户端在回调队列中根据correlation_id字段的值就可以分辨此响应属于哪个请求。

流程说明：
当客户端启动的时候，它创建一个匿名独享的回调队列。
在 RPC 请求中，客户端发送带有两个属性的消息：一个是设置回调队列的 reply_to 属性，另一个是设置唯一值的 correlation_id 属性。
将请求发送到一个 rpc_queue 队列中。
服务器等待请求发送到这个队列中来。当请求出现的时候，它执行他的工作并且将带有执行结果的消息发送给 reply_to 字段指定的队列。
客户端等待回调队列里的数据。当有消息出现的时候，它会检查 correlation_id 属性。如果此属性的值与请求匹配，将它返回给应用。

四、两个知识点

避免消息堆积？
1) 采用workqueue，多个消费者监听同一队列。
2)接收到消息以后，而是通过线程池，异步消费。

如何避免消息丢失？
1) 消费者的ACK机制。可以防止消费者丢失消息。
但是，如果在消费者消费之前，MQ就宕机了，消息就没了？
2)可以将消息进行持久化。要将消息持久化，前提是：队列、Exchange都持久化

转载文章RabbitMQ快速入门(详细)