RabbitMQ学习笔记

RabbitMQ学习笔记

概念

什么是MQ

MQ(message queue)，从字面意思上看，本质是个队列先入先出，只不过队列中存放的内容是message 而已，MQ还是一种跨进程的通信机制，用于上下游传递消息。在互联网架构中，MQ 是一种非常常见的上下游“逻辑解耦+物理解耦”的消息通信服务。使用了 MQ 之后，消息发送上游只需要依赖 MQ，不用依赖其他服务。

MQ的作用

1.流量消峰

举个例子，如果订单系统最多能处理一万次订单，这个处理能力应付正常时段的下单时绰绰有余，正常时段我们下单一秒后就能返回结果。但是在高峰期，如果有两万次下单操作系统是处理不了的，只能限制订单超过一万后不允许用户下单。使用消息队列做缓冲，我们可以取消这个限制，把一秒内下的订单分散成一段时间来处理，这时有些用户可能在下单十几秒后才能收到下单成功的操作，但是比不能下单的体验要好。

2.应用解耦

以电商应用为例，应用中有订单系统、库存系统、物流系统、支付系统。用户创建订单后，如果耦合调用库存系统、物流系统、支付系统，任何一个子系统出了故障，都会造成下单操作异常。当转变成基于消息队列的方式后，系统间调用的问题会减少很多，比如物流系统因为发生故障，需要几分钟来修复。在这几分钟的时间里，物流系统要处理的内存被缓存在消息队列中，用户的下单操作可以正常完成。当物流系统恢复后，继续处理订单信息即可，中单用户感受不到物流系统的故障，提升系统的可用性。

3.异步处理

有些服务间调用是异步的，例如 A 调用 B，B 需要花费很长时间执行，但是 A 需要知道 B 什么时候可以执行完，以前一般有两种方式，A 过一段时间去调用 B 的查询 api 查询。或者 A 提供一个 callback api，B 执行完之后调用 api 通知 A 服务。这两种方式都不是很优雅，使用消息总线，可以很方便解决这个问题，A 调用 B 服务后，只需要监听 B 处理完成的消息，当 B 处理完成后，会发送一条消息给 MQ，MQ 会将此消息转发给 A 服务。这样 A 服务既不用循环调用 B 的查询 api，也不用提供 callback api。同样 B 服务也不用做这些操作。A 服务还能及时的得到异步处理成功的消息。

RabbitMQ

RabbitMQ 是一个消息中间件：它接受并转发消息。你可以把它当做一个快递站点，当你要发送一个包裹时，你把你的包裹放到快递站，快递员最终会把你的快递送到收件人那里，按照这种逻辑 RabbitMQ 是 一个快递站，一个快递员帮你传递快件。RabbitMQ 与快递站的主要区别在于，它不处理快件而是接收， 存储和转发消息数据。

RabbitMQ四大核心

• 生产者 ：产生数据发送消息的程序是生产者
• 交换机 ：交换机是 RabbitMQ 非常重要的一个部件，一方面它接收来自生产者的消息，另一方面它将消息推送到队列中。交换机必须确切知道如何处理它接收到的消息，是将这些消息推送到特定队列还是推送到多个队列，亦或者是把消息丢弃，这个得有交换机类型决定
• 队列：队列是 RabbitMQ 内部使用的一种数据结构，尽管消息流经 RabbitMQ 和应用程序，但它们只能存储在队列中。队列仅受主机的内存和磁盘限制的约束，本质上是一个大的消息缓冲区。许多生产者可以将消息发送到一个队列，许多消费者可以尝试从一个队列接收数据。这就是我们使用队列的方式
• 消费者 ：消费与接收具有相似的含义。消费者大多时候是一个等待接收消息的程序。请注意生产者，消费者和消息中间件很多时候并不在同一机器上。同一个应用程序既可以是生产者又是可以是消费者。

RabbitMQ环境搭建

官网地址

https://www.rabbitmq.com/download.html

安装RabbitMQ

该安装流程基于Linux CentOS_7和RabbitMQ3.8.8，其他版本可能会有区别。

1.将从官网下载的RabbitMQ安装文件上传到linux服务器或虚拟机

2.安装文件(分别按照以下顺序安装)

rpm -ivh erlang-21.3-1.el7.x86_64.rpm(你自己的安装包名称)
yum install socat -y
rpm -ivh rabbitmq-server-3.8.8-1.el7.noarch.rpm(你自己的安装包名称)

3.添加开机启动 RabbitMQ 服务

chkconfig rabbitmq-server on

4.启动服务

/sbin/service rabbitmq-server start

5.查看服务状态

/sbin/service rabbitmq-server status

6.停止服务(选择执行)

/sbin/service rabbitmq-server stop

开启RabbitMQ后台管理插件

这是RabbitMQ自带的web端可视化管理页面，我们可以在里面了解到MQ的所有信息。界面如下图所示：

开启流程

1.开启 web 管理插件

rabbitmq-plugins enable rabbitmq_management

因为权限问题，第一次启动后是无法登录管理系统的，我们需要添加用户给他权限后登录。

2.创建账号

rabbitmqctl add_user admin 123

3.设置用户角色

rabbitmqctl set_user_tags admin administrator

4.设置用户权限

//set_permissions [-p <vhostpath>] <user> <conf> <write> <read>
//用户 user_admin 具有/vhost1 这个 virtual host 中所有资源的配置、写、读权限
rabbitmqctl set_permissions -p "/" admin ".*" ".*" ".*"

5.查看当前MQ中的用户和角色，确认是否添加成功

rabbitmqctl list_users

6.登录管理系统

登录地址为:你的服务器地址+15672
示例：http://192.168.10.100:15672

操作

引入MQ依赖

<dependencies>
    <!--rabbitmq 依赖客户端-->
    <dependency>
        <groupId>com.rabbitmq</groupId>
        <artifactId>amqp-client</artifactId>
        <version>5.8.0</version>
    </dependency>
    <!--操作文件流的一个依赖-->
    <dependency>
        <groupId>commons-io</groupId>
        <artifactId>commons-io</artifactId>
        <version>2.6</version>
    </dependency>
