RabbitMQ

RabbitMQ

本篇代码没有怎么贴，官网上都有，水一下字数

MQ

在计算机科学中，消息队列（英语：Message queue）是一种进程间通信或同一进程的不同线程间的

通信方式，软件的贮列用来处理一系列的输入，通常是来自用户。消息队列提供了异步的通信协议，每

一个贮列中的纪录包含详细说明的数据，包含发生的时间，输入设备的种类，以及特定的输入参数，也

就是说：消息的发送者和接收者不需要同时与消息队列互交。消息会保存在队列中，直到接收者取回

它。

实现

消息队列常常保存在链表结构中。拥有权限的进程可以向消息队列中写入或读取消息。

目前，有很多消息队列有很多开源的实现，包括 JBoss Messaging 、 JORAM 、 Apache ActiveMQ 、 Sun Open Message Queue 、 IBM MQ 、 Apache Qpid 和 HTTPSQS 。

当前使用较多的消息队列有 RabbitMQ 、 RocketMQ 、 ActiveMQ 、 Kafka 、 ZeroMQ 、 MetaMq等，而部分数据库如 Redis 、 Mysql 以及 phxsql 也可实现消息队列的功能。

特点

MQ是消费者-生产者模型的一个典型的代表，一端往消息队列中不断写入消息，而另一端则可以读取或者订阅队列中的消息。MQ和JMS类似，但不同的是JMS是SUN JAVA消息中间件服务的一个标准和API定义，而MQ则是遵循了AMQP协议的具体实现和产品。

注意：

1. AMQP ，即Advanced Message Queuing Protocol,一个提供统一消息服务的应用层标准高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同的开发语言等条件的限制。

2. JMS ，Java消息服务（Java Message Service）应用程序接口，是一个Java平台中关于面向消息中间件的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。 Java消息服务是一个与具体平台无关的API，绝大多数MOM提供商都对JMS提供支持。常见的消息队列，大部分都实现了JMS API，如 ActiveMQ ， Redis 以及 RabbitMQ 等。

优点

异步：

​ 注册的例子，发邮件通知通知用户正在注册，这里我们另外开个线程发邮件，主线程执行注册业务。这样整个业务速度就快了。

解耦：

​ 把东西放在消息队列里，不用改代码，想要什么东西拿什么。

削峰：

​ 比如数据库的QPS是1000，这时有10000个请求过来数据库承受不住，这时使用队列里使用特定的策略，使消费速度（数据查询速率）维持在数据库承受范围内。

场景

消息队列，是分布式系统中重要的组件，其通用的使用场景可以简单地描述为：当不需要立即获得结果，但是并发量又需要进行控制的时候，差不多就是需要使用消息队列的时候

在项目中，将一些无需即时返回且耗时的操作提取出来，进行了异步处理，而这种异步处理的方式大大的节省了服务器的请求响应时间，从而提高了系统的吞吐量。

RabbitMQ优势

​ AMQP，即Advanced Message Queuing Protocol，高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。消息中间件主要用于组件之间的解耦，消息的发送者无需知道消息使用者的存在，反之亦然。

​ AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。

RabbitMQ是一个开源的AMQP实现，服务器端用Erlang语言编写，支持多种客户端，如： Python 、 Ruby 、 .NET 、 Java 、 JMS 、 C 、 PHP 、 ActionScript 、 XMPP 、 STOMP 等，支持AJAX。用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。

总结如下：

基于AMQP协议

高并发(是一个容量的概念，服务器可以接受的最大任务数量)高性能(是一个速度的概念，单位时间内服务器可以处理的任务数)

高可用(是一个持久的概念，单位时间内服务器可以正常工作的时间比例)

强大的社区支持，以及很多公司都在使用

支持插件

支持多语言

安装

1. 下载rabbitmq 的rpm包，官网下载地址：http://www.rabbitmq.com/download.html ：rabbitmq-server-3.8.5-1.el7.noarch.rpm

