RabbitMQ学习总结-消息的可靠性

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());
        }
    });
}

}

@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(“hmall.direct”, “q”, “hello”, cd);
}

2.MQ自身的可靠性：交换机/队列/消息都实现持久化，消息不会丢失，如果是在项目中通过代码创建的交换机/队列/消息，spring默认就是持久化的，如果在mq的客户端手工配置，那就要选定各个参数了。持久化后的消息会直接进入磁盘，不在经过内存了，正常来讲有IO的操作会慢才对，但是在实际的操作中却是非常快。


MQ队列最怕的就是消息积压，导致内存溢出。在3.12版本以后，MQ直接默认就是Laz懒惰队列的模式了，这个模式会直接加载到磁盘，当用到消息的时候，会从磁盘加载到内存，磁盘空间很大，支持数百万级别的存储，所以内存溢出的可能性就会大大降低。我们可以在mq客户端手动设置为lazy队列，也可以在代码中直接实现，代码如下：

@RabbitListener(queuesToDeclare = @Queue(
name = “lazy.queue”,
durable = “true”,
arguments = @Argument(name = “x-queue-mode”, value = “lazy”)
))
public void listenLazyQueue(String msg){
log.info(“接收到 lazy.queue的消息：{}”, msg);
}

3.消费者的可靠性：


3.1消费者消费消息后，向MQ发送回执，让MQ知道消息是否正常被消费了，目前回执有三种：


ack：成功处理了消息，MQ从队列中就会删除消息，正常。


nack：失败处理了消息，MQ需要再次投递消息，这会出现一直重试的问题。


reject：消息失败，并拒绝了消息，并且从队列中删除了消息。这个消息被删除了，岂不是数据就丢失了。


对于以上三种回执，基本回执都是固定的，AMQP提供了消息确认的方式，不用写代码，配置就可以,配置有三种：none-配置它失败了，消息会被删除，auto-失败了，消息会回到MQ重新投递，不会丢失，不会被删除，manual-太麻烦，算了。


不过，对于auto的配置，对于返回的异常，会有两种判断：1，如果是业务异常，会自动返回nack


如果是消息处理或者校验异常，会直接进行reject

spring:
rabbitmq:
listener:
simple:
acknowledge-mode: auto

3.2 生产者有重试机制，消费者也有重试机制，但是，对于消费者的重试，如果一直失败，那就要有一定的策略，可以把这个失败的消息放到另一个交换机上，后续人工进行干预，这样可以保证消息不丢失。


对于消费者的重试配置：

spring:
rabbitmq:
listener:
simple:
retry:
enabled: true # 开启消费者失败重试
initial-interval: 1000ms # 初识的失败等待时长为1秒
multiplier: 1 # 失败的等待时长倍数，下次等待时长 = multiplier * last-interval
max-attempts: 3 # 最大重试次数
stateless: true # true无状态；false有状态。如果业务中包含事务，这里改为false

如何把消息发送到另一个交换机上呢？


在消费者服务定义一个处理失败消息队列的交换机，这样就可以把消息存储过去了

@Configuration
@ConditionalOnProperty(name = “spring.rabbitmq.listener.simple.retry.enabled”, havingValue = “true”)
public class ErrorMessageConfig {
@Bean
public DirectExchange errorMessageExchange(){
return new DirectExchange(“error.direct”);
}
@Bean
public Queue errorQueue(){
return new Queue(“error.queue”, true);
}
@Bean
public Binding errorBinding(Queue errorQueue, DirectExchange errorMessageExchange){
return BindingBuilder.bind(errorQueue).to(errorMessageExchange).with(“error”);
}

@Bean
public MessageRecoverer republishMessageRecoverer(RabbitTemplate rabbitTemplate){
    return new RepublishMessageRecoverer(rabbitTemplate, "error.direct", "error");
}

}

4.业务的幂等性判断


4.1.对于一条MQ消息，为了防止被重复消费，可以做一个唯一的msgID，当消费的时候可以先检查下这个ID，如果已经消费过了，那就不能再消费了，一定程度上可以避免被重复消费，代码如下：



![img](https://img-blog.csdnimg.cn/img_convert/9ffe853e5a93c27a85bb4379b865ffe0.png)
![img](https://img-blog.csdnimg.cn/img_convert/066e24dd226135add121b0f0cf530aad.png)
![img](https://img-blog.csdnimg.cn/img_convert/f3fc39b1d46a230c5d911dfcaad51935.png)

**既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！**

436)]
[外链图片转存中...(img-0gXxh4K7-4701989395436)]
[外链图片转存中...(img-zcmSs3Ja-4701989395436)]

**既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！**