</dependencies>

创建链接工厂

ConnectionFactory factory = new ConnectionFactory();
//MQ服务器地址
factory.setHost("182.92.234.71");
factory.setUsername("admin");
factory.setPassword("123");

创建链接和信道

Connection connection = factory.newConnection();
Channel channel = connection.createChannel();

创建队列

/*
  生成一个队列
  1.队列名称
  2.队列里面的消息是否持久化 默认消息存储在内存中
  3.该队列是否只供一个消费者进行消费 是否进行共享 true 可以多个消费者消费
  4.是否自动删除 最后一个消费者断开连接以后 该队列是否自动删除 true 自动删除
  5.其他参数
 */
channel.queueDeclare(QUEUE_NAME, false, false, false, null);

生产者发送消息

/*
  发送一个消息
  1.发送到哪个交换机
  2.路由的 key 是哪个
  3.其他的参数信息
  4.发送消息的消息体
 */
channel.basicPublish("", QUEUE_NAME, null, message.getBytes());

消费者接受消息

...//创建链接和信道部分省略
//推送的消息如何进行消费的接口回调
DeliverCallback deliverCallback = (consumerTag, delivery) -> {
    String message = new String(delivery.getBody());
    System.out.println(message);
};
//取消消费的一个回调接口 如在消费的时候队列被删除掉了
CancelCallback cancelCallback = (consumerTag) -> {
    System.out.println("消息消费被中断");
};
/*
  消费者消费消息
  1.消费哪个队列
  2.消费成功之后是否要自动应答 true 代表自动应答 false 手动应答
  3.消费处理逻辑
  4.消费者未成功消费的回调
 */
channel.basicConsume(QUEUE_NAME, true, deliverCallback, cancelCallback);

消费自动应答和手动应答

消息发送后立即被认为已经传送成功，这种模式需要在高吞吐量和数据传输安全性方面做权衡,因为这种模式如果消息在接收到之前，消费者那边出现连接或者 channel 关闭，那么消息就丢失了,当然另一方面这种模式消费者那边可以传递过载的消息，没有对传递的消息数量进行限制，当然这样有可能使得消费者这边由于接收太多还来不及处理的消息，导致这些消息的积压，最终使得内存耗尽，最终这些消费者线程被操作系统杀死，所以这种模式仅适用在消费者可以高效并以某种速率能够处理这些消息的情况下使用。

/**
 * 用于肯定确认应答,告诉MQ已经处理完成
 * 1.消息标记 tag
 * 2.是否批量应答未应答消息，true 代表批量应答比如说channe上有传送tag的消息5,6,7,8当前tag是8那么此时5-8的这些还未应答的消息都会被确认收到消息应答；false同上面相比只会应答tag=8的消息5,6,7这三个消息依然不会被确认收到消息应答。下面的批量否认确定同此。
 */
Channel.basicAck(long var1, boolean var3);
/**
 * 用于否定确认
 * 1.消息标记 tag
 * 2.指定是否批量否定确认
 * 3.决定被否定确认的消息是否应重新入队（requeue）供其他消费者再次消费
 */
Channel.basicNack(long var1, boolean var3, boolean var4);
/**
 * 用于否定确认
 * 1.消息标记 tag
 * 2.决定被否定确认的消息是否应重新入队（requeue）供其他消费者再次消费
 */
Channel.basicReject(long var1, boolean var3);

使用实例

//消费者开启手动应答
boolean autoAck = false;
channel.basicConsume(ACK_QUEUE_NAME, autoAck, deliverCallback, (consumerTag) -> {
    System.out.println(consumerTag + "消费者取消消费接口回调逻辑");
});

//消息消费的时候如何处理消息
DeliverCallback deliverCallback = (consumerTag, delivery) -> {
	String message = new String(delivery.getBody());
	SleepUtils.sleep(1);
	System.out.println("接收到消息:" + message);
	//在消费时进行应答处理
    if(xxx){
        channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false);
    }else{
        Channel.basicNack(long var1, boolean var3, boolean var4);
        Channel.basicReject(long var1, boolean var3);
    }
};

消息自动重新入队

如果消费者由于某些原因失去连接(其通道已关闭，连接已关闭或 TCP 连接丢失)，导致消息未发送 ACK 确认，RabbitMQ 将了解到消息未完全处理，并将对其重新排队。如果此时其他消费者 可以处理，它将很快将其重新分发给另一个消费者。这样，即使某个消费者偶尔死亡，也可以确 保不会丢失任何消息。

队列持久化

队列如果不持久化的话，MQ重启队列便会消失，因为队列是存储在内存中。如果队列要实现持久化需要在声明队列的时候把 durable 参数设置为持久化。

注意如果之前声明的队列不是持久化的，需要把原先队列先删除，或者重新创建一个持久化的队列，不然就会出现错误。

/*
  生成一个队列
  1.队列名称
  2.队列里面的消息是否持久化 默认消息存储在内存中
  3.该队列是否只供一个消费者进行消费 是否进行共享 true 可以多个消费者消费
  4.是否自动删除 最后一个消费者断开连接以后 该队列是否自动删除 true 自动删除
  5.其他参数
 */
channel.queueDeclare(QUEUE_NAME, true, false, false, null);

消息实现持久化

要想让消息实现持久化需要在消息生产者修改代码，MessageProperties.PERSISTENT_TEXT_PLAIN 添加这个属性。

/*
  发送一个消息
  1.发送到哪个交换机
  2.路由的 key 是哪个
  3.其他的参数信息
  4.发送消息的消息体
 */
channel.basicPublish("", QUEUE_NAME, MessageProperties.PERSISTENT_TEXT_PLAIN, message.getBytes());

将消息标记为持久化并不能完全保证不会丢失消息。尽管它告诉 RabbitMQ 将消息保存到磁盘，但是这里依然存在当消息刚准备存储在磁盘的时候 但是还没有存储完，消息还在缓存的一个间隔点。此时并没有真正写入磁盘。持久性保证并不强。

不公平分发和预取值

不公平分发