2. 下载erlang的rpm包，https://www.erlang-solutions.com/resources/download.html：esl-erlang_23.0.2-1_centos_7_amd64.rpm

3. 安装：

   yum -y install esl-erlang_23.0.2-1_centos_7_amd64.rpm
   //测试erlang安装成功
   erl
   exit
   
   //安装兔子消息队列
   yum -y install rabbitmq-server-3.8.5-1.el7.noarch.rpm
   //ui插件
   rabbitmq-plugins enable rabbitmq_management
   
   //开启服务,访问ip:15670,远程访问开启端口5672，15672，访问ip：15672到兔子消息队列管理页面
   systemctl start rabbitmq-server.service
   //账号密码guest   guest，开启账号远程登录
   //  /etc/rabbitmq/rabbitmq.config文件新建并插入下列内容
   [{rabbit, [{loopback_users, []}]}].
   
   
   //重启消息队列
   syystemctl restartrabbitmq-server.service
   

概念

用户

相当数据库角色

RabbitMQ角色分类

none:不能访问 management plugin（管理插件）

impersonator:演员？？？

**management:**用户可以通过AMQP做的任何事外加：

列出自己可以通过AMQP登入的virtual hosts

查看自己的virtual hosts中的queues, exchanges 和 bindings

查看和关闭自己的channels 和 connections

查看有关自己的virtual hosts的“全局”的统计信息，包含其他用户在这些virtual hosts中的活

动。

policymaker

management可以做的任何事外加：

查看、创建和删除自己的virtual hosts所属的policies和parameters

monitoring

management可以做的任何事外加：

列出所有virtual hosts，包括他们不能登录的virtual hosts

查看其他用户的connections和channels

查看节点级别的数据如clustering和memory使用情况

查看真正的关于所有virtual hosts的全局的统计信息

administrator

policymaker和monitoring可以做的任何事外加:

创建和删除virtual hosts

查看、创建和删除users

查看创建和删除permissions

关闭其他用户的connections

虚拟主机

相当于数据库

Producing

Producing意思不仅仅是发送消息。发送消息的程序叫做producer生产者。

Queue

Queue是一个消息盒子的名称。它存活在 RabbitMQ 里。虽然消息流经 RabbitMQ 和你的应用程序，但

是他们只能在 Queue 里才能被保存。Queue 没有任何边界的限制，你想存多少消息都可以，它本质上是

一个无限的缓存。许多生产者都可以向一个 Queue 里发送消息，许多消费者都可以从一个 Queue 里接

收消息。

Consuming

Consuming 的意思和接收类似。等待接收消息的程序叫做消费者。

ConnectionFactory、Connection、Channel

ConnectionFactory 、 Connection 、 Channel 都是RabbitMQ对外提供的API中最基本的对象。

Connection 是RabbitMQ的 socket 连接，它封装了 socket 协议相关部分逻辑。

ConnectionFactory 为Connection的制造工厂。

Channel 是我们与RabbitMQ打交道的最重要的一个接口，我们大部分的业务操作是在Channel这个接口

中完成的，包括定义 Queue 、定义 Exchange 、绑定 Queue 与 Exchange 、发布消息等。

Message acknowledgment

在实际应用中，可能会发生消费者收到 Queue 中的消息，但没有处理完成就宕机（或出现其他意

外）的情况，这种情况下就可能会导致消息丢失。为了避免这种情况发生，我们可以要求消费者在消费

完消息后发送一个回执给RabbitMQ，RabbitMQ收到消息回执（ Message acknowledgment ）后才将该

消息从 Queue 中移除；如果RabbitMQ没有收到回执并检测到消费者的RabbitMQ连接断开，则RabbitMQ

会将该消息发送给其他消费者（如果存在多个消费者）进行处理。这里不存在timeout概念，一个消费

者处理消息时间再长也不会导致该消息被发送给其他消费者，除非它的RabbitMQ连接断开。

