目录
前言
在MQTT协议中,给出了三种传递消息时能够提供的服务质量标准,这三种服务质量从低到高依次是:
- At most once:至多一次。消息在传递时,最多会被送达一次。也就是说,没什么消息可靠性保证,允许丢消息。
- At least once:至少一次。消息在传递时,至少会被送达一次。也就是说,不允许丢消息,但是允许有少量重复消息出现。
- Exactly once:恰好一次。消息在传递时,只会被送达一次,不允许丢失也不允许重复,这个是最高的等级 这个服务质量标准不仅适用于MQTT,对所有的消息队列都是适用的。现在常用的绝大部分消息队列提供的服务质量都是 At least once,包括RocketMQ、RabbitMQ和Kafka都是这样。也就是说,消息队列很难保证消息不重复。
At least once+幂等消费=Exactly once
消息消费的步骤:
- 生产端发送消息到RabbitMQ;
- RabbitMQ发送消息到消费端;
- 消费端消费这条消息;
消息丢失的原因
- 生产者没有成功发送到MQ;
- 消息发送到MQ后,MQ宕机导致内存的消息数据丢失;
- 消费者获取到消息,但是消费者还没来得及处理就宕机了,但此时MQ中消息已经删除,消费者重启后不能再消费之前的消息;
确保消息不丢失的方案
- 生产者发送MQ后,MQ给生产者确认收到;
- MQ收到消息后进行消息持久化;
- 消费者收到消息,处理完毕后,手动进行ack确认;
- MQ收到消费者ack确认后,删除持久化的消息;
生产者可靠性投递
1.事务消息机制:
// 设置channel开启事务
rabbitTemplate.setChannelTransacted(true);
@Bean
public RabbitTransactionManager rabbitTransactionManager(ConnectionFactory connectionFactory)
{
return new RabbitTransactionManager(connectionFactory);
}
@Transactional(rollbackFor = Exception.class,transactionManager = "rabbitTransactionManager")
public void publishMessage(String message) throws Exception {
rabbitTemplate.setMandatory(true);
rabbitTemplate.convertAndSend("javatrip",message);
}
事务消息机制由于会严重降低性能,所以一般不采用这种方法,因为这是同步操作,一条消息发送之后会使发送端阻塞,以等待RabbitMQ-Server的回应,之后才能继续发送下一条消息,生产者生产消息的吞吐量和性能都会大大降低。
2.confirm消息确认机制(推荐)
顾名思义,就是生产端投递的消息一旦投递到RabbitMQ后,RabbitMQ就会发送一个确认消息(ack)给生产端,让生产端知道我已经收到消息了,如果rabbitmq没能处理该消息,会发送一个Nack给生产者,生产端可以重新发送消息。
# 开启发送确认
spring.rabbitmq.publisher-confirm-type=correlated
# 开启发送失败回退
spring.rabbitmq.publisher-returns=true
@Configuration
@Slf4j
public class RabbitMQConfig {
@Autowired
private RabbitTemplate rabbitTemplate;
@PostConstruct
public void enableConfirmCallback() {
//confirm 监听,当消息成功发到交换机 ack = true,没有发送到交换机 ack = false
//correlationData 可在发送时指定消息唯一 id
rabbitTemplate.setConfirmCallback((correlationData, ack, cause) -> {
if(!ack){
//记录日志、发送邮件通知、落库定时任务扫描重发
}
});
//当消息成功发送到交换机没有路由到队列触发此监听
rabbitTemplate.setReturnsCallback(returned -> {
//记录日志、发送邮件通知、落库定时任务扫描重发
});
}
}
实际在这两个监听里面去做重发并不是很多,因为成本太高了,首先 RabbitMQ 本身丢失的可能性就非常低,其次如果这里需要落库再用定时任务扫描重发还要开发一堆代码,分布式定时任务…再其次定时任务扫描肯定会增加消息延迟,不是很有必要。真实业务场景是记录一下日志就行了,方便问题回溯,顺便发个邮件给相关人员,如果真的极其罕见的是生产者弄丢消息,那么开发往数据库补数据就行了。
消息持久化
RabbitMQ收到消息后将这个消息暂时存在了内存中,如果RabbitMQ挂了,那重启后数据就丢失了,所以相关的数据应该持久化到硬盘中,需要给exchange、queue和message都进行持久化。
这个持久化配置可以和confirm机制配合使用,可以在消息持久化磁盘后,再给生产者发送一个ACK信号,这样如果消息持久化磁盘之前,rabbitmq阵亡了,那么生产者收不到ack信号,生产者会自动重发。 这样即使mq挂了,重启后也能恢复数据。
@Bean
public Queue TestQueue() {
// durable:是否持久化,默认是false,持久化队列:会被存储在磁盘上,当消息代理重启时仍然存在,暂存队列:当前连接有效
// exclusive:该队列是否只供一个消费者进行消费是否进行消息共享,true可以多个消费者消费,false:只能-一个消费者消费
// autoDelete:是否自动删除,当没有生产者或者消费者使用此队列,该队列会自动删除。
return new Queue("test",true,true,false);
}
在Spring Boot中消息默认就是持久化的。
消费者可靠性投递
RabbitMQ的自动ack机制工作流程如下:
- 1. 消费者接收到消息并开始处理。
- 2. 一旦消息被成功处理且没有发生异常,RabbitMQ会立即将消息从队列中删除。
- 3. 如果消费者在处理消息期间发生了异常,消息将会被重新放回队列中以便后续重新处理。
这种机制确保了当消费者成功处理消息时,消息会被立即删除,从而避免重复消费。
ACK机制改为手动
RabbitMQ的手动ack机制工作流程如下:
1. 消费者接收到消息并开始处理。
2. 消费者在处理完消息后,显式发送acknowledgement(ACK)给RabbitMQ来确认消息已经被处理。
3. 一旦RabbitMQ接收到ACK,它会将消息从队列中删除。
4. 如果消费者在处理消息期间发生了异常,可以选择不发送ACK,这样消息会被重新放回队列中以便后续重新处理。
这种机制允许消费者控制何时确认消息的处理完成,从而确保消息在被处理后才会被删除。
#开启手动ACK,消费消息的时候,就必须发送ack确认,不然消息永远还在队列中
spring.rabbitmq.listener.simple.acknowledge-mode=manual
这里要小心! basicNack 方法的第三个参数代表是否重回队列,通常代码的报错并不会因为重试就能解决,所以可能这种情况:继续被消费,继续报错,重回队列,继续被消费…死循环。
一定要有重发消息次数的限制,或者干脆不入队,发送到Redis进行下记录也行。
SpringBoot 提供的消息重试
SpringBoot 给我们提供了一种重试机制,当消费者执行的业务方法报错时会重试执行消费者业务方法。
启用 SpringBoot 提供的重试机制
spring.rabbitmq.listener.simple.retry.enabled=true
# 重试次数
spring.rabbitmq.listener.simple.max-attempts=3
# 重试时间间隔
spring.rabbitmq.listener.simpleinitial-interval: 3000
消费者代码:
@RabbitListener(queues = "queue")
public void listen(String object, Message message, Channel channel) throws IOException {
try {
/**
* 执行业务代码...
* */
int i = 1 / 0; //故意报错测试
} catch (Exception e) {
log.error("签收失败", e);
/**
* 记录日志、发送邮件、保存消息到数据库,落库之前判断如果消息已经落库就不保存
* */
throw new RuntimeException("消息消费失败");
}
}
注意一定要手动 throw 一个异常,因为 SpringBoot 触发重试是根据方法中发生未捕捉的异常来决定的。值得注意的是这个重试是 SpringBoot 提供的,重新执行消费者方法,而不是让 RabbitMQ 重新推送消息。