在最开始的时候我们学习到 RabbitMQ 分发消息采用的轮训分发，但是在某种场景下这种策略并不是很好，比方说有两个消费者在处理任务，其中有个消费者 1 处理任务的速度非常快，而另外一个消费者 2 处理速度却很慢，这个时候我们还是采用轮训分发的化就会到这处理速度快的这个消费者很大一部分时间处于空闲状态，而处理慢的那个消费者一直在干活，这种分配方式在这种情况下其实就不太好，但是RabbitMQ 并不知道这种情况它依然很公平的进行分发。 为了避免这种情况，我们可以设置消费者参数 channel.basicQos(1);

预取值

本身消息的发送就是异步发送的，所以在任何时候，channel 上肯定不止只有一个消息另外来自消费者的手动确认本质上也是异步的。因此这里就存在一个未确认的消息缓冲区，因此希望开发人员能限制此缓冲区的大小，以避免缓冲区里面无限制的未确认消息问题**。这个时候就可以通过使用 basic.qos 方法设置“预取计数”值来完成的。该值定义通道上允许的未确认消息的最大数量。一旦数量达到配置的数量，RabbitMQ 将停止在通道上传递更多消息，除非至少有一个未处理的消息被确认，例如，假设在通道上有未确认的消息 5、6、7，8，并且通道的预取计数设置为 4，此时 RabbitMQ 将不会在该通道上再传递任何消息，除非至少有一个未应答的消息被 ack。比方说 tag=6 这个消息刚刚被确认 ACK，RabbitMQ 将会感知 这个情况到并再发送一条消息。消息应答和 QoS 预取值对用户吞吐量有重大影响。通常，增加预取将提高向消费者传递消息的速度。**虽然自动应答传输消息速率是最佳的，但是，在这种情况下已传递但尚未处理的消息的数量也会增加，从而增加了消费者的 RAM 消耗(随机存取存储器)应该小心使用具有无限预处理的自动确认模式或手动确认模式，消费者消费了大量的消息如果没有确认的话，会导致消费者连接节点的内存消耗变大，所以找到合适的预取值是一个反复试验的过程，不同的负载该值取值也不同 100 到 300 范围内的值通常可提供最佳的吞吐量，并且不会给消费者带来太大的风险。预取值为 1 是最保守的。当然这将使吞吐量变得很低，特别是消费者连接延迟很严重的情况下，特别是在消费者连接等待时间较长的环境中。对于大多数应用来说，稍微高一点的值将是最佳的。

/**
 * 只能处理一条消息，在未应答前MQ不会给该消费者发送下一条消息
 */
channel.basicQos(1);

消息的可靠性确认

在使用 RabbitMQ 的时候，作为消息发送方希望杜绝任何消息丢失或者投递失败场景。 RabbitMQ 为我们提供了两种方式用来控制消息的投递可靠性模式。
⚫ confirm 发布确认模式
⚫ return 消息退回模式
rabbitmq 整个消息投递的路径为：
producer—>rabbitmq broker—>exchange—>queue—>consumer
⚫ 消息从 producer 到 exchange 则会返回一个 confirmCallback 。
⚫ 消息从 exchange–>queue 投递失败则会返回一个 returnCallback 。
我们利用这两个 callback 控制消息的可靠性投递，下面将详细介绍这两种模式。

发布确认

发布确认原理

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

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

//开启发布确认
channel.confirmSelect();

单个确认发布

这是一种简单的确认方式，它是一种同步确认发布的方式，也就是发布一个消息之后只有它被确认发布，后续的消息才能继续发布,waitForConfirmsOrDie(long)这个方法只有在消息被确认的时候才返回，如果在指定时间范围内这个消息没有被确认那么它将抛出异常。

这种确认方式有一个最大的缺点就是:**发布速度特别的慢，**因为如果没有确认发布的消息就会阻塞所有后续消息的发布，这种方式最多提供每秒不超过数百条发布消息的吞吐量。当然对于某些应用程序来说这可能已经足够了。

优点是可靠性比较高，当应用对消息送达的可靠性有严格要求时，发布者可以在发送消息后立即调用 waitForConfirms()，确保在继续发送下一批消息之前，已经确认当前批次的所有消息都被 RabbitMQ 正确接收和处理。

/*
使用单个确认发布后发布者的程序执行会暂停，等待未得到确认的消息获得服务器的确认回复。
MQ收到消息后返回，true成功，服务端返回 false 或超时时间内未返回，生产者可以消息重发
*/
Channel.waitForConfirms();
//1.超时时间，未确认单位是秒还是毫秒
Channel.waitForConfirms(long var1);

批量确认发布

单个确认方式非常慢，与单个等待确认消息相比，先发布一批消息然后一起确认可以极大地提高吞吐量，当然这种方式的缺点就是:当发生故障导致发布出现问题时，不知道是哪个消息出现问题了，我们必须将整个批处理保存在内存中，以记录重要的信息而后重新发布消息。当然这种方案仍然是同步的，也一样阻塞消息的发布。

批量和单个一样都是使用waitForConfirmsOrDie(long)这个方法区别在于单个是每发送一个消息确认一次，批量是发送多个消息后一次性确认。

批量确认发布实例使用代码

public static void publishMessageBatch() throws Exception {
    try (Channel channel = RabbitMqUtils.getChannel()) {
        String queueName = UUID.randomUUID().toString();
        channel.queueDeclare(queueName, false, false, false, null);
        //开启发布确认
        channel.confirmSelect();
        //批量确认消息大小
        int batchSize = 100;
        //未确认消息个数
        int outstandingMessageCount = 0;
        long begin = System.currentTimeMillis();
        for (int i = 0; i < MESSAGE_COUNT; i++) {
            String message = i + "";
            channel.basicPublish("", queueName, null, message.getBytes());
            outstandingMessageCount++;
            if (outstandingMessageCount == batchSize) {
                channel.waitForConfirms();
                outstandingMessageCount = 0;
            }
        }
        //为了确保还有剩余没有确认消息 再次确认
        if (outstandingMessageCount > 0) {
            channel.waitForConfirms();
        }
        long end = System.currentTimeMillis();
        System.out.println("发布" + MESSAGE_COUNT + "个批量确认消息,耗时" + (end - begin) +
                "ms");
    }
}