这里会产生另外一个问题，如果我们的开发人员在处理完业务逻辑后，忘记发送回执给RabbitMQ，这

将会导致严重的bug—— Queue 中堆积的消息会越来越多；消费者重启后会重复消费这些消息并重复执

行业务逻辑…

Message durability

如果我们希望即使在RabbitMQ服务重启的情况下，也不会丢失消息，我们可以将Queue与Message都

设置为可持久化的（durable），这样可以保证绝大部分情况下我们的RabbitMQ消息不会丢失。但依然

解决不了小概率丢失事件的发生（比如RabbitMQ服务器已经接收到生产者的消息，但还没来得及持久化

该消息时RabbitMQ服务器就断电了），如果我们需要对这种小概率事件也要管理起来，那么我们要用到

事务。

Prefetch count

前面我们讲到如果有多个消费者同时订阅同一个 Queue 中的消息， Queue 中的消息会被平摊给多个

消费者。这时如果每个消息的处理时间不同，就有可能会导致某些消费者一直在忙，而另外一些消费者

很快就处理完手头工作并一直空闲的情况。我们可以通过设置 prefetchCount 来限制 Queue 每次发送

给每个消费者的消息数，比如我们设置prefetchCount=1，则 Queue 每次给每个消费者发送一条消息；

消费者处理完这条消息后 Queue 会再给该消费者发送一条消息。

Exchange

生产者将消息投递到 Queue 中，实际上这在RabbitMQ中这种事情永远都不会发生。实际的情况是，

生产者将消息发送到Exchange（交换器，下图中的X），由Exchange将消息路由到一个或多个 Queue 中

（或者丢弃）。

Exchange是按照什么逻辑将消息路由到 Queue 的？这个将在Binding一节介绍。

RabbitMQ中的Exchange有四种类型，不同的类型有着不同的路由策略，这将在Exchange Types一节介

绍。

routing key

生产者在将消息发送给Exchange的时候，一般会指定一个 routing key ，来指定这个消息的路由规

则，而这个 routing key 需要与 Exchange Type 及 binding key 联合使用才能最终生效。

在 Exchange Type 与 binding key 固定的情况下（在正常使用时一般这些内容都是固定配置好

的），我们的生产者就可以在发送消息给Exchange时，通过指定 routing key 来决定消息流向哪里。

RabbitMQ为 routing key 设定的长度限制为255 bytes。

Binding

RabbitMQ中通过Binding将Exchange与Queue关联起来，这样RabbitMQ就知道如何正确地将消息路由到

指定的Queue了。

Binding key

在绑定（Binding）Exchange与 Queue 的同时，一般会指定一个 binding key ；消费者将消息发送

给Exchange时，一般会指定一个 routing key ；当 binding key 与 routing key 相匹配时，消息将

会被路由到对应的Queue中。这个将在Exchange Types章节会列举实际的例子加以说明。

在绑定多个Queue到同一个Exchange的时候，这些Binding允许使用相同的 binding key 。

binding key 并不是在所有情况下都生效，它依赖于Exchange Type，比如 fanout 类型的Exchange

就会无视 binding key ，而是将消息路由到所有绑定到该Exchange的Queue。

Exchange Types

RabbitMQ常用的Exchange Type有 fanout 、 direct 、 topic 、 headers 这四种（AMQP规范里还

提到两种Exchange Type，分别为 system 与 自定义 ，这里不予以描述），下面分别进行介绍。

**fanout：**广播模式

交换机将收到的所以消息给绑定的所以队列

direct：

direct 类型的Exchange路由规则也很简单，它会把消息路由到那些 binding key 与 routing

key 完全匹配的Queue中。

以上图的配置为例，我们以 routingKey=”error” 发送消息到Exchange，则消息会路由到Queue1（amqp.gen-S9b…，这是由RabbitMQ自动生成的Queue名称）和Queue2（amqp.gen-Agl…）；如果我们以 routingKey=”info” 或 routingKey=”warning” 来发送消息，则消息只会路由到Queue2。

