RabbitMQ——消息发送的双重保障机制
在分布式系统中，确保消息的可靠传输是至关重要的。无论是处理金融交易、用户互动还是后台数据同步，丢失或重复的消息都可能导致严重的问题。为了增强系统的可靠性，我们可以依赖于生产者的重试机制和生产者确认机制。本文将探讨这两种机制如何共同作用来提高发送者的可靠性。
目录
生产者重试机制
生产者确认机制
实现生产者确认
对应的模块添加配置
定义ReturnCallback
定义ConfirmCallback
生产者确认实现效果
生产者重试机制
问题：网络故障，导致与MQ的连接中断。
解决方案：SpringAMQP提供的消息发送时的重试机制。
即：当RabbitTemplate与MQ连接超时后，多次重试。
方案实现如下：
修改publisher模块的application.yml文件，添加如下配置：
spring:
rabbitmq:
connection-timeout: 1s # 设置MQ的连接超时时间
template:
retry:
enabled: true # 开启超时重试机制
initial-interval: 1000ms # 失败后的初始等待时间
multiplier: 1 # 失败后下次的等待时长倍数，下次等待时长 = initial-interval * multiplier
max-attempts: 3 # 最大重试次数测试：（故意停掉RabbitMQ服务，验证方案可行性）
效果如下：
解决方案验证成功
生产者确认机制
问题：消息发送到MQ之后丢失的现象。
描述：
MQ内部处理消息的进程发生了异常
生产者发送消息到达MQ后未找到Exchange(往往是程序员编码出问题导致)
生产者发送消息到达MQ的Exchange后，未找到合适的Queue，因此无法路由(往往是程序员编码出问题导致)
解决方案：RabbitMQ提供了生产者消息确认机制。
即：Publisher Confirm和Publisher Return两种。在开启确认机制的情况下，当生产者发送消息给MQ后，MQ会根据消息处理的情况返回不同的回执。
如图所示：
图像解读：
publisher --- exchange2：当消息投递到MQ，但是路由失败时，返回异常信息，同时返回ACK(投递成功)
publisher --- exchange：临时消息投递到了MQ，并且入队成功，返回ACK（投递成功）
publisher --- exchange：持久消息投递到了MQ，并且入队完成持久化，返回ACK （投递成功）
其它情况都会返回NACK（投递失败）
实现生产者确认
对应的模块添加配置
在publisher模块的application.yml中添加配置：
spring:
rabbitmq:
publisher-confirm-type: correlated # 开启publisher confirm机制，并设置confirm类型
publisher-returns: true # 开启publisher return机制publisher-confirm-type有三种模式，推荐使用correlated（回调机制）
定义ReturnCallback
每个RabbitTemplate只能配置一个ReturnCallback。
我们在publisher模块定义MqConfig配置类,代码如下：
package com.itheima.publisher.config;
import lombok.AllArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.core.ReturnedMessage;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.context.annotation.Configuration;
import javax.annotation.PostConstruct;
@Slf4j
@AllArgsConstructor
@Configuration
public class MqConfig {
private final RabbitTemplate rabbitTemplate;
@PostConstruct
public void init(){
rabbitTemplate.setReturnsCallback(new RabbitTemplate.ReturnsCallback() {
@Override
public void returnedMessage(ReturnedMessage returned) {
log.error("触发return callback,");
log.debug("exchange: {}", returned.getExchange());
log.debug("routingKey: {}", returned.getRoutingKey());
log.debug("message: {}", returned.getMessage());
log.debug("replyCode: {}", returned.getReplyCode());
log.debug("replyText: {}", returned.getReplyText());
}
});
}
}定义ConfirmCallback
由于每个消息发送时的处理逻辑不一定相同，因此ConfirmCallback需要在每次发消息时定义。具体来说，是在调用RabbitTemplate中的convertAndSend方法时，多传递一个参数,代码如下：
@Test
void testPublisherConfirm() {
// 1.创建CorrelationData
CorrelationData cd = new CorrelationData();
// 2.给Future添加ConfirmCallback
cd.getFuture().addCallback(new ListenableFutureCallback<CorrelationData.Confirm>() {
@Override
public void onFailure(Throwable ex) {
// 2.1.Future发生异常时的处理逻辑，基本不会触发
log.error("send message fail", ex);
}
@Override
public void onSuccess(CorrelationData.Confirm result) {
// 2.2.Future接收到回执的处理逻辑，参数中的result就是回执内容
if(result.isAck()){ // result.isAck()，boolean类型，true代表ack回执，false 代表 nack回执
log.debug("发送消息成功，收到 ack!");
}else{ // result.getReason()，String类型，返回nack时的异常描述
log.error("发送消息失败，收到 nack, reason : {}", result.getReason());
}
}
});
// 3.发送消息
rabbitTemplate.convertAndSend("user.direct", "q", "hello", cd);
}生产者确认实现效果
idea控制台展示：
效果解读：
可以看到，由于传递的RoutingKey是错误的，路由失败后，触发了return callback，同时也收到了ack。
当我们修改为正确的RoutingKey以后，就不会触发return callback了，只收到ack。