RabbitMQ-如何保证消息不丢失
RabbitMQ常用于 异步发送，mysql，redis，es之间的数据同步 ，分布式事务，削峰填谷等.....在微服务中，rabbitmq是我们经常用到的消息中间件。它能够异步的在各个业务之中进行消息的接受和发送，那么如何保证rabbitmq的消息不丢失就显得尤为重要。
起首要分析题目，我们就要明确rabbitmq在什么时间可能会出现消息丢失的情况呢？
我们直接说结果
RabbitMQ在每个阶段都有可能使消息发生丢失
https://img-blog.csdnimg.cn/direct/d814a27b2c2d40c5960e0dd6197f15b0.png
我们在这里把他们简单归结为三个层面
层面一 ：生产者发送消息没有到达交换机大概没有到达绑定的队列。
层面二：RabbitMQ宕机可能导致的消息的丢失。
层面三：消耗者宕机导致消息丢失。
层面一的办理方法常见的是
1.生产者确认机制
RabbitMQ提供了publisher confirm机制来制止消息发送到Mq的过程中丢失，消息发送到Mq以后，会返回一个结果给发送者，表现消息的发送乐成。
情况一：发送乐成 生产者正常发送消息到队列之后会返回一个publish-confirm ack 这个意思是告诉生产者已经吸收到消息了。
情况二：发送失败 这里的发送失败有两种，一种是生产者发送到交换机失败 此时返回 publish-confirm nack 。第二种是生产者发送到队列失败 返回 publish-return ack。
https://img-blog.csdnimg.cn/direct/e74719f58d4a46688b9ab01be933800e.png
开启生产者确认机制的代码如下 ，在生产者的配置文件中参加以下配置
spring:
rabbitmq:
publisher-confirm-type: correlated #开启生产者确认机制
publisher-returns: true 这里的
publisher-confirm-type:有三种模式可以选择： 第一种是none：代表关闭confirm机制
第二种是 simple：表现同步壅闭并等候mq的回执消息，即发送完消息后不能干其他的事情，只能等候mq的回执，很显然这样服从很低。
第三种是correlated：MQ异步回调方式返回回执消息，即生产者发送完消息后可以干其他的事情，直到吸收到mq的回执。很显着这种服从要优于第二种。
配置return callback的代码如下，每个RabbitTemplate只能配置一个 代码如下
package com.itheima.publisher.com.it.heima.config;
import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.core.ReturnedMessage;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.beans.BeansException;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;
import org.springframework.context.annotation.Configuration;
/**
* @Auther: QuJingChuan
* @Date: 2024/1/13 10:34
* @Description:
*/
@Slf4j
@Configuration
public class MqConfirmConfig implements ApplicationContextAware {
@Autowired
private RabbitTemplate rabbitTemplate;
@Override
public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
//配置回调
rabbitTemplate.setReturnsCallback(new RabbitTemplate.ReturnsCallback() {
@Override
public void returnedMessage(ReturnedMessage returnedMessage) {
log.debug("收到消息return的callback,{},{},{},{},{}",
returnedMessage.getExchange(),
returnedMessage.getRoutingKey(),
returnedMessage.getMessage(),
returnedMessage.getReplyCode(),
returnedMessage.getReplyText());
}
});
}
}
Confirm Callback必要每次发消息的时间都要配置（要订定发消息的id方便回执的时间直到是谁发的消息）这里写一个测试类方便各人看。
@Test
void testConfirmCallback() throws InterruptedException {
//创建cd 参数为每次发送消息的id
CorrelationData correlationData = new CorrelationData(UUID.randomUUID().toString());
//添加confirmCallBack
correlationData.getFuture().addCallback(new ListenableFutureCallback<CorrelationData.Confirm>() {
@Override
public void onFailure(Throwable ex) {
//这种情况一般是运行出现bug，一般不会发生。
log.error("消息回调失败",ex);
}
@Override
public void onSuccess(CorrelationData.Confirm result) {
log.debug("收到confirm callback 回执");
if (result.isAck()){
//消息发送成功
log.debug("消息发送成功收到ack");
}else {
//消息发送失败
log.debug("消息发送失败收到nack，原因：{}",result.getReason());
//TODO 重发消息等业务
}
}
});
rabbitTemplate.convertAndSend("amqp.test","amqptest","hello qjc",correlationData);
Thread.sleep(2000);
}
那么我们如何办理这个题目呢
方案一：重发消息
方案二：记录日志
方案三：保存到数据库中定时发送，发送乐成后删除表中的数据。
方案四：交给人工处置处罚。
~生产者确认机制必要额外的网络和系统的资源开销，尽量不要使用。
~假如业务必要，那么无需开启publisher-return机制，因为一般路由失败都是自己业务的原因。
~对于nack消息可以有限次数的重试，依然失败则记录异常消息。
层面二的办理方法常见的是
2.消息持久化
由于mq是基于内存存储消息的，那么在mq服务宕机等一些情况下可能导致消息的丢失。同时内存空间有限，当消耗者出现故障大概处置处罚过慢，会导致消息积存，mq会对消息做迁移（page out 写入磁盘）从而引发mq壅闭。我们将消息存储在磁盘上就制止了这个题目。
一 ：持久化交换机。
https://img-blog.csdnimg.cn/direct/e3b29a76e2b946fca8c4d760deb1a7c8.png
这里要选择Durable,因为Transient是临时交换机，当mq宕机后会消失。
或
代码展示
@Bean
public DirectExchange simpleExchange(){
//分别是三个参数 交换机名称 是否持久化 当没有队列绑定时是否自动删除
return new DirectExchange("qjc.exchange",true,false);
} 二 ：持久化队列。
https://img-blog.csdnimg.cn/direct/0b236dbbff8b463d8f49a7dd216b3dc2.png
这个与交换机类似，在此不做赘述。
或
代码展示
@Bean
public Queue simpleQueue(){
//springamqp在使用QueueBuilder来创建队列的时候，默认就是持久化的
return QueueBuilder.durable("qjc.queue").build();
} 三 ：持久化消息。
https://img-blog.csdnimg.cn/direct/b0d43cce24064cb9a9d0ed40090246b3.png
这里选择delivery mode 选择2 ,1是不持久的。
或
代码展示
Message message = MessageBuilder.withBody("hello".getBytes(StandardCharsets.UTF_8))
.setDeliveryMode(MessageDeliveryMode.PERSISTENT)
.build(); 假如不选择持久化队列，交换机，消息的话我们尚有另一种方案
Lazy Queue（惰性队列）
惰性队列的特征如下
~接受到消息的时间直接存入磁盘而非内存（内存中只保存最近的消息）
~消耗者必要消息的时间才会从磁盘中取出数据加载到内存
~支持数百万条的消息存储
在mq3.12版本后，全部的队列都是Lazy Queue模式，无法更改。
假如各位小伙伴的版本低于3.12那我这里提供了两种方式创建惰性队列
https://img-blog.csdnimg.cn/direct/9caa8581935049838daac38ada460df9.png
或
https://img-blog.csdnimg.cn/direct/fb1cf856571247498423eacb020fe0e5.png
或用注解声明
@RabbitListener(queuesToDeclare = @Queue(
name = "lazy.queue",
durable = "true",
arguments = @Argument(name = "x-queue-mode",value = "lazy")
))
public void listenLazyQueue(String msg){
log.debug("接收到lazyqueue的消息" + msg);
}
3.消耗者确认机制
RabbitMQ支持消耗者确认机制，即：当消耗者处置处罚消息后可以向mq发送ack回执，mq收到消息后会在队列中删除该消息。
https://img-blog.csdnimg.cn/direct/115274907b1b457a839654980455e9ee.png
SpringAMQP已经实现了消息确认的功能，而且允许我们通过配置文件选择ack的处置处罚方式，有三种方式。
- none: 不处置处罚。即消息投递给消耗者后立刻ack，消息会立刻从MQ删除。非常不安全，不建议使用
- manual: 手动模式。必要自己在业务代码中调用api，发送ack或reject，存在业务入侵，但更灵活
- auto: 主动模式。SpringAMQP使用AOP对我们的消息处置处罚逻辑做了环绕增强，当业务正常执行时则主动返回ack.
当业务出现异常时，根据异常判断返回差别结果:
- 假如是业务异常，会主动返回nack
- 假如是消息处置处罚或校验异常，主动返回reject
注意我们必要再消耗者的配置文件中参加参数
https://img-blog.csdnimg.cn/direct/674509e7e9ed403d8fd59a913b6510cf.png
这就是mq保证消息不丢失的一些方式和办理方案。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]