如果我们以其他routingKey发送消息，则消息不会路由到这两个Queue中。

topic

前面讲到direct类型的Exchange路由规则是完全匹配 binding key 与 routing key ，但这种严格的

匹配方式在很多情况下不能满足实际业务需求。topic类型的Exchange在匹配规则上进行了扩展，它与

direct类型的Exchage相似，也是将消息路由到 binding key 与 routing key 相匹配的Queue中，但这

里的匹配规则有些不同，它约定：

routing key为一个句点号 . 分隔的字符串（我们将被句点号 . 分隔开的每一段独立的字符串称为

一个单词），如“stock.usd.nyse”、“nyse.vmw”、“quick.orange.rabbit”

binding key与routing key一样也是句点号 . 分隔的字符串

binding key中可以存在两种特殊字符 * 与 # ，用于做模糊匹配，其中 * 用于匹配一个单词， # 用

于匹配多个单词（可以是零个）

以上图中的配置为例，routingKey=”quick.orange.rabbit”的消息会同时路由到Q1与Q2，routingKey=”lazy.orange.fox”的消息会路由到Q1，routingKey=”lazy.brown.fox”的消息会路由到Q2，routingKey=”lazy.pink.rabbit”的消息会路由到Q2（只会投递给Q2一次，虽然这个routingKey与Q2的两个bindingKey都匹配）；routingKey=”quick.brown.fox”、routingKey=”orange”、routingKey=”quick.orange.male.rabbit”的消息将会被丢弃，因为它们没有匹配任何bindingKey。

headers：

headers类型的Exchange不依赖于 routing key 与 binding key 的匹配规则来路由消息，而是根据

发送的消息内容中的headers属性进行匹配。

在绑定Queue与Exchange时指定一组键值对；当消息发送到Exchange时，RabbitMQ会取到该消息的

headers（也是一个键值对的形式），对比其中的键值对是否完全匹配Queue与Exchange绑定时指定的键

值对；如果完全匹配则消息会路由到该Queue，否则不会路由到该Queue。

RPC

MQ本身是基于异步的消息处理，前面的示例中所有的生产者（P）将消息发送到RabbitMQ后不会知道

消费者（C）处理成功或者失败（甚至连有没有消费者来处理这条消息都不知道）。

但实际的应用场景中，我们很可能需要一些同步处理，需要同步等待服务端将我的消息处理完成后再

进行下一步处理。这相当于RPC（Remote Procedure Call，远程过程调用）。在RabbitMQ中也支持RPC。

RabbitMQ中实现RPC的机制是：

客户端发送请求（消息）时，在消息的属性（ MessageProperties ，在AMQP协议中定义了14种

properties，这些属性会随着消息一起发送）中设置两个值 replyTo （一个Queue名称，用于告诉

服务器处理完成后将通知我的消息发送到这个Queue中）和 correlationId （此次请求的标识

号，服务器处理完成后需要将此属性返还，客户端将根据这个id了解哪条请求被成功执行了或执行

失败）

服务器端收到消息并处理

服务器端处理完消息后，将生成一条应答消息到 replyTo 指定的Queue，同时带上

correlationId 属性

客户端之前已订阅 replyTo 指定的Queue，从中收到服务器的应答消息后，根据其中的

correlationId 属性分析哪条请求被执行了，根据执行结果进行后续业务处理

简单队列模式

在这部分的使用指南中，我们要用 Java 写两个程序；一个是生产者，他发送一个消息，另一个是消

费者，它接收消息，并且把消息打印出来。我们将会忽略一些Java API 的细节，而是将注意力主要放在

我们将要做的这件事上，这件事就是发送一个 “Hello World” 消息。

在下面的图中，“P” 代表生产者，而 “C” 代表消费者。中间的就是一个 Queue，一个消息缓存区。