异步确认发布

异步确认虽然编程逻辑比上两个要复杂，但是性价比最高，无论是可靠性还是效率都没得说， 他是利用回调函数来达到消息可靠性传递的。当MQ收到发送的消息后会回调生产者，这样就不用同步等待确认消息。

public static void publishMessageAsync() throws Exception {
    try (Channel channel = RabbitMqUtils.getChannel()) {
        String queueName = UUID.randomUUID().toString();
        System.out.println("异步确认发布名称" + queueName);
        channel.queueDeclare(queueName, false, false, false, null);
        //开启发布确认
        channel.confirmSelect();
        /**
         * 线程安全有序的一个哈希表，适用于高并发的情况，存放未确认的消息
         * 1.轻松的将序号与消息进行关联
         * 2.轻松批量删除条目 只要给到序列号
         * 3.支持并发访问
         */
        ConcurrentSkipListMap<Long, String> outstandingConfirms = new
                ConcurrentSkipListMap<>();
        /**
         * 确认收到消息的一个回调
         * 1.消息序列号
         * 2.true 可以确认小于等于当前序列号的消息,false 确认当前序列号消息
         */
        ConfirmCallback ackCallback = (sequenceNumber, multiple) -> {
            if (multiple) {
                //返回的是小于等于当前序列号的未确认消息 是一个 map
                ConcurrentNavigableMap<Long, String> confirmed =
                        outstandingConfirms.headMap(sequenceNumber, true);
                //清除该部分未确认消息
                confirmed.clear();
            } else {
                //只清除当前序列号的消息
                outstandingConfirms.remove(sequenceNumber);
            }
            System.out.println("确认消息发送成功");
        };
        ConfirmCallback nackCallback = (sequenceNumber, multiple) -> {
            String message = outstandingConfirms.get(sequenceNumber);
            System.out.println("发布的消息" + message + "未被确认，序列号" + sequenceNumber);
        };
        /**
         * 添加一个异步确认的监听器
         * 1.确认收到消息的回调
         * 2.未收到消息的回调
         */
        channel.addConfirmListener(ackCallback, nackCallback);
        long begin = System.currentTimeMillis();
        for (int i = 0; i < MESSAGE_COUNT; i++) {
            String message = "消息" + i;
            /**
             * channel.getNextPublishSeqNo()获取当前通道（Channel）上即将发布的下一个消息的序列号
             * 通过序列号与消息体进行一个关联
             * 全部都是未确认的消息体
             */
            outstandingConfirms.put(channel.getNextPublishSeqNo(), message);
            channel.basicPublish("", queueName, null, message.getBytes());
        }
        long end = System.currentTimeMillis();
        System.out.println("发布" + MESSAGE_COUNT + "个异步确认消息,耗时" + (end - begin) +
                "ms");
    }
}

消息回退

消息回退与异步确认发一样都是利用回调来完成可靠性传递的，当消息发送给Exchange后，Exchange路由到Queue失败是 才会执行 ReturnCallBack。

public static void main(String[] args) throws Exception {
    try (Channel channel = RabbitMqUtils.getChannel()) {
        String queueName = UUID.randomUUID().toString();
        channel.queueDeclare(queueName, false, false, false, null);
        //开启发布确认
        channel.confirmSelect();

        ReturnCallback callback = (message) -> {
            System.out.println("消息" + Arrays.toString(message.getBody()) + "被拒绝");
        };
        /*
          添加消息退回监听器
          1.确认收到消息的回调
          2.未收到消息的回调
         */
        //注意：交换机要设置处理失败消息的模式才能监听
        channel.addReturnListener(callback);
        
        channel.basicPublish("", queueName, null, "123".getBytes());
    }
}

创建临时队列

Channel.queueDeclare().getQueue();

fanout（广播类型）交换机

"fanout"为广播类型所有绑定该交换机的消费者都会收到这条消息进行消费。

public static void main(String[] argv) throws Exception {
        Channel channel = RabbitMqUtils.getChannel();
       /**
        * 声明一个 exchange
        * 1.exchange 的名称
        * 2.exchange 的类型
        */
        channel.exchangeDeclare(EXCHANGE_NAME, "fanout");
        /**
         * 生成一个临时的队列 队列的名称是随机的
         * 当消费者断开和该队列的连接时 队列自动删除
         */
        String queueName = channel.queueDeclare().getQueue();
        /*
        把该临时队列绑定我们的 exchange 其中 routingkey(也称之为 binding key)为空字符串
        1.队列名称
        2.交换机名称
        3.routingKey
         */
        channel.queueBind(queueName, EXCHANGE_NAME, "");
        System.out.println("等待接收消息,把接收到的消息打印在屏幕.....");
        DeliverCallback deliverCallback = (consumerTag, delivery) -> {
            String message = new String(delivery.getBody(), "UTF-8");
            System.out.println("控制台打印接收到的消息" + message);
        };
        channel.basicConsume(queueName, true, deliverCallback, consumerTag -> {
        });
    }

direct（直接类型）交换机

direct类型的交换机只会将消息给routingkey匹配的消费者消费，如有多个消费者routingkey与消息匹配多个消费者都消费，如果没有匹配的消费者，消息会丢失。

生产者：

public static void main(String[] argv) throws Exception {
        try (Channel channel = RabbitMqUtils.getChannel()) {
            channel.exchangeDeclare(EXCHANGE_NAME, BuiltinExchangeType.DIRECT);
            //创建多个 bindingKey
            Map<String, String> bindingKeyMap = new HashMap<>();
            bindingKeyMap.put("info","普通 info 信息");
            bindingKeyMap.put("warning","警告 warning 信息");
            bindingKeyMap.put("error","错误 error 信息");
            //debug 没有消费这接收这个消息 所有就丢失了
            bindingKeyMap.put("debug","调试 debug 信息");
            for (Map.Entry<String, String> bindingKeyEntry: bindingKeyMap.entrySet()){
                String bindingKey = bindingKeyEntry.getKey();
                String message = bindingKeyEntry.getValue();
                channel.basicPublish(EXCHANGE_NAME,bindingKey, null,
                        message.getBytes("UTF-8"));
                System.out.println("生产者发出消息:" + message);
            }
        }
    }

