文章目录
RabbitMQ之发布确认模式
1、发布确认原理
发布确认是解决消息不丢失的重要环节。
在上节有说到即使我们在生产者中设置了队列持久化、消息持久化,但依然存在消息被传送到队列上,还没来得及存储在磁盘上,队列就宕机了,这种情况下消息也是会丢失的。所以在之前两步的基础上还是进行第三步:发布确认。三步操作加一起才能保证消息是不丢失的。
来看一下发布确认的原理:生产者将信道设置成 confirm (发布确认)模式,一旦信道进入 confirm 模式,所有在该信道上面发布的消息都将会被指派一个唯一的 ID(从 1 开始),一旦消息被投递到所有匹配的队列之后,broker 就会发送一个确认给生产者(包含消息的唯一 ID),这就使得生产者知道消息已经正确到达目的队列了,如果消息和队列是可持久化的,那么确认消息会在将消息写入磁盘之后发出,broker 回传给生产者的确认消息中 delivery-tag 域包含了确认消息的序列号,此外 broker 也可以设置basic.ack 的multiple 域,表示到这个序列号之前的所有消息都已经得到了处理。
confirm 模式最大的好处在于他是异步的,一旦发布一条消息,生产者应用程序就可以在等信道返回确认的同时继续发送下一条消息,当消息最终得到确认之后,生产者应用便可以通过回调方法来处理该确认消息,如果 RabbitMQ 因为自身内部错误导致消息丢失,就会发送一条 nack 消息,生产者应用程序同样可以在回调方法中处理该 nack 消息。
2、发布确认的策略
2.1. 开启发布确认的方法
发布确认模式默认是没有开启的,如果要开启需要调用方法 confirmSelect,每当你要想使用发布确认,都需要在 channel 上调用该方法。这一步操作是在生产者中操作的。

2.2.同步发布确认
2.2.1. 单个发布确认
这是一种简单的确认方式,它是一种同步发布确认的方式,也就是发布一个消息之后只有它被确认发布,后续的消息才能继续发布,
waitForConfirms() 与 waitForConfirmsOrDie(),可以指定时间参数,这个方法只有在消息被确认的时候才返回,如果在指定时间范围内这个消息没有被确认那么它将抛出异常。只是waitForConfirmsOrDie异常后信道被关闭,生产者发布不能继续发布消息。
这种确认方式有一个最大的缺点就是:发布速度特别的慢,因为如果没有确认发布的消息就会阻塞所有后续消息的发布,这种方式最多提供每秒不超过数百条发布消息的吞吐量。当然对于某些应用程序来说这可能已经足够了。
package com.wlw.rabbitmq.four;
import com.rabbitmq.client.Channel;
import com.rabbitmq.client.MessageProperties;
import com.wlw.rabbitmq.utils.RabbitMqUtils;
import java.util.UUID;
/**
* 发布确认模式
* 使用的时间比较哪种确认方式是最好的
* 1、单个确认 - 同步
* 2、批量确认 - 同步
* 3、异步批量确认
*/
public class ConfirmMessage {
private static final int MESSAGE_COUNT = 1000;
public static void main(String[] args) throws Exception {
//1、单个确认 - 同步
publishMessageIndividually(); //发布1000个单独确认消息,耗时722ms
}
//单个确认 - 同步
public static void publishMessageIndividually() throws Exception {
//获取信道
Channel channel = RabbitMqUtils.getChannel();
//队列名
String queueName = UUID.randomUUID().toString();
//声明队列 - 同时设置队列持久化
channel.queueDeclare(queueName, true, false, false, null);
//开启发布确认
channel.confirmSelect();
long begin = System.currentTimeMillis();
for (int i = 0; i < MESSAGE_COUNT; i++) {
String message = i + "";
//发消息 - 同时设置消息持久化
channel.basicPublish("", queueName

本文详细探讨RabbitMQ的发布确认模式,包括原理、同步与异步策略的实现,并比较不同确认方式下的性能。了解如何提升消息可靠性,避免消息丢失,重点关注异步批量确认的高效和可靠性。
最低0.47元/天 解锁文章
892

被折叠的 条评论
为什么被折叠?