代码实例：

<!-- rabbitmq依赖 -->
<dependency> 
<groupId>com.rabbitmq</groupId> 
<artifactId>amqp-client</artifactId>
<version>5.10.0</version> 
</dependency>

sending

生产者，发送完消息连接就会被关闭

/*** 
简单模式队列-消息发送者 
*/
public class Send { 
// 队列名称 
private final static String QUEUE_NAME = "hello"; 
public static void main(String[] args) { 
// 创建连接工厂
ConnectionFactory factory = new ConnectionFactory();
factory.setHost("192.168.10.100");
factory.setPort(5672);
factory.setUsername("shop");
factory.setPassword("shop");
factory.setVirtualHost("/shop");
Connection connection = null;
Channel channel = null;
try {
// 通过工厂创建连接
connection = factory.newConnection();
// 获取通道
channel = connection.createChannel();
/**
* 声明队列
* 第一个参数queue：队列名称
* 第二个参数durable：是否持久化
* 第三个参数Exclusive：排他队列，如果一个队列被声明为排他队列，该队列仅对首次声明它
的连接可见，并在连接断开时自动删除。
* 这里需要注意三点：
* 1. 排他队列是基于连接可见的，同一连接的不同通道是可以同时访问同一个连接创
建的排他队列的。
* 2. "首次"，如果一个连接已经声明了一个排他队列，其他连接是不允许建立同名的
排他队列的，这个与普通队列不同。
* 3. 即使该队列是持久化的，一旦连接关闭或者客户端退出，该排他队列都会被自动
删除的。
* 这种队列适用于只限于一个客户端发送读取消息的应用场景。
* 第四个参数Auto-delete：自动删除，如果该队列没有任何订阅的消费者的话，该队列会被自
动删除。
* 这种队列适用于临时队列。
*/
channel.queueDeclare(QUEUE_NAME, false, false, false, null);
// 创建消息
String message = "Hello World!";
// 将产生的消息放入队列
channel.basicPublish("", QUEUE_NAME, null, message.getBytes("UTF-8"));
System.out.println(" [x] Sent '" + message + "'");
} catch (IOException e) {
e.printStackTrace();
} catch (TimeoutException e) {
e.printStackTrace();
} finally {
try {
// 关闭通道
if (null != channel && channel.isOpen())
channel.close();
// 关闭连接
if (null != connection && connection.isOpen())
connection.close();
} catch (TimeoutException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
}
}
}

Receiving

消息的发送者只是发送一个消息，我们的接收者需要不断的监听消息，并把它们打印出来。

import com.rabbitmq.client.*;
import java.io.IOException;
import java.util.concurrent.TimeoutException;
/**
* 简单模式队列-消息接收者
*/
public class Recv {
// 队列名称
private final static String QUEUE_NAME = "hello";
public static void main(String[] args) {
// 创建连接工厂
ConnectionFactory factory = new ConnectionFactory();
factory.setHost("127.0.0.1");
factory.setPort(5672);
factory.setUsername("shop");
factory.setPassword("shop");
factory.setVirtualHost("/shop");
try {
// 通过工厂创建连接
Connection connection = factory.newConnection();
// 获取通道
Channel channel = connection.createChannel();
// 指定队列
channel.queueDeclare(QUEUE_NAME, false, false, false, null);
System.out.println(" [*] Waiting for messages. To exit press CTRL+C");
// ---------------------之前旧版本的写法-------begin-----------
/*
// 获取消息
Consumer consumer = new DefaultConsumer(channel) {
@Override
public void handleDelivery(String consumerTag, Envelope envelope,
AMQP.BasicProperties properties,
byte[] body) throws IOException {
// 获取消息并在控制台打印
String message = new String(body, "utf-8");
System.out.println(" [x] Received '" + message + "'");
}
};
// 监听队列
channel.basicConsume(QUEUE_NAME, true, consumer);
*/
// ---------------------之前旧版本的写法--------end------------
// 获取消息
DeliverCallback deliverCallback = (consumerTag, delivery) -> {
String message = new String(delivery.getBody(), "UTF-8");
System.out.println(" [x] Received '" + message + "'");
};
// 监听队列
channel.basicConsume(QUEUE_NAME, true, deliverCallback, consumerTag -> {
});
} catch (IOException e) {
e.printStackTrace();
} catch (TimeoutException e) {
e.printStackTrace();
}
}
}

总结：

问题：如果任务量很大，消息得不到及时的消费会造成队列积压，问题非常严重，比如内存溢出，消

息丢失等。

解决：配置多个消费者消费消息。

总结：简单队列-处理消息效率不高，吞吐量较低，不适合生成环境

Work queues-工作模式队列

消息轮询分发(Round-robin)：公平分配

通过Helloworld工程我们已经能够构建一个简单的消息队列的基本项目，项目中存在几个角色:生产者、消费者、队列，而对于我们真实的开发中，对于消息的消费者通过是有多个的，比如在实现用户注册功能时，用户注册成功，会给响对应用户发送邮件，同时给用户发送手机短信，告诉用户已成功注册网站或者app 应用，这种功能在大部分项目开发中都比较常见，而对于helloworld 的应用中虽然能够对消息进行消费，但是有很大问题:消息消费者只有一个，当消息量非常大时，单个消费者处理消息就会变得很慢，同时给节点页带来很大压力，导致消息堆积越来越多。对于这种情况，RabbitMQ 提供了工作队列模式，通过工作队列提供做个消费者，对MQ产生的消息进行消费，提高MQ消息的吞吐率，降低消息的处理时间。处理模型图如下

这里RabitMQ采用轮询来对消息进行分发时保证了消息被平均分配到每个消费方，但是引入新的问题:真正的生产环境下，对于消息的处理基本不会像我们现在看到的这样，每个消费方处理的消息数量是平均分配的，比如因为网络原因，机器cpu,内存等硬件问题，消费方处理消息时同类消息不同机器进行处理时消耗时间也是不一样的，比如1号消费者消费1条消息时1秒，2号消费者消费1条消息是5秒，对于1号消费者比2号消费者处理消息快，那么在分配消息时就应该让1号消费者多收到消息进行处理，也即是我们通常所说的”能者多劳”,同样Rabbitmq对于这种消息分配模式提供了支持。

问题：任务量很大，消息虽然得到了及时的消费，单位时间内消息处理速度加快，提高了吞吐量，可是不同消费者处理消息的时间不同，导致部分消费者的资源被浪费。

解决：采用消息公平分发。

总结：工作队列-消息轮询分发-消费者收到的消息数量平均分配，单位时间内消息处理速度加快，提高了吞吐量。

消息公平分发(fair dispatch)：能者多劳

在轮询中对于消息分发采用的是默认轮询分发，消息应答采用的自动应答模式，这是因为当消息进入队列，RabbitMQ就会分派消息。它不看消费者为应答的数目，只是盲目的将第n条消息发给第n个消费者。

为了解决这个问题，我们使用 basicQos(prefetchCount = 1) 方法，来限制RabbitMQ只发不超过1条的消息给同一个消费者。当消息处理完毕后，有了反馈，才会进行第二次发送。执行模型图如下:

问题：生产者产生的消息只可以被一个消费者消费，可不可以被多个消费者消费呢？

解决：采用发布与订阅模式。

总结：工作队列-公平轮询分发-根据不同消费者机器硬件配置，消息处理速度不同，收到的消息数量

也不同，通常速度快的处理的消息数量比较多，最大化使用计算机资源。适用于生成环境。

工作模式队列

消息的发布与订阅模式队列fanout

对于微信公众号，相信每个人都订阅过，当公众号发送新的消息后，对于订阅过该公众号的所有用户均可以收到消息，这个场景大家都能明白，同样对于RabbitMQ消息的处理也支持这种消息处理，当生产者把消息投送出去后，不同的消费者均可以对该消息进行消费，而不是消息被一个消费者消费后就立即从队列中删除，对于这种消息处理，我们通常称之为消息的发布与订阅模式，凡是消费者订阅了该消息，均能够收到对应消息进行处理，比较常见的如用户注册操作。模型图如下:

从图中看到:

消息产生后不是直接投送到队列中，而是将消息先投送给Exchange交换机，然后消息经过Exchange交换机投递到相关队列多个消费者消费的不再是同一个队列，而是每个消费者消费属于自己的队列

问题：生产者产生的消息所有消费者都可以消费，可不可以指定某些消费者消费呢？

解决：采用direct路由模式。

路由模式队列direct

通常在真正项目开发时会遇到这种情况:在对项目信息输出日志进行收集时，会把日志(error warning,info)分类进行输出，这时通过Exchange Types中的 direct 类型就可以实现，针对不同的消息，在对消息进行消费时，通过 Exchange types 以及 Routing key 设置的规则 ，便可以将不同消息路由到不同的队列中然后交给不同消费者进行消费操作。

从图中可以看出:

1. 生产者产生的消息投给交换机

2. 交换机投送消息时的Exchange Types为direct类型3. 消息通过定义的Routing Key被路由到指定的队列进行后续消费

问题：生产者产生的消息如果场景需求过多需要设置很多路由规则，可不可以减少？

解决：采用topic主题模式。

主题模式队列topic

于RabbitMq 除了 direct 模式外，Mq 同样还提供了 topics 主题模式来对消息进行匹配路由，比如在项目开发中，拿商品模块来说，对于商品的查询功能在对商品进行查询时我们将查询消息路由到查询对应队列，而对于商品的添加、更新、删除等操作我们统一路由到另外一个队列来进行处理，此时采用direct 模式可以实现，但对于维护的队列可能就不太容易进行维护，如果涉及模块很多，此时对应队列数量就很多，此时我们就可以通过 topic 主题模式来对消息路由时进行匹配，通过指定的匹配模式将消息路由到匹配到的队列中进行后续处理。对于routing key匹配模式定义规则举例如下:

routing key为一个句点号 . 分隔的字符串（我们将被句点号 . 分隔开的每一段独立的字符串称为一个单词），如“stock.usd.nyse”、“nyse.vmw”、“quick.orange.rabbit” routing key中可以存在两种特殊字符 * 与 # ，用于做模糊匹配，其中 * 用于匹配一个词， # 用于匹配多个单词（可以是零个）

例如:

以上图中的配置为例：

routingKey=”quick.orange.rabbit”的消息会同时路由到Q1与Q2，

routingKey=”lazy.orange.fox”的消息会路由到Q1，Q2,

routingKey=”lazy.brown.fox”的消息会路由到Q2，

routingKey=”lazy.pink.rabbit”的消息会路由到Q2；

routingKey=”quick.brown.fox”;

routingKey=”orange”;

routingKey=”quick.orange.male.rabbit”的消息将会被丢弃，因为它们没有匹配任何bindingKey。

问题：RabbitMQ本身是基于异步的消息处理，是否可以同步实现？

解决：采用RPC模式。

RPC-远程过程调用模式队列

MQ本身是基于异步的消息处理，前面的示例中所有的生产者（P）将消息发送到RabbitMQ后不会知道消费者（C）处理成功或者失败（甚至连有没有消费者来处理这条消息都不知道）。

但实际的应用场景中，我们很可能需要一些同步处理，需要同步等待服务端将我的消息处理完成后再进行下一步处理。这相当于RPC（Remote Procedure Call，远程过程调用）。在RabbitMQ中也支持RPC。

RabbitMQ中实现RPC的机制是：

1. 客户端发送请求（消息）时，在消息的属性（MessageProperties，在AMQP协议中定义了14种 properties，这些属性会随着消息一起发送）中设置两个值 replyTo （一个Queue名称，用于告诉服务器处理完成后将通知我的消息发送到这个Queue中）和 correlationId （此次请求的标识号，服务器处理完成后需要将此属性返还，客户端将根据这个id了解哪条请求被成功执行了或执行失败）

2. 服务器端收到消息并处理

3. 服务器端处理完消息后，将生成一条应答消息到 replyTo 指定的Queue，同时携带correlationId 属性

客户端之前已订阅 replyTo 指定的Queue，从中收到服务器的应答消息后，根据其中的correlationId 属性分析哪条请求被执行了，根据执行结果进行后续业务处理。

RabbitMQ消息的事务机制

在使用RabbitMQ的时候，我们可以通过消息持久化操作来解决因为服务器的异常奔溃导致的消息丢失，除此之外我们还会遇到一个问题，当消息的发布者在将消息发送出去之后，消息到底有没有正确到达broker代理服务器呢？如果不进行特殊配置的话，默认情况下发布操作是不会返回任何信息给生产者的，也就是默认情况下我们的生产者是不知道消息有没有正确到达broker的，如果在消息到达broker之前已经丢失的话，持久化操作也解决不了这个问题，因为消息根本就没到达代理服务器，你怎么进行持久化，那么这个问题该怎么解决呢？

RabbitMQ为我们提供了两种方式：

• 通过AMQP事务机制实现，这也是AMQP协议层面提供的解决方案；

• 通过将channel设置成confirm模式来实现；

RabbitMQ中与事务机制有关的方法有三个： txSelect() , txCommit() 以及 txRollback()；

txSelect() 用于将当前channel设置成transaction模式， txCommit() 用于提交事务，

txRollback() 用于回滚事务，在通过 txSelect() 开启事务之后，我们便可以发布消息给broker代理服务器了，如果 txCommit() 提交成功了，则消息一定到达了broker了，如果在 txCommit() 执行之前broker异常崩溃或者由于其他原因抛出异常，这个时候我们便可以捕获异常通过 txRollback() 回滚事务。

confirm确认模式

原理

生产者将信道设置成confirm模式，一旦信道进入confirm模式，所有在该信道上面发布的消息都会被指派一个唯一的ID(从1开始)，一旦消息被投递到所有匹配的队列之后，broker就会发送一个确认给生产者（包含消息的唯一ID）,这就使得生产者知道消息已经正确到达目的队列了，如果消息和队列是可持久化的，那么确认消息会将消息写入磁盘之后发出，broker回传给生产者的确认消息中deliver-tag域包含了确认消息的序列号，此外broker也可以设置basic.ack的multiple域，表示到这个序列号之前的所有消息都已经得到了处理。

confirm模式最大的好处在于他是异步的，一旦发布一条消息，生产者应用程序就可以在等信道返回确认的同时继续发送下一条消息，当消息最终得到确认之后，生产者应用便可以通过回调方法来处理该确认消息，如果RabbitMQ因为自身内部错误导致消息丢失，就会发送一条nack消息，生产者应用程序同样可以在回调方法中处理该nack消息。

在channel 被设置成 confirm 模式之后，所有被 publish 的后续消息都将被 confirm（即 ack） 或者被nack一次。但是没有对消息被 confirm 的快慢做任何保证，并且同一条消息不会既被 confirm又被nack 。

注意:两种事物控制形式不能同时开启！

实现

实现生产者confirm 机制有三种方式:

• 普通confirm模式：每发送一条消息后，调用waitForConfirms()方法，等待服务器端confirm。实际上是一种串行confirm了。

• 批量confirm模式：每发送一批消息后，调用waitForConfirmsOrDie()方法，等待服务器端confirm。

• 异步confirm模式：提供一个回调方法，服务端confirm了一条或者多条消息后Client端会回调这个方法