消费者：

public static void main(String[] argv) throws Exception {
    Channel channel = RabbitMqUtils.getChannel();
    channel.exchangeDeclare(EXCHANGE_NAME, BuiltinExchangeType.DIRECT);
    String queueName = "console";
    channel.queueDeclare(queueName, false, false, false, null);
    channel.queueBind(queueName, EXCHANGE_NAME, "info");
    channel.queueBind(queueName, EXCHANGE_NAME, "warning");
    channel.queueBind(queueName, EXCHANGE_NAME, "error");
    System.out.println("等待接收消息.....");
    DeliverCallback deliverCallback = (consumerTag, delivery) -> {
        String message = new String(delivery.getBody(), "UTF-8");
        System.out.println(" 接收绑定键 :" + delivery.getEnvelope().getRoutingKey() + ", 消息:" + message);
    };
    channel.basicConsume(queueName, true, deliverCallback, consumerTag -> {
    });
}

Topics（复杂匹配）交换机

发送到类型是 topic 交换机的消息的 routing_key 不能随意写，必须满足一定的要求，它必须是一个单词列表，以点号分隔开。这些单词可以是任意单词，比如说：“stock.usd.nyse”, “nyse.vmw”, “quick.orange.rabbit”.这种类型的。当然这个单词列表最多不能超过 255 个字节。

在这个规则列表中，其中有两个替换符是大家需要注意的

*(星号)可以代替一个单词

#(井号)可以代替多个或零工单词

代码示例：

生产者：

