RabbitMQ消息丢失的三种情况
第一种:生产者弄丢了数据。生产者将数据发送到 RabbitMQ 的时候,可能数据就在半路给搞丢了,因为网络问题啥的,都有可能。
第二种:RabbitMQ 弄丢了数据。MQ还没有持久化自己挂了。
第三种:消费端弄丢了数据。刚消费到,还没处理,结果进程挂了,比如重启了。
RabbitMQ消息丢失解决方案
针对生产者
1、开启RabbitMQ事务
可以选择用 RabbitMQ 提供的事务功能,就是生产者发送数据之前开启 RabbitMQ 事务channel.txSelect,然后发送消息,如果消息没有成功被 RabbitMQ 接收到,那么生产者会收到异常报错,此时就可以回滚事务channel.txRollback,然后重试发送消息;如果收到了消息,那么可以提交事务channel.txCommit。
// 开启事务
channel.txSelect();
try {
// 这里发送消息
} catch (Exception e) {
channel.txRollback();
// 这里再次重发这条消息
}
// 提交事务
channel.txCommit();
缺点:
RabbitMQ 事务机制是同步的,你提交一个事务之后会阻塞在那儿,采用这种方式基本上吞吐量会下来,因为太耗性能。
2、使用confirm机制
事务机制和 confirm 机制最大的不同在于,事务机制是同步的,你提交一个事务之后会阻塞在那儿,但是 confirm 机制是异步的
在生产者开启了confirm模式之后,每次写的消息都会分配一个唯一的id,然后如果写入了rabbitmq之中,rabbitmq会给你回传一个ack消息,告诉你这个消息发送OK了;如果rabbitmq没能处理这个消息,会回调你一个nack接口,告诉你这个消息失败了,你可以进行重试。而且你可以结合这个机制知道自己在内存里维护每个消息的id,如果超过一定时间还没接收到这个消息的回调,那么你可以进行重发。
//开启confirm
channel.confirm();
//发送成功回调
public void ack(String messageId){
}
// 发送失败回调
public void nack(String messageId){
//重发该消息
}
针对RabbitMQ
RabbitMQ 自己弄丢了数据,这个必须要开启 RabbitMQ消息的持久化,就是消息写入之后会持久化到磁盘,哪怕是 RabbitMQ 自己挂了,恢复之后会自动读取之前存储的数据,一般数据不会丢失。
解决办法:
设置持久化有两个关注点:
第一个是创建 queue 的时候将其设置为持久化
第二个是发送消息的时候将消息设置为持久化
第一种:元配置持久化
在创建交换机和队列的时候,将其设置为持久化,这样就算重启RabbitMQ或者突然断电,元数据信息也会从磁盘中进行读取,这样就可以保证RabbitMQ 持久化 queue 的元数据,但是不会持久化 queue 里的数据。
// 1. 创建持久化交换器 如果不存在自动创建
channel.exchangeDeclare(rabbitConfigDTO.getExchange(), BuiltinExchangeType.TOPIC, true);
// 2. 创建持久化队列 如果不存在自动创建
channel.queueDeclare(rabbitConfigDTO.getQueue(), true, false, false, null);
channel.queueBind(rabbitConfigDTO.getQueue(), rabbitConfigDTO.getExchange(), rabbitConfigDTO.getRoutingkey());
第二种:消息持久化
发送消息的时候将消息的deliveryMode设置为2,或者是
MessageProperties.PERSISTENT_TEXT_PLAIN 就是将消息设置为持久化的,此时 RabbitMQ 就会将消息持久化到磁盘上去。必须要同时设置这两个持久化才行,RabbitMQ 哪怕是挂了,再次重启,也会从磁盘上重启恢复 queue,恢复这个 queue 里的数据。
下面是采用springboot整合的rabbitTemplate来实现消息发送
MessageProperties props = new MessageProperties();
props.setDeliveryMode(MessageDeliveryMode.PERSISTENT); // 设置为持久化模式
Message message = new Message(payload, props);
rabbitTemplate.send(exchange, routingKey, message);
// 或者直接传递Message对象,其中包含已设置持久化的MessageProperties
rabbitTemplate.convertAndSend(exchange, routingKey, new Message(messageBody, props));
// 或者使用MessagePostProcessor接口动态设置消息属性
rabbitTemplate.convertAndSend(
exchange,
routingKey,
messageBody,
new MessagePostProcessor() {
@Override
public Message postProcessMessage(Message message) throws AmqpException {
message.getMessageProperties().setDeliveryMode(MessageDeliveryMode.PERSISTENT);
return message;
}
}
);
下面是采用SpringBoot中通过new来创建连接来实现消息发送
Connection connection = new RabbitMQUtils(rabbitConnectionUrlDTO.getIp(), rabbitConnectionUrlDTO.getPort(), rabbitConnectionUrlDTO.getVirtualhost(), rabbitConnectionUrlDTO.getUsername(), rabbitConnectionUrlDTO.getPassword()).getConnection();
if (Objects.nonNull(connection)) {
log.warn("共" + RABBIT_CONNECTION_URL_LIST.size() + "个连接!");
Channel channel = connection.createChannel();
//消息持久化到磁盘,避免因为突然断电或重启导致消息丢失
channel.basicPublish(rabbitConnectionUrlDTO.getExchange(), rabbitConnectionUrlDTO.getRoutingkey(), MessageProperties.PERSISTENT_TEXT_PLAIN, JSONObject.toJSONString(map).getBytes(StandardCharsets.UTF_8));
log.warn("连接RabbitMQ成功!" + "IP地址为" + rabbitConnectionUrlDTO.getIp() + "端口号为" + rabbitConnectionUrlDTO.getPort() + "交换器为" + rabbitConnectionUrlDTO.getExchange() + "队列名为" + rabbitConnectionUrlDTO.getQueue() + "路由键为" + rabbitConnectionUrlDTO.getRoutingkey());
}
消费者确认机制
如果上述生产端
、消息队列
都正确投递,那么问题出现在消费端
是否可以正确消费?
消费者在成功处理了一条消息后通知RabbitMQ,这样RabbitMQ在收到确认后才会移除队列中的消息。
默认情况下,以下3种原因导致消息丢失:
1、 网络故障
:消费端还没接收到消息之前,发生网络故障导致消息丢失;
2、 未接收消息前服务宕机
:消费端突然挂机未接收到消息,此时消息会丢失;
3、 处理过程中服务宕机
:消费端正确接收到消息,但在处理消息的过程中发生异常或宕机了,消息也会丢失。
这是因为RabbitMQ的自动ack
机制,即默认RabbitMQ在消息发出后,不管消费端是否接收到,是否处理完,就立即删除这条消息,导致消息丢失。
应对方案:
-
将自动ack机制改为手动ack机制。
DeliverCallback deliverCallback = (consumerTag, delivery) -> {
try {
//接收消息,业务处理
//设置手动确认
channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false);
} catch (Exception e) {
//发生异常时,可以选择重新发送消息或进行错误处理
// 例如,可以选择负确认(nack),让消息重回队列
// channel.basicNack(delivery.getEnvelope().getDeliveryTag(), false, true);
}
};
//设置autoAck为false,表示关闭自动确认机制,改为手动确认
channel.basicConsume(QUEUE_NAME, autoAck, deliverCallback, consumerTag -> {});
消息补偿机制
以上3种解决办法理论上可靠,但是系统的异常或者故障比较偶然,我们没法做到100%消息不丢失。因此需要介入补偿机制
或者人工干预
。这是我们的最后一道防线。
如何做消息补偿呢?其实就是将消息入库,通过定时任务
重新发送失败的消息。详细流程如下:
-
生产端发送消息;
-
确认失败,将消息保存到数据库中,并设置初始状态0;
-
定时任务以一定频率扫描数据库中status=0 的消息(失败消息);
-
重发消息,可多次;
-
重发成功,更新数据库:status=1;
-
超过固定次数重发仍然失败,人工干预。
标注:
超过最大失败次数后,对于无法被正常消费的消息可移入死信队列
。
-
可人工干预手动排查
-
也可自动重试,需要实现一个消费者来从死信队列中获取消息,并根据业务逻辑来决定是否以及如何重新发送消息。这里涉及到消息去重、幂等性处理等。