在消息传递过程中,可能遇到各种问题,如网络故障,服务不可用,资源不足等,这些问题可能导致消息处理失败,为了解决这些问题,RabbitMQ提供了重试机制,循序消息处理失败后重新发送.
1.1重试配置
retry:
enabled: true # 开启消费者失败重试
initial-interval: 5000ms # 初始失败等待时⻓为 5 秒
max-attempts: 5 # 最⼤重试次数 ( 包括⾃⾝消费的一次)
1.2手动确认和自动确认下重试的区别
自动确认模式下,RabbitMQ会在消息被投递给消费者后自动确认消息,如果消费者处理消息时抛出异常,RabbitMQ根据配置的重试参数自动将消息重新入队,从而实现重试,重试次数和重试间隔等参数可以在RabbitMQ的配置中设定。
但是手动确认模式下,消费者需要显式地对消息进行确认,如果消费者在处理消息时遇到异常,可以选择不确认消息使消息可以重新入队,重试的控制权在于应用程序本身,而不是RabbitMQ的内部机制,应用程序可以通过自己的逻辑和利用RabbitMQ的高级特性来实现有效的重试策略。
1.3重试机制的注意事项
1.手动确认模式下:程序逻辑异常,多次重试消息依然处理失败,无法被确认,就一直是unacked状态,导致消息挤压.
2.自动确认模式下:程序逻辑异常,多次重试还是失败,消息就会被自动确认,那么消息就丢失了
2.TTL
TTL(time to live)就是过期时间,RabbitMQ可以对消息和队列设置TTL
当消息达到存货时间之后,还没有被消费,就会被自动清除
比如我们在网上购物,一定时间内没有付款,订单就会被自动取消
2.1设置消息的TTL
目前有两种方法设置消息的TTL.
一种时设置队列的TTL,队列中所有消息都有相同的过期时间.二是对消息本身进行单独设置,每条消息都TTL都可以不同,如果两种方法一起用,则消息的TTL以两者之间较小的那个数值为准.
先说明对每条消息设置TTL.可在发送消息的方法中加入expiration的属性参数,单位为毫秒.
messagePostProcessor.getMessageProperties().setExpiration(ttlTime);
2.2设置队列的TTL
设置队列的TTL方法就是在创建队列时加入x-message-ttl参数实现的,单位时毫秒.
java
@Bean("ttlQueue2")
public Queue ttlQueue2() {
//设置20秒过期
return QueueBuilder.durable(Constant.TTL_QUEUE2).ttl(20*1000).build();
}
2.3两者的区别
设置队列TTL属性的方法,一旦消息过期就会立马从队列中删除.
设置消息TTL的方法,即使消息过期,也不会马上从队列中删除,而是在即将投递到消费者之前进行判定的.
为什么会这样呢?
因为设置队列过期时间,队列中已过期的消息肯定在队列头部,RabbitMQ只要定期从对头开始扫描是否有过期消息即可.
而设置消息TTL的方式,每条消息的过期时间不同,如果要删除所有过期消息就需要扫描整个队列,所以不如等到此消息即将被消费时再判定是否过期,如果过期在进行删除即可.