public static void main(String[] argv) throws Exception {
    try (Channel channel = RabbitMqUtils.getChannel()) {
        channel.exchangeDeclare(EXCHANGE_NAME, "topic");
        /**
         * Q1-->绑定的是
         * 中间带 orange 带 3 个单词的字符串(*.orange.*)
         * Q2-->绑定的是
         * 最后一个单词是 rabbit 的 3 个单词(*.*.rabbit)
         * 第一个单词是 lazy 的多个单词(lazy.#)
         *
         */
        Map<String, String> bindingKeyMap = new HashMap<>();
        bindingKeyMap.put("quick.orange.rabbit", "被队列 Q1Q2 接收到");
        bindingKeyMap.put("lazy.orange.elephant", "被队列 Q1Q2 接收到");
        bindingKeyMap.put("quick.orange.fox", "被队列 Q1 接收到");
        bindingKeyMap.put("lazy.brown.fox", "被队列 Q2 接收到");
        bindingKeyMap.put("lazy.pink.rabbit", "虽然满足两个绑定但只被队列 Q2 接收一次");
        bindingKeyMap.put("quick.brown.fox", "不匹配任何绑定不会被任何队列接收到会被丢弃");
        bindingKeyMap.put("quick.orange.male.rabbit", "是四个单词不匹配任何绑定会被丢弃");
        bindingKeyMap.put("lazy.orange.male.rabbit", "是四个单词但匹配 Q2");
        for (Map.Entry<String, String> bindingKeyEntry : bindingKeyMap.entrySet()) {
            String bindingKey = bindingKeyEntry.getKey();
            String message = bindingKeyEntry.getValue();
            channel.basicPublish(EXCHANGE_NAME, bindingKey, null,
                    message.getBytes("UTF-8"));
            System.out.println("生产者发出消息" + message);
        }
    }

消费者1：匹配routingKey为*.orange.*的消息

public static void main(String[] argv) throws Exception {
    Channel channel = RabbitMqUtils.getChannel();
    channel.exchangeDeclare(EXCHANGE_NAME, "topic");
    //声明 Q1 队列与绑定关系
    String queueName = "Q1";
    channel.queueDeclare(queueName, false, false, false, null);
    channel.queueBind(queueName, EXCHANGE_NAME, "*.orange.*");
    System.out.println("等待接收消息.....");
    DeliverCallback deliverCallback = (consumerTag, delivery) -> {
        String message = new String(delivery.getBody(), "UTF-8");
        System.out.println(" 接收队列 :" + queueName + " 绑定键:" + delivery.getEnvelope().getRoutingKey() +
                ", 消息:" + message);
    };
    channel.basicConsume(queueName, true, deliverCallback, consumerTag -> {
    });
}

消费者2：匹配routingKey为*.*.rabbit和lazy.#的消息

public static void main(String[] argv) throws Exception {
    Channel channel = RabbitMqUtils.getChannel();
    channel.exchangeDeclare(EXCHANGE_NAME, "topic");
    //声明 Q2 队列与绑定关系
    String queueName = "Q2";
    channel.queueDeclare(queueName, false, false, false, null);
    channel.queueBind(queueName, EXCHANGE_NAME, "*.*.rabbit");
    channel.queueBind(queueName, EXCHANGE_NAME, "lazy.#");
    System.out.println("等待接收消息.....");
    DeliverCallback deliverCallback = (consumerTag, delivery) -> {
        String message = new String(delivery.getBody(), "UTF-8");
        System.out.println(" 接收队列 :" + queueName + " 绑 定 键:" + delivery.getEnvelope().getRoutingKey() +
                ", 消息:" + message);
    };
    channel.basicConsume(queueName, true, deliverCallback, consumerTag -> {
    });
}

死信队列

先从概念解释上搞清楚这个定义，死信，顾名思义就是无法被消费的消息，字面意思可以这样理解，一般来说，producer 将消息投递到 broker 或者直接到 queue 里了，consumer 从 queue 取出消息进行消费，但某些时候由于特定的原因导致 queue 中的某些消息无法被消费，这样的消息如果没有后续的处理，就变成了死信，有死信自然就有了死信队列。

应用场景:为了保证订单业务的消息数据不丢失，需要使用到 RabbitMQ 的死信队列机制，当消息

消费发生异常时，将消息投入死信队列中.还有比如说: 用户在商城下单成功并点击去支付后在指定时

间未支付时自动失效

死信的来源：

1. 消息 TTL 过期
2. 队列达到最大长度(队列满了，无法再添加数据到 mq 中)
3. 消息被拒绝(basic.reject 或 basic.nack)并且 requeue=false.

消息TTL过期

当消息超时未消费时进入死信队列消费

生产者：

private static final String NORMAL_EXCHANGE = "normal_exchange";

public static void main(String[] argv) throws Exception {
    try (Channel channel = RabbitMqUtils.getChannel()) {
        channel.exchangeDeclare(NORMAL_EXCHANGE, BuiltinExchangeType.DIRECT);
        //设置消息的 TTL 时间
        AMQP.BasicProperties properties = new AMQP.BasicProperties().builder().expiration("10000").build();
        //该信息是用作演示队列个数限制
        for (int i = 1; i < 11; i++) {
            String message = "info" + i;
            channel.basicPublish(NORMAL_EXCHANGE, "zhangsan", properties, message.getBytes());
            System.out.println("生产者发送消息:" + message);
        }
    }
}

消费者 C1 代码(启动之后关闭该消费者 模拟其接收不到消息)消息超时后进入死信队列

//普通交换机名称
private static final String NORMAL_EXCHANGE = "normal_exchange";
//死信交换机名称
private static final String DEAD_EXCHANGE = "dead_exchange";

public static void main(String[] argv) throws Exception {
    Channel channel = RabbitMqUtils.getChannel();
    //声明死信和普通交换机 类型为 direct
    channel.exchangeDeclare(NORMAL_EXCHANGE, BuiltinExchangeType.DIRECT);
    channel.exchangeDeclare(DEAD_EXCHANGE, BuiltinExchangeType.DIRECT);
    //声明死信队列
    String deadQueue = "dead-queue";
    channel.queueDeclare(deadQueue, false, false, false, null);
    //死信队列绑定死信交换机与 routingkey
    channel.queueBind(deadQueue, DEAD_EXCHANGE, "lisi");
    //正常队列绑定死信队列信息
    Map<String, Object> params = new HashMap<>();
    //正常队列设置死信交换机 参数 key 是固定值
    params.put("x-dead-letter-exchange", DEAD_EXCHANGE);
    //正常队列设置死信 routing-key 参数 key 是固定值
    params.put("x-dead-letter-routing-key", "lisi");

    String normalQueue = "normal-queue";
    channel.queueDeclare(normalQueue, false, false, false, params);
    channel.queueBind(normalQueue, NORMAL_EXCHANGE, "zhangsan");
    System.out.println("等待接收消息.....");
    DeliverCallback deliverCallback = (consumerTag, delivery) -> {
        String message = new String(delivery.getBody(), "UTF-8");
        System.out.println("Consumer01 接收到消息" + message);
    };
    channel.basicConsume(normalQueue, true, deliverCallback, consumerTag -> {
    });
}

消费者 C2 代码(以上步骤完成后 启动 C2 消费者 它消费死信队列里面的消息)

private static final String DEAD_EXCHANGE = "dead_exchange";

public static void main(String[] argv) throws Exception {
    Channel channel = RabbitMqUtils.getChannel();
    channel.exchangeDeclare(DEAD_EXCHANGE, BuiltinExchangeType.DIRECT);
    String deadQueue = "dead-queue";
    channel.queueDeclare(deadQueue, false, false, false, null);
    channel.queueBind(deadQueue, DEAD_EXCHANGE, "lisi");
    System.out.println("等待接收死信队列消息.....");
    DeliverCallback deliverCallback = (consumerTag, delivery) -> {
        String message = new String(delivery.getBody(), "UTF-8");
        System.out.println("Consumer02 接收死信队列的消息" + message);
    };
    channel.basicConsume(deadQueue, true, deliverCallback, consumerTag -> {
    });
}

队列达到最大长度

当队列达到最大长度时，新的消息进入死信队列消费。

 //设置队列长度限制
 params.put("x-max-length", 6);

生产者：

public static void main(String[] argv) throws Exception {
    try (Channel channel = RabbitMqUtils.getChannel()) {
        channel.exchangeDeclare(NORMAL_EXCHANGE, BuiltinExchangeType.DIRECT);
        //该信息是用作演示队列个数限制
        for (int i = 1; i < 11; i++) {
            String message = "info" + i;
            channel.basicPublish(NORMAL_EXCHANGE, "zhangsan", null, message.getBytes());
            System.out.println("生产者发送消息:" + message);
        }
    }
}

消费者 C1 代码(启动之后关闭该消费者 模拟其接收不到消息)队列达到最大长度后进入死信队列

//普通交换机名称
private static final String NORMAL_EXCHANGE = "normal_exchange";
//死信交换机名称
private static final String DEAD_EXCHANGE = "dead_exchange";

public static void main(String[] argv) throws Exception {
    Channel channel = RabbitMqUtils.getChannel();
    //声明死信和普通交换机 类型为 direct
    channel.exchangeDeclare(NORMAL_EXCHANGE, BuiltinExchangeType.DIRECT);
    channel.exchangeDeclare(DEAD_EXCHANGE, BuiltinExchangeType.DIRECT);
    //声明死信队列
    String deadQueue = "dead-queue";
    channel.queueDeclare(deadQueue, false, false, false, null);
    //死信队列绑定死信交换机与 routingkey
    channel.queueBind(deadQueue, DEAD_EXCHANGE, "lisi");
    //正常队列绑定死信队列信息
    Map<String, Object> params = new HashMap<>();
    //正常队列设置死信交换机 参数 key 是固定值
    params.put("x-dead-letter-exchange", DEAD_EXCHANGE);
    //正常队列设置死信 routing-key 参数 key 是固定值
    params.put("x-dead-letter-routing-key", "lisi");
    //设置正常队列长度限制
    params.put("x-max-length", 6);
    String normalQueue = "normal-queue";
    channel.queueDeclare(normalQueue, false, false, false, params);
    channel.queueBind(normalQueue, NORMAL_EXCHANGE, "zhangsan");
    System.out.println("等待接收消息.....");
    DeliverCallback deliverCallback = (consumerTag, delivery) -> {
        String message = new String(delivery.getBody(), "UTF-8");
        System.out.println("Consumer01 接收到消息" + message);
    };
    channel.basicConsume(normalQueue, true, deliverCallback, consumerTag -> {
    });
}

消费者 C2 代码(以上步骤完成后 启动 C2 消费者 它消费死信队列里面的消息)

private static final String DEAD_EXCHANGE = "dead_exchange";

public static void main(String[] argv) throws Exception {
    Channel channel = RabbitMqUtils.getChannel();
    channel.exchangeDeclare(DEAD_EXCHANGE, BuiltinExchangeType.DIRECT);
    String deadQueue = "dead-queue";
    channel.queueDeclare(deadQueue, false, false, false, null);
    channel.queueBind(deadQueue, DEAD_EXCHANGE, "lisi");
    System.out.println("等待接收死信队列消息.....");
    DeliverCallback deliverCallback = (consumerTag, delivery) -> {
        String message = new String(delivery.getBody(), "UTF-8");
        System.out.println("Consumer02 接收死信队列的消息" + message);
    };
    channel.basicConsume(deadQueue, true, deliverCallback, consumerTag -> {
    });
}

消息被拒

消费者手动应到消息为flase并不允许消息重新入队时消息进入死信队列

生产者

public static void main(String[] argv) throws Exception {
    try (Channel channel = RabbitMqUtils.getChannel()) {
        channel.exchangeDeclare(NORMAL_EXCHANGE, BuiltinExchangeType.DIRECT);
        //该信息是用作演示队列个数限制
        for (int i = 1; i < 11; i++) {
            String message = "info" + i;
            channel.basicPublish(NORMAL_EXCHANGE, "zhangsan", null, message.getBytes());
            System.out.println("生产者发送消息:" + message);
        }
    }
}

消费者 C1 代码(启动之后关闭该消费者 模拟其接收不到消息)消息被拒后进入死信队列

//普通交换机名称
private static final String NORMAL_EXCHANGE = "normal_exchange";
//死信交换机名称
private static final String DEAD_EXCHANGE = "dead_exchange";

public static void main(String[] argv) throws Exception {
    Channel channel = RabbitMqUtils.getChannel();
    //声明死信和普通交换机 类型为 direct
    channel.exchangeDeclare(NORMAL_EXCHANGE, BuiltinExchangeType.DIRECT);
    channel.exchangeDeclare(DEAD_EXCHANGE, BuiltinExchangeType.DIRECT);
    //声明死信队列
    String deadQueue = "dead-queue";
    channel.queueDeclare(deadQueue, false, false, false, null);
    //死信队列绑定死信交换机与 routingkey
    channel.queueBind(deadQueue, DEAD_EXCHANGE, "lisi");
    //正常队列绑定死信队列信息
    Map<String, Object> params = new HashMap<>();
    //正常队列设置死信交换机 参数 key 是固定值
    params.put("x-dead-letter-exchange", DEAD_EXCHANGE);
    //正常队列设置死信 routing-key 参数 key 是固定值
    params.put("x-dead-letter-routing-key", "lisi");
    String normalQueue = "normal-queue";
    channel.queueDeclare(normalQueue, false, false, false, params);
    channel.queueBind(normalQueue, NORMAL_EXCHANGE, "zhangsan");
    System.out.println("等待接收消息.....");
    DeliverCallback deliverCallback = (consumerTag, delivery) -> {
        String message = new String(delivery.getBody(), "UTF-8");
        if (message.equals("info5")){
            System.out.println("Consumer01 拒绝接收到消息" + message);
            //requeue 设置为 false 代表拒绝重新入队 该队列如果配置了死信交换机将发送到死信队列中
            channel.basicReject(delivery.getEnvelope().getDeliveryTag(), false);
        }else {
            System.out.println("Consumer01 接收到消息" + message);
            channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false);
        }
    };
    channel.basicConsume(normalQueue, true, deliverCallback, consumerTag -> {
    });
}

