Work Queues

工作队列(又称任务队列)的主要思想是避免立即执行资源密集型任务，而不得不等待它完成。相反我们安排任务在之后执行。我们把任务封装为消息并将其发送到队列。在后台运行的工作进程将弹出任务并最终执行作业。当有多个工作线程时，这些工作线程将一起处理这些任务。

轮训发送消息

启动两个线程，一个消息发送线程，来看看这两个工作线程是如何工作的。

抽取工具类

package com.uin;import com.rabbitmq.client.Channel;import com.rabbitmq.client.Connection;import com.rabbitmq.client.ConnectionFactory;import java.io.IOException;import java.util.concurrent.TimeoutException;public class RabbitMQUtils { public static Channel getChannel() throws IOException, TimeoutException { //引入连接工厂 ConnectionFactory factory = new ConnectionFactory(); factory.setHost("localhost"); factory.setUsername("guest"); factory.setPassword("guest"); Connection connection = factory.newConnection(); Channel channel = connection.createChannel(); return channel; }}

启动两个工作线程

package com.uin.work_queues;import com.rabbitmq.client.CancelCallback;import com.rabbitmq.client.Channel;import com.rabbitmq.client.DeliverCallback;import com.uin.utils.RabbitMQUtils;import java.io.IOException;import java.util.concurrent.TimeoutException;public class Consumer_work01 { public static final String QUEUE_NAME = "hello"; public static void main(String[] args) throws IOException, TimeoutException { Channel channel = RabbitMQUtils.getChannel(); //接受消息的回调 DeliverCallback deliverCallback = (consumerTag, message) -> { System.out.println("接受到的消息:" + new String(message.getBody())); }; //取消消息的回调 CancelCallback cancelCallback = (consumerTag) -> { System.out.println(consumerTag + "消息被取消消费者接口的回调逻辑！"); }; System.out.println("第一个工作线程！等待接受消息。。。。"); channel.basicConsume(QUEUE_NAME, true, deliverCallback, cancelCallback); }}

package com.uin.work_queues;import com.rabbitmq.client.CancelCallback;import com.rabbitmq.client.Channel;import com.rabbitmq.client.DeliverCallback;import com.uin.utils.RabbitMQUtils;import java.io.IOException;import java.util.concurrent.TimeoutException;public class Consumer_work02 { public static final String QUEUE_NAME = "hello"; public static void main(String[] args) throws IOException, TimeoutException { Channel channel = RabbitMQUtils.getChannel(); //接受消息的回调 DeliverCallback deliverCallback = (consumerTag, message) -> { System.out.println("接受到的消息:" + new String(message.getBody())); }; //取消消息的回调 CancelCallback cancelCallback = (consumerTag) -> { System.out.println(consumerTag + "消息被取消消费者接口的回调逻辑！"); }; System.out.println("第二个工作线程！等待接受消息。。。。"); channel.basicConsume(QUEUE_NAME, true, deliverCallback, cancelCallback); }}

生产者

package com.uin.work_queues;import com.rabbitmq.client.Channel;import com.uin.utils.RabbitMQUtils;import java.io.IOException;import java.util.Scanner;import java.util.concurrent.TimeoutException;public class Producer_task01 { public static final String QUEUE_NAME = "hello"; public static void main(String[] args) throws IOException, TimeoutException { Channel channel = RabbitMQUtils.getChannel(); //声明队列 channel.queueDeclare(QUEUE_NAME, false, false, false, null); //发送消息 Scanner scanner = new Scanner(System.in); while (scanner.hasNext()) { String message = scanner.next(); channel.basicPublish("", QUEUE_NAME, null, message.getBytes());//以二进制传输 System.out.println("发送消息完成：" + message); } }}

消息应答

概念

消费者完成一个任务可能需要一段时间，如果其中一个消费者处理一个长的任务并仅只完成了部分突然它挂掉了，会发生什么情况。RabbitMQ 一旦向消费者传递了一条消息，便立即将该消息标记为删除。在这种情况下，突然有个消费者挂掉了，我们将丢失正在处理的消息。以及后续发送给该消费这的消息，因为它无法接收到。为了保证消息在发送过程中不丢失，rabbitmq 引入消息应答机制，消息应答就是:消费者在接收到消息并且处理该消息之后，告诉 rabbitmq 它已经处理了，rabbitmq 可以把该消息删除了。

意思就是：生产者它发完消息之后就会把发送消息这个线程给删除，而另一端的消费者并没有处理完消息就宕机了，而它又把这个消息抢到了。就会造成消息的丢失。所以就出来这个消息应答的机制。

自动应答

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

消息应答的方法(手动应答)

A.Channel.basicAck(用于肯定确认) //RabbitMQ 已知道该消息并且成功的处理消息，可以将其丢弃了B.Channel.basicNack(用于否定确认) C.Channel.basicReject(用于否定确认) //与 Channel.basicNack 相比少一个参数(**Multiple**)//不处理该消息了直接拒绝，可以将其丢弃了

Multiple的解释

手动应答的好处是可以批量应答并减少网络的拥堵

multiple 的 true 和 false 代表不同意思

true 代表批量应答 channel 上未应答的消息//比如说 channel 上有传送 tag 的消息 5,6,7,8 当前 tag 是8 那么此时//5-8 的这些还未应答的消息都会被确认收到消息应答false 同上面相比//只会应答 tag=8 的消息 5,6,7 这三个消息依然不会被确认收到消息应答

消息的自动重新入队

为了保证消息的不丢失，可以让消息重新自动入队列。

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

消息手动应答的实验

要实现的效果：

生产者的代码：

package com.uin.MessageResponse;import com.rabbitmq.client.Channel;import com.uin.utils.RabbitMQUtils;import java.io.IOException;import java.util.Scanner;import java.util.concurrent.TimeoutException;public class Producer_ack { //队列的名字 private static final String TASK_QUEUE_NAME = "ack_queue"; public static void main(String[] args) throws IOException, TimeoutException { Channel channel = RabbitMQUtils.getChannel(); //声明队列 channel.queueDeclare(TASK_QUEUE_NAME, false, false, false, null); //从控制台输入消息 Scanner scanner = new Scanner(System.in); System.out.println("请输入消息："); //循环 while (scanner.hasNext()) { String s = scanner.next(); channel.basicPublish("", TASK_QUEUE_NAME, null, s.getBytes("UTF-8")); System.out.println("生产者发出消息：" + s); } }}

消费者1

package com.uin.MessageResponse;import com.rabbitmq.client.CancelCallback;import com.rabbitmq.client.Channel;import com.rabbitmq.client.DeliverCallback;import com.uin.utils.RabbitMQUtils;import com.uin.utils.SleepUtils;import java.io.IOException;import java.util.concurrent.TimeoutException;public class Consumer_work_ack01 { //队列的名字 private static final String TASK_QUEUE_NAME = "ack_queue"; public static void main(String[] args) throws IOException, TimeoutException { Channel channel = RabbitMQUtils.getChannel(); System.out.println("C1等待接受消息处理较短:"); //消费消息的时候如何处理消息 DeliverCallback deliverCallback = (consumerTag, delivery) -> { String message = new String(delivery.getBody()); try { SleepUtils.sleep(1); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println("接收到消息:" + message); channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false); }; // boolean autoAck = false; channel.basicConsume(TASK_QUEUE_NAME, autoAck,deliverCallback,consumerTag -> { System.out.println("消费者取消消费接口回调"); }); }}

消费者2

package com.uin.MessageResponse;import com.rabbitmq.client.Channel;import com.rabbitmq.client.DeliverCallback;import com.uin.utils.RabbitMQUtils;import com.uin.utils.SleepUtils;import java.io.IOException;import java.util.concurrent.TimeoutException;public class Consumer_work_ack02 { //队列的名字 private static final String TASK_QUEUE_NAME = "ack_queue"; public static void main(String[] args) throws IOException, TimeoutException { Channel channel = RabbitMQUtils.getChannel(); System.out.println("C2等待接受消息处理较长:"); //消费消息的时候如何处理消息 DeliverCallback deliverCallback = (consumerTag, delivery) -> { String message = new String(delivery.getBody()); try { SleepUtils.sleep(30); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println("接收到消息:" + message); channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false); }; // boolean autoAck = false; channel.basicConsume(TASK_QUEUE_NAME, autoAck,deliverCallback,consumerTag -> { System.out.println("消费者取消消费接口回调"); }); }}

RabbitMQ 队列持久化

如何保障当 RabbitMQ 服务停掉以后消息生产者发送过来的消息不丢失。默认情况下 RabbitMQ 退出或由于某种原因崩溃时，它忽视队列和消息，除非告知它不要这样做。确保消息不会丢失需要做两件事：我们需要将队列和消息都标记为持久化。

将false改为true。就可以持久化。

消息持久化

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

消息的持久化是指当消息从交换机发送到队列之后，被消费者消费之前，服务器突然宕机重启，消息仍然存在。消息持久化的前提是队列持久化，假如队列不是持久化，那么消息的持久化毫无意义。

其中MessageProperties.PERSISTENT_TEXT_PLAIN是设置持久化的参数。

看一下basicPublish方法的定义：

* Publish a message * @see com.rabbitmq.client.AMQP.Basic.Publish * @param exchange the exchange to publish the message to * @param routingKey the routing key * @param props other properties for the message - routing headers etc * @param body the message body * @throws java.io.IOException if an error is encountered */void basicPublish(String exchange, String routingKey, BasicProperties props, byte[] body) throws IOException;

再看下BasicProperties的类型：

public BasicProperties( String contentType, String contentEncoding, Map headers, Integer deliveryMode, Integer priority, String correlationId, String replyTo, String expiration, String messageId, Date timestamp, String type, String userId, String appId, String clusterId)

其中deliveryMode是设置消息持久化的参数，等于1不设置持久化，等于2设置持久化。PERSISTENT_TEXT_PLAIN是实例化的一个deliveryMode=2的对象，便于编程：

public static final BasicProperties PERSISTENT_TEXT_PLAIN = new BasicProperties("text/plain", null, null, 2, 0, null, null, null, null, null, null, null, null, null);

保证在服务器重启的时候可以保持不丢失相关信息，重点解决服务器的异常崩溃而导致的消息丢失问题。但是，将所有的消息都设置为持久化，会严重影响RabbitMQ的性能，写入硬盘的速度比写入内存的速度慢的不只一点点。对于可靠性不是那么高的消息可以不采用持久化处理以提高整体的吞吐率，在选择是否要将消息持久化时，需要在可靠性和吞吐量之间做一个权衡。

不公平分发--能者多劳的思想

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

为了避免这种情况，我们可以设置参数 channel.basicQos(1);

意思就是如果这个任务我还没有处理完或者我还没有应答你，你先别分配给我，我目前只能处理一个任务，然后 rabbitmq 就会把该任务分配给没有那么忙的那个空闲消费者，当然如果所有的消费者都没有完成手上任务，队列还在不停的添加新任务，队列有可能就会遇到队列被撑满的情况，这个时候就只能添加新的 worker 或者改变其他存储任务的策略。

预取值--设置一个信道的缓冲大小

本身消息的发送就是异步发送的，所以在任何时候，channel 上肯定不止只有一个消息。另外来自消费者的手动确认本质上也是异步的。因此这里就存在一个未确认的消息缓冲区，因此希望开发人员能限制此缓冲区的大小，以避免缓冲区里面无限制的未确认消息问题。这个时候就可以通过使用 basic.qos() 方法设置“预取计数”值来完成的。

该值定义通道上允许的未确认消息的最大数量。一旦数量达到配置的数量，RabbitMQ 将停止在通道上传递更多消息，除非至少有一个未处理的消息被确认，例如，假设在通道上有未确认的消息 5、6、7，8，并且通道的预取计数设置为 4，此时RabbitMQ 将不会在该通道上再传递任何消息，除非至少有一个未应答的消息被 ack。比方说 tag=6 这个消息刚刚被确认 ACK，RabbitMQ 将会感知这个情况到并再发送一条消息。

消息应答和 QoS 预取值对用户吞吐量有重大影响。通常，增加预取值将提高向消费者传递消息的速度。虽然自动应答传输消息速率是最佳的，但是，在这种情况下已传递但尚未处理的消息的数量也会增加，从而增加了消费者的RAM 耗(随机存取存储器)应该小心使用具有无限预处理的自动确认模式或手动确认模式，消费者消费了大量的消息如果没有确认的话，会导致消费者连接节点的内存消耗变大，所以找到合适的预取值是一个反复试验的过程，不同的负载该值取值也不同 100 到 300 范围内的值通常可提供最佳的吞吐量，并且不会给消费者带来太大的风险。预取值为 1 是最保守的。当然这将使吞吐量变得很低，特别是消费者连接延迟很严重的情况下，特别是在消费者连接等待时间较长的环境中。对于大多数应用来说，稍微高一点的值将是最佳的。

生产者的代码：

package com.uin.MessageResponse;import com.rabbitmq.client.Channel;import com.rabbitmq.client.MessageProperties;import com.uin.utils.RabbitMQUtils;import java.io.IOException;import java.util.Scanner;import java.util.concurrent.TimeoutException;public class Producer_ack { //队列的名字 private static final String TASK_QUEUE_NAME = "ack_queue1"; public static void main(String[] args) throws IOException, TimeoutException { Channel channel = RabbitMQUtils.getChannel(); //声明队列 //声明队列的持久化 boolean durable = true; channel.queueDeclare(TASK_QUEUE_NAME, durable, false, false, null); //从控制台输入消息 Scanner scanner = new Scanner(System.in); System.out.println("请输入消息："); //循环 while (scanner.hasNext()) { String s = scanner.next(); //设置生产者消息为持久化--要求保存到磁盘上 channel.basicPublish("", TASK_QUEUE_NAME, MessageProperties.PERSISTENT_TEXT_PLAIN, s.getBytes( "UTF-8")); System.out.println("生产者发出消息：" + s); } }}

消费者1:

package com.uin.MessageResponse;import com.rabbitmq.client.CancelCallback;import com.rabbitmq.client.Channel;import com.rabbitmq.client.DeliverCallback;import com.uin.utils.RabbitMQUtils;import com.uin.utils.SleepUtils;import java.io.IOException;import java.util.concurrent.TimeoutException;public class Consumer_work_ack01 { //队列的名字 private static final String TASK_QUEUE_NAME = "ack_queue1"; public static void main(String[] args) throws IOException, TimeoutException { Channel channel = RabbitMQUtils.getChannel(); System.out.println("C1等待接受消息处理较短:"); //消费消息的时候如何处理消息 DeliverCallback deliverCallback = (consumerTag, delivery) -> { String message = new String(delivery.getBody()); try { SleepUtils.sleep(1); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println("接收到消息:" + message); channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false); }; //配置为不公平的分发 0默认为轮训(公平的分发) 1不公的分发(不公平的分发) int prefetchCount = 2; //欲取值 channel.basicQos(prefetchCount); //配置手动应答 boolean autoAck = false; channel.basicConsume(TASK_QUEUE_NAME, autoAck, deliverCallback, consumerTag -> { System.out.println("消费者取消消费接口回调"); }); }}

消费者2：

package com.uin.MessageResponse;import com.rabbitmq.client.Channel;import com.rabbitmq.client.DeliverCallback;import com.uin.utils.RabbitMQUtils;import com.uin.utils.SleepUtils;import java.io.IOException;import java.util.concurrent.TimeoutException;public class Consumer_work_ack02 { //队列的名字 private static final String TASK_QUEUE_NAME = "ack_queue1"; public static void main(String[] args) throws IOException, TimeoutException { Channel channel = RabbitMQUtils.getChannel(); System.out.println("C2等待接受消息处理较长:"); //消费消息的时候如何处理消息 DeliverCallback deliverCallback = (consumerTag, delivery) -> { String message = new String(delivery.getBody()); try { SleepUtils.sleep(30); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println("接收到消息:" + message); channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false); }; //配置为不公平的分发 0默认为轮训(公平的分发) 1不公的分发(不公平的分发) int prefetchCount = 5;//欲取值 channel.basicQos(prefetchCount); // 配置手动应答 boolean autoAck = false; channel.basicConsume(TASK_QUEUE_NAME, autoAck, deliverCallback, consumerTag -> { System.out.println("消费者取消消费接口回调"); }); }}

因为c1处理的比较快 就看不到

发布确认

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

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

是解决消息不丢失的一个重要的环节！

发布确认的策略

开启发布确认的方法

单个确认方法

这是一种简单的确认方式，它是一种同步确认发布的方式。

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

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

package com.uin./confirm/i;import com.rabbitmq.client.Channel;import com.rabbitmq.client.MessageProperties;import com.uin.utils.RabbitMQUtils;import sun.lwawt.macosx.CSystemTray;import javax.swing.plaf.synth.SynthLookAndFeel;import java.io.IOException;import java.util.Scanner;import java.util.UUID;import java.util.concurrent.TimeoutException;public class Producer_confirm { private static final String TASK_QUEUE_ConFIRM = "hello"; public static final int MESSAGE_COUNT = 1000; public static void main(String[] args) throws IOException, TimeoutException, InterruptedException { //单个确认 Producer_/confirm/i.publishMessageIndividually(); //批量确认 //异步确认 } public static void publishMessageIndividually() throws IOException, TimeoutException, InterruptedException { Channel channel = RabbitMQUtils.getChannel(); channel.confirmSelect();//开启消息的发布确认 UUID uuid = UUID.randomUUID(); boolean durable = true; //开启队列的持久化 channel.queueDeclare(TASK_QUEUE_/confirm/i, durable, false, false, null); long begin = System.currentTimeMillis(); for (int i = 0; i < MESSAGE_COUNT; i++) { String message = i + ""; channel.basicPublish("", TASK_QUEUE_/confirm/i, null, message.getBytes()); //单个消息确认 boolean flag = channel.waitForConfirms(); if (flag) { System.out.println("消息发送成功！"); } long end = System.currentTimeMillis(); System.out.println("发布" + MESSAGE_COUNT + "个单独确认消息，" + "耗时：" + (end - begin) + "ms"); } }}

批量确认发布

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

package com.uin./confirm/i;import com.rabbitmq.client.Channel;import com.rabbitmq.client.MessageProperties;import com.uin.utils.RabbitMQUtils;import sun.lwawt.macosx.CSystemTray;import javax.swing.plaf.synth.SynthLookAndFeel;import java.io.IOException;import java.util.Scanner;import java.util.UUID;import java.util.concurrent.TimeoutException;public class Producer_confirm { private static final String TASK_QUEUE_ConFIRM = "hello"; public static final int MESSAGE_COUNT = 1000; public static void main(String[] args) throws IOException, TimeoutException, InterruptedException { //单个确认 //Producer_/confirm/i.publishMessageIndividually(); //批量确认 Producer_/confirm/i.publishMessageIndividually(); //异步确认 } public static void publishMessageIndividually() throws IOException, TimeoutException, InterruptedException { Channel channel = RabbitMQUtils.getChannel(); channel.confirmSelect();//开启消息的发布确认 UUID uuid = UUID.randomUUID(); boolean durable = true; //开启队列的持久化 channel.queueDeclare(TASK_QUEUE_/confirm/i, durable, false, false, null); //批量确认消息的大小 int batchSize = 100; //未确认消息个数 int outstandingMessageCount = 0; long begin = System.currentTimeMillis(); for (int i = 0; i < MESSAGE_COUNT; i++) { String message = i + ""; channel.basicPublish("", TASK_QUEUE_/confirm/i, 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"); }}

异步确认发布

异步确认虽然编程逻辑比上两个要复杂，但是性价比最高，无论是可靠性还是效率都没得说，他是利用回调函数来达到消息可靠性传递的，这个中间件也是通过函数回调来保证是否投递成功，下面就让我们来详细讲解异步确认是怎么实现的。

//异步确认消息 public static void publishMessageAsync() throws IOException, TimeoutException { Channel channel = RabbitMQUtils.getChannel(); channel.queueDeclare(TASK_QUEUE_/confirm/i, true, false, false, null); channel.confirmSelect();//开启消息确认 long begin = System.currentTimeMillis(); //消息确认成功 回调函数 ConfirmCallback ackCallback = (deliveryTag, multiple) -> { System.out.println("消息监听成功的消息:" + deliveryTag); }; //消息确认失败 回调函数 ConfirmCallback nackCallback = (deliveryTag, multiple) -> { System.out.println("消息监听失败的消息:" + deliveryTag); }; //开启消息监听器 监听哪些成功 哪些失败了 channel.addConfirmListener(ackCallback, nackCallback); //异步通知 for (int i = 0; i < MESSAGE_COUNT; i++) { String message = "消息:" + i; channel.basicPublish("", TASK_QUEUE_/confirm/i, null, message.getBytes("UTF-8")); } long end = System.currentTimeMillis(); System.out.println("发布" + MESSAGE_COUNT + "个异步确认消息，" + "耗时：" + (end - begin) + "ms"); }

如何处理异步未确认的消息

最好的解决的解决方案就是把未确认的消息放到一个基于内存的能被发布线程访问的队列，比如说用 ConcurrentlinkedQueue 这个队列在 confirm 和callbacks 与发布线程之间进行消息的传递。

package com.uin./confirm/i;import com.rabbitmq.client.Channel;import com.rabbitmq.client./confirm/iCallback;import com.rabbitmq.client.MessageProperties;import com.uin.utils.RabbitMQUtils;import sun.lwawt.macosx.CSystemTray;import javax.swing.plaf.synth.SynthLookAndFeel;import java.io.IOException;import java.util.Scanner;import java.util.UUID;import java.util.concurrent.ConcurrentNavigableMap;import java.util.concurrent.ConcurrentSkipListMap;import java.util.concurrent.TimeoutException;public class Producer_confirm { private static final String TASK_QUEUE_ConFIRM = "hello"; public static final int MESSAGE_COUNT = 1000; public static void main(String[] args) throws IOException, TimeoutException, InterruptedException { //单个确认 //Producer_/confirm/i.publishMessageIndividually(); //批量确认// Producer_/confirm/i.publishMessageIndividually(); //异步确认 Producer_/confirm/i.publishMessageAsync(); } public static void publishMessageIndividually() throws IOException, TimeoutException, InterruptedException { Channel channel = RabbitMQUtils.getChannel(); channel.confirmSelect();//开启消息的发布确认 UUID uuid = UUID.randomUUID(); boolean durable = true; //开启队列的持久化 channel.queueDeclare(TASK_QUEUE_/confirm/i, durable, false, false, null); //批量确认消息的大小 int batchSize = 100; //未确认消息个数 int outstandingMessageCount = 0; long begin = System.currentTimeMillis(); for (int i = 0; i < MESSAGE_COUNT; i++) { String message = i + ""; channel.basicPublish("", TASK_QUEUE_/confirm/i, 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"); } //异步确认消息 public static void publishMessageAsync() throws IOException, TimeoutException { Channel channel = RabbitMQUtils.getChannel(); channel.queueDeclare(TASK_QUEUE_/confirm/i, true, false, false, null); channel.confirmSelect();//开启消息确认 ConcurrentSkipListMap map = new ConcurrentSkipListMap<>(); //消息确认成功 回调函数 ConfirmCallback ackCallback = (deliveryTag, multiple) -> { //2.删除掉一定确认的消息 剩下的就是未确认的消息 if (multiple) {//如果是批量 ConcurrentNavigableMap confirmMap = map.headMap(deliveryTag);//删掉一定异步确认的消息 } else { map.remove(deliveryTag); } System.out.println("消息监听成功的消息:" + deliveryTag); }; //消息确认失败 回调函数 ConfirmCallback nackCallback = (deliveryTag, multiple) -> { //3.打印一下为确认的消息都有哪些 String s = map.get(deliveryTag); System.out.println("未确认的消息是" + s + "，" + "消息监听失败的消息tag:" + deliveryTag); }; //开启消息监听器 监听哪些成功 哪些失败了 channel.addConfirmListener(ackCallback, nackCallback); //异步通知 long begin = System.currentTimeMillis(); for (int i = 0; i < MESSAGE_COUNT; i++) { String message = "消息:" + i; channel.basicPublish("", TASK_QUEUE_/confirm/i, null, message.getBytes("UTF-8")); //1.此处记录下所有要发送的消息 消息的总和 map.put(channel.getNextPublishSeqNo(), message); } long end = System.currentTimeMillis(); System.out.println("发布" + MESSAGE_COUNT + "个异步确认消息，" + "耗时：" + (end - begin) + "ms"); }}

三者的对比

单独发布消息

同步等待确认，简单，但吞吐量非常有限。

批量发布消息

批量同步等待确认，简单，合理的吞吐量，一旦出现问题但很难推断出是那条消息出现了问题。

异步处理：

最佳性能和资源使用，在出现错误的情况下可以很好地控制，但是实现起来稍微难些