MQ的可靠性
在默认情况下,RabbitMQ会将接收到的信息保存在内存中以降低消息收发的延迟。这样会导致两个问题:
- 一旦MQ宕机,内存中的消息会丢失。
- 内存空间有限,当消费者故障或者处理过慢时,会导致消息积压,引发MQ阻塞。
解决方案
1.数据持久化
在早期MQ3.6之前,会采用这种模式,RabbitMQ实现数据持久化包括3个方面:
-
交换机的持久化
Transient属于临时的交换机,重启后不存在。默认是持久化创建 -
队列的持久化
和交换机的持久化类似 -
消息的持久化
发送消息时,delivery_mode设置为2表示持久化消息。
2.Lazy Queue
要设置一个队列为惰性队列,只需要在声明队列时,指定x-queue-mode属性为lazy即可:
public Queue lazyQueue(){
return QueueBuilder.durable("lazy.queue")
.lazy() //开启lazy模式
.build();
}
@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);
}
消费者确认机制
SpringAMQP已经实现了消息确认功能。并允许我们通过配置文件选择ACK处理方式,有三种方式:
none: 不处理。即消息投递给消费者后立刻ack,消息会立刻从MQ删除。非常不安全,不建议使用
manual: 手动模式。需要自己在业务代码中调用api,发送ack或rehect,存在业务入侵,但更灵活
auto: 自动模式。SpringAMQP利用AOP对我们的消息处理逻辑做了环绕增强,当业务正常执行时则自动返回ack.
当业务出现异常时,根据异常判断返回不同结果
- 如果是业务异常,会自动返回nack
- 如果是消息处理或校验异常,会自动返回reject
spring:
rabbitmq:
listener:
simple:
prefetch: 1
acknowledge-mode: none
消息失败处理
当消费者出现异常后,消息会不断requeue(重新入队)到队列,再重新发送给消费者,然后再次异常,再次requeue,无限循环,导致mq的消息处理飙升,带来不必要的压力。
我们可以利用spring的retry机制,在消费者出现异常时利用本地重试,而不是无限制的requeue到mq队列:
spring:
rabbitmq:
listener:
simple:
prefetch: 1
retry:
enable: true #开启消费者失败重试
initial-interval: 1000ms #初始的失败等待时长为 1秒
multiplier: 1 #下次失败的等待时长倍数,下次等待时长=multiplier * last-interval
max-attempts: 3 #最大重试次数
stateless: true # true无状态;false有状态,如果业务中包含事务,这里改为false
失败消息处理策略
在开启重试模式后,重试次数耗尽,如果消息依然失败,则需要有MessageRecoverer接口来处理,它包含三种不同的实现:
- RejectAndDontRequeueRecoverer: 重试耗尽后,直接reject,丢弃消息。默认就是这种方式
- ImmediateRequeueMessageRecoverer:重试耗尽后,返回nack,消息重新入队
- RepublishMessageRecoverer: 重试耗尽后,将失败消息投递到指定的交换机。
将失败处理策略改为RepublishMessageRecoverer:
①首先,定义接受失败消息的交换机,队列及其绑定关系,此处略;
②然后,定义ReplishMessageRecoverer:
@Configuration
@ConditionalOnProperty(name = "spring.rabbitmq.listener.simple.retry.enabled",havingValue = "true")
public class ErrorConfiguration {
@Bean
public DirectExchange errorExchange(){
return new DirectExchange("error.direct");
}
@Bean
public Queue errorQueue(){
return new Queue("error.queue");
}
@Bean
public Binding directQueueBindingerror(Queue errorQueue, DirectExchange errorExchange){
return BindingBuilder.bind(errorQueue).to(errorExchange).with("error");
}
@Bean
public MessageRecoverer recoverer(RabbitTemplate rabbitTemplate){
return new RepublishMessageRecoverer(rabbitTemplate,"error.direct","error");
}
通过配置RepublishMessageRecoverer来设置本地重试后发往收集异常信息的交换机。同时可以通过@ConditionalOnProperty设置是否开启
总结
消费者如何保证消息一定被消费?
- 开启消费者确认机制为auto,由spring确认消息处理成功后返回ack,异常时返回nack
- 开启消费者失败重试机制,并设置MessageRecoverer,多次重试失败后将消息投递到异常交换机,交由人工处理。
业务幂等性
幂等是一个数学概念,用函数表达式来描述是这样的:f(x)=f(f(x))。在程序开发中,则是指同一个业务,执行一次或多次对业务状态的影响是一致的。
解决方案:
唯一消息id
方案一,是给每个消息都设置一个唯一id,利用id区分是否是重复消息:
① 每一条消息都生成一个唯一的id,与消息一起投递给消费者。
② 消费者接收到消息后处理自己的业务,业务处理成功后将消息ID保存到数据库。
③ 如果下次又收到相同的消息,去数据库查询判断是否存在,存在则为重复消息放弃处理。
@Bean
public MessageConverter messageConverter(){
Jackson2JsonMessageConverter jackson2JsonMessageConverter = new Jackson2JsonMessageConverter();
//配置自动创建消息id,用于识别不同消息,也可以在业务中基于ID判断是否是重复消息
jackson2JsonMessageConverter.setCreateMessageIds(true);
return jackson2JsonMessageConverter;
}
配置消息转换器时,可以设置自动写入唯一id
方案二,是结合业务逻辑,基于业务本身做判断。以我们的业务为例:我们要在支付后修改订单状态为已支付,应该在修改订单状态前先查询订单状态,判断状态是否是未支付。只有未支付订单才需要修改,其他状态不做处理。
问题:
1.如何保证支付服务和交易服务之间的订单状态一致性
- 首先,支付服务会在用户支付成功后利用MQ消息通知交易服务,完成订单状态同步。
- 其次,为了保证MQ消息的可靠性,我们采用了生产者确认机制,消费者确认,消费者失败重试等策略,确保消息投递和处理的可靠性。同时也开启了MQ的持久化,避免因为服务宕机导致的消息丢失。
- 最后,我们还在交易服务更新订单状态时做了业务幂等性判断,避免因为消息重复消费导致订单状态异常。
2.如果交易服务消息处理失败,有没有什么兜底方案?
- 我们可以在交易服务设置定时任务,定期查询订单支付状态。这样即使MQ通知失败,还可以利用定时任务作为兜底方案,确保订单支付状态的最终一致性。