消费者 C2 代码(以上步骤完成后 启动 C2 消费者 它消费死信队列里面的消息)

private static final String DEAD_EXCHANGE = "dead_exchange";

public static void main(String[] argv) throws Exception {
    Channel channel = RabbitMqUtils.getChannel();
    channel.exchangeDeclare(DEAD_EXCHANGE, BuiltinExchangeType.DIRECT);
    String deadQueue = "dead-queue";
    channel.queueDeclare(deadQueue, false, false, false, null);
    channel.queueBind(deadQueue, DEAD_EXCHANGE, "lisi");
    System.out.println("等待接收死信队列消息.....");
    DeliverCallback deliverCallback = (consumerTag, delivery) -> {
        String message = new String(delivery.getBody(), "UTF-8");
        System.out.println("Consumer02 接收死信队列的消息" + message);
    };
    channel.basicConsume(deadQueue, true, deliverCallback, consumerTag -> {
    });
}

延迟队列

延迟队列是死信队列的一种使用，通过TTL超时的方式来激活

延迟队列使用场景

1. 订单在十分钟之内未支付则自动取消
2. 新创建的店铺，如果在十天内都没有上传过商品，则自动发送消息提醒。
3. 用户注册成功后，如果三天内没有登陆则进行短信提醒。
4. 用户发起退款，如果三天内没有得到处理则通知相关运营人员。
5. 预定会议后，需要在预定的时间点前十分钟通知各个与会人员参加会议

当数据量小的时候上面这些操作都可以用定时任务来完成，但如果数据量很大用数据库就很消耗资源。

延迟队列的本质就是将任务交给mq并设置TTL然后正常队列不消费，等TTL超时后用死信队列来作为正常消费队列使用，这样就可以以低资源快速的完成以上类型的需求。

延迟队列-TTL队列

我们可以声明队列的消息过期时间，这这样整个队列所有的消息都将在超时后进入死信队列消费，已达成延迟的效果。

//声明队列的 TTL
 args.put("x-message-ttl", 10000);

但是这样灵活性很差，如果我有消息的TTL需求时间和队列不一致就需要创建新的队列，这样整个项目中将会出现大量的队列从而造成资源浪费。我们可以使用TTL消息来解决这个问题。

