RabbitMQ 高级指南

1 RabbitMQ 简介
1.1 介绍
　　RabbitMQ 是一个由 erlang 开发的基于 AMQP（Advanced Message Queue）协议的开源实现。用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面都非常的优秀，是当前最主流的消息中间件之一。RabbitMQ 官网：http://www.rabbitmq.com

1.2 AMQP
　　AMQP 是应用层协议的一个开放标准，为面向消息的中间件设计。消息中间件主要用于组件之间的解耦，消息的发送者无需知道消息使用者的存在，同样，消息使用者也不用知道发送者的存在。AMQP 的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。

1.3 系统架构

消息队列的使用过程大概如下：

客户端连接到消息队列服务器，打开一个 channel；
客户端声明一个 exchange，并设置相关属性；
客户端声明一个 queue，并设置相关属性；
客户端使用 routing key，在 exchange 和 queue 之间建立好绑定关系；
客户端投递消息到 exchange，exchange 接收到消息后，就根据消息的 key 和已经设置的 binding，进行消息路由，将消息投递到一个或多个队列里。
如上图所示：AMQP 里主要说两个组件，Exchange 和 Queue。绿色的X就是 Exchange ，红色的是 Queue ，这两者都在 Server 端，又称作 Broker，这部分是 RabbitMQ 实现的，而蓝色的则是客户端，通常有 Producer 和 Consumer 两种类型。

1.4 几个概念
P： 为 Producer，数据的发送方；
C：为 Consumer，数据的接收方；
Exchange：消息交换机，它指定消息按什么规则，路由到哪个队列；
Queue：消息队列载体，每个消息都会被投入到一个或多个队列；
Binding：绑定，它的作用就是把 exchange 和 queue 按照路由规则绑定起来；
Routing Key：路由关键字，exchange 根据这个关键字进行消息投递；
vhost：虚拟主机，一个 broker 里可以开设多个 vhost，用作不同用户的权限分离；
channel：消息通道，在客户端的每个连接里，可建立多个 channel，每个 channel 代表一个会话任务。

4 四种 Exchange 模式
　　AMQP 协议中的核心思想就是：生产者和消费者隔离，生产者从不直接将消息发送给队列。生产者通常不知道是否一个消息会被发送到队列中，只是将消息发送到一个交换机。先由 Exchange 来接收，然后 Exchange 按照特定的策略转发到 Queue 进行存储。同理，消费者也是如此。Exchange 就类似于一个交换机，转发各个消息分发到相应的队列中。

　　RabbitMQ 提供了四种 Exchange 模式：fanout、direct、topic、header. 由于 header 模式在实际使用中较少，因此本节只对前三种模式进行比较。

4.1 Fanout Exchange

所有发送到 Fanout Exchange 的消息都会被转发到与该 Exchange 绑定（Binding）的所有 Queue 上。

Fanout Exchange 不需要处理 RouteKey，只需要简单的将队列绑定到 exchange 上，这样发送到 exchange 的消息都会被转发到与该交换机绑定的所有队列上。类似子网广播，每台子网内的主机都获得了一份复制的消息。

所以，Fanout Exchange 转发消息是最快的。

4.2 Direct Exchange

所有发送到 Direct Exchange 的消息被转发到 RouteKey 中指定的 Queue.

Direct 模式可以使用 RabbitMQ 自带的 Exchange：default Exchange ，因此不需要将 Exchange 进行任何绑定（binding）操作 。消息传递时，RouteKey 必须完全匹配，才会被队列接收，否则该消息会被抛弃。

4.3 Topic Exchange

所有发送到 Topic Exchange 的消息被转发到所有关心 RouteKey 中指定 Topic 的 Queue 上，Exchange 将 RouteKey 和某 Topic 进行模糊匹配。此时队列需要绑定一个 Topic，可以使用通配符进行模糊匹配，符号#匹配一个或多个词，符号匹配不多不少一个词。因此log.#能够匹配到log.info.oa，但是log. 只会匹配到log.error.

所以，Topic Exchange 使用非常灵活。

5 RPC 远程过程调用
　　在这一节中，主要讲述 RabbitMQ RPC. 其实，RabbitMQ RPC 就是通过消息队列（Message Queue）来实现 RPC 的功能，就是客户端向服务端发送定义好的 Queue 消息，其中携带的消息就应该是服务端将要调用的方法的参数 ，并使用 Propertis 告诉服务端将结果返回到指定的 Queue.

5.1 RabbitMQ RPC 的特点
Message Queue 把所有的请求消息存储起来，然后处理，和客户端解耦；
Message Queue 引入新的结点，系统的可靠性会受 Message Queue 结点的影响；
Message Queue 是异步单向的消息。发送消息设计成是不需要等待消息处理的完成。
所以对于有同步返回需求的，Message Queue 是个不错的方向。

5.2 普通 PRC 的特点
同步调用，对于要等待返回结果/处理结果的场景，RPC 是可以非常自然直觉的使用方式，当然 RPC 也可以是异步调用；
由于等待结果，客户端会有线程消耗。
如果以异步 RPC 的方式使用，客户端线程消耗可以去掉，但不能做到像消息一样暂存消息请求，压力会直接传导到服务端。

5.3 适用场合说明
希望同步得到结果的场合，RPC 合适。
希望使用简单，则 RPC；RPC 操作基于接口，使用简单，使用方式模拟本地调用。异步的方式编程比较复杂。
不希望客户端受限于服务端的速度等，可以使用 Message Queue.
5.4 RabbitMQ RPC工作流程

基本概念：

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

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

流程说明：

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