延迟队列-TTL消息

将TTL设置在消息上就可以解决，队列灵活性差的问题。

//ttlTime单位毫秒
correlationData.getMessageProperties().setExpiration(ttlTime);

看起来似乎没什么问题，但是在最开始的时候，就介绍过如果使用在消息属性上设置 TTL 的方式，消息可能并不会按时“死亡“，因为 RabbitMQ 只会检查第一个消息是否过期，如果过期则丢到死信队列， 如果第一个消息的延时时长很长，而第二个消息的延时时长很短，第二个消息并不会优先得到执行。 为了解决这个问题我们需要使用rabbitmq的插件。

插件实现延迟队列

安装延时队列插件

参考尚硅谷的课件

声明交换机：在创建交换机时我们将交换机类型设置为插件的类型

    /**
     * 创建一个延迟交换机
     */
    @Bean
    public CustomExchange delayExchange() {
        Map<String, Object> args = new HashMap<>();
        args.put("x-delayed-type", "direct");
        // 属性参数 交换机名称 交换机类型 是否持久化 是否自动删除 配置参数
        return new CustomExchange("delay_exchange", "x-delayed-message", true, false, args);
    }

设置消息TTL：

correlationData.getMessageProperties().setDelay(delayTime);

优先级队列

在我们系统中有一个订单催付的场景，我们的客户在天猫下的订单,淘宝会及时将订单推送给我们，如果在用户设定的时间内未付款那么就会给用户推送一条短信提醒，很简单的一个功能对吧，但是，tmall商家对我们来说，肯定是要分大客户和小客户的对吧，比如像苹果，小米这样大商家一年起码能给我们创造很大的利润，所以理应当然，他们的订单必须得到优先处理，而曾经我们的后端系统是使用 redis 来存放的定时轮询，大家都知道 redis 只能用 List 做一个简简单单的消息队列，并不能实现一个优先级的场景，所以订单量大了后采用 RabbitMQ 进行改造和优化,如果发现是大客户的订单给一个相对比较高的优先级，否则就是默认优先级。

要让队列实现优先级需要做的事情有如下事情:队列需要设置为优先级队列，消息需要设置消息的优先级，消费者需要等待消息已经发送到队列中才去消费因为，这样才有机会对消息进行排序。

生产者

private static final String QUEUE_NAME = "hello";

        public static void main(String[] args) throws Exception {
            try (Channel channel = RabbitMqUtils.getChannel();) {
                //给消息赋予一个 priority 属性，设置消息优先级
                AMQP.BasicProperties properties = new AMQP.BasicProperties().builder().priority(5).build();
                for (int i = 1; i < 11; i++) {
                    String message = "info" + i;
                    if (i == 5) {
                        channel.basicPublish("", QUEUE_NAME, properties, message.getBytes());
                    } else {
                        channel.basicPublish("", QUEUE_NAME, null, message.getBytes());
                    }
                    System.out.println("发送消息完成:" + message);
                }
            }
        }

消费者

private static final String QUEUE_NAME = "hello";

public static void main(String[] args) throws Exception {
    Channel channel = RabbitMqUtils.getChannel();
    //设置队列的最大优先级 最大可以设置到 255 官网推荐 1-10 如果设置太高比较吃内存和 CPU
    Map<String, Object> params = new HashMap();
    params.put("x-max-priority", 10);
    channel.queueDeclare(QUEUE_NAME, true, false, false, params);
    System.out.println("消费者启动等待消费......");
    DeliverCallback deliverCallback = (consumerTag, delivery) -> {
        String receivedMessage = new String(delivery.getBody());
        System.out.println("接收到消息:" + receivedMessage);
    };
    channel.basicConsume(QUEUE_NAME, true, deliverCallback, (consumerTag) -> {
        System.out.println("消费者无法消费消息时调用，如队列被删除");
    });
}

RabbitMQ幂等性

概念

用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。举个最简单的例子，那就是支付，用户购买商品后支付，支付扣款成功，但是返回结果的时候网络异常，此时钱已经扣了，用户再次点击按钮，此时会进行第二次扣款，返回结果成功，用户查询余额发现多扣钱了，流水记录也变成了两条。在以前的单应用系统中，我们只需要把数据操作放入事务中即可，发生错误立即回滚，但是再响应客户端的时候也有可能出现网络中断或者异常等等。

案例：消息重复消费

消费者在消费 MQ 中的消息时，MQ 已把消息发送给消费者，消费者在给 MQ 返回 ack 时网络中断，故 MQ 未收到确认信息，该条消息会重新发给其他的消费者，或者在网络重连后再次发送给该消费者，但实际上该消费者已成功消费了该条消息，造成消费者消费了重复的消息。

幂等性解决思路

MQ 消费者的幂等性的解决一般使用全局 ID 或者写个唯一标识比如时间戳 或者 UUID 或者订单消费者消费 MQ 中的消息也可利用 MQ 的该 id 来判断，或者可按自己的规则生成一个全局唯一 id，每次消费消息时用该 id 先判断该消息是否已消费过。

消费端的幂等性保障

在海量订单生成的业务高峰期，生产端有可能就会重复发生了消息，这时候消费端就要实现幂等性，这就意味着我们的消息永远不会被消费多次，即使我们收到了一样的消息。业界主流的幂等性有两种操作:a. 唯一 ID+指纹码机制,利用数据库主键去重, b.利用 redis 的原子性去实现。

唯一 ID+指纹码机制

指纹码:我们的一些规则或者时间戳加别的服务给到的唯一信息码,它并不一定是我们系统生成的，基本都是由我们的业务规则拼接而来，但是一定要保证唯一性，然后就利用查询语句进行判断这个 id 是否存 在数据库中,优势就是实现简单就一个拼接，然后查询判断是否重复；劣势就是在高并发时，如果是单个数 据库就会有写入性能瓶颈当然也可以采用分库分表提升性能，但也不是我们最推荐的方式。

Redis 原子性

利用 redis 执行 setnx 命令，天然具有幂等性。从而实现不重复消费。