MQ的一些常见问题
消息可靠性问题:如何确保发送的消息至少被消费一次
延迟消息问题:如何实现消息的延迟投递
消息堆积问题:如何解决数百万消息堆积,无法及时消费的问题
高可用问题:如何避免单点的MQ故障而导致的不可用问题
目录
1.1.1 在publisher这个微服务的application.yml中添加配置
1.1.2 每个RabbitTemplate只能配置一个ReturnCallback,因此需要在项目启动过程中配置
1.1.3 发送消息,指定消息ID、消息ConfirmCallback
3.2.3.基于@RabbitListener声明LazyQueue
1、消息可靠性-解决消息可靠性问题
消息从生产者发送到exchange,再到queue,再到消费者,有哪些导致消息丢失的可能性?
发送时丢失:• 生产者发送的消息未送达 exchange• 消息到达 exchange 后未到达 queueMQ 宕机, queue 将消息丢失consumer 接收到消息后未消费就宕机![]()
针对这些问题,RabbitMQ分别给出了解决方案:①生产者确认机制②mq持久化③消费者确认机制④失败重试机制
1.1 生产者确认机制
1.1.1 在publisher这个微服务的application.yml中添加配置
spring:
rabbitmq:
publisher-confirm-type: correlated
publisher-returns: true
template:
mandatory: true
publish-confirm-type:开启publisher-confirm,这里支持两种类型:
simple:同步等待confirm结果,直到超时
correlated:异步回调,定义ConfirmCallback,MQ返回结果时会回调这个ConfirmCallback
publish-returns:开启publish-return功能,同样是基于callback机制,不过是定义ReturnCallback
template.mandatory:定义消息路由失败时的策略。true,则调用ReturnCallback;false:则直接丢弃消息
1.1.2 每个RabbitTemplate只能配置一个ReturnCallback,因此需要在项目启动过程中配置
消息成功发送到exchange,但没有路由到queue,调用ReturnCallback
@Slf4j
@Configuration
public class CommonConfig implements ApplicationContextAware {
@Override
public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
// 获取RabbitTemplate
RabbitTemplate rabbitTemplate = applicationContext.getBean(RabbitTemplate.class);
// 设置ReturnCallback
rabbitTemplate.setReturnCallback((message, replyCode, replyText, exchange, routingKey) -> {
// 投递失败,记录日志
log.info("消息发送失败,应答码{},原因{},交换机{},路由键{},消息{}",
replyCode, replyText, exchange, routingKey, message.toString());
// 如果有业务需要,可以重发消息
});
}
}
1.1.3 发送消息,指定消息ID、消息ConfirmCallback
ConfirmCallback可以在发送消息时指定,因为每个业务处理confirm成功或失败的逻辑不一定相同。
•消息成功发送到exchange,返回ack
•消息发送失败,没有到达交换机,返回nack
@Test
public void testSendMessage2SimpleQueue() throws InterruptedException {
// 1.消息体
String message = "hello, spring amqp!";
// 2.全局唯一的消息ID,需要封装到CorrelationData中
CorrelationData correlationData = new CorrelationData(UUID.randomUUID().toString());
// 3.添加callback
correlationData.getFuture().addCallback(
result -> {
if(result.isAck()){
// 3.1.ack,消息成功
log.debug("消息发送成功, ID:{}", correlationData.getId());
}else{
// 3.2.nack,消息失败
log.error("消息发送失败, ID:{}, 原因{}",correlationData.getId(), result.getReason());
}
},
ex -> log.error("消息发送异常, ID:{}, 原因{}",correlationData.getId(),ex.getMessage())
);
// 4.发送消息
rabbitTemplate.convertAndSend("task.direct", "task", message, correlationData);
// 休眠一会儿,等待ack回执
Thread.sleep(2000);
}
1.2 mq消息持久化
生产者确认可以确保消息投递到RabbitMQ的队列中,但是消息发送到RabbitMQ以后,如果突然宕机,也可能导致消息丢失。
要想确保消息在RabbitMQ中安全保存,必须开启消息持久化机制。交换机持久化、队列持久化、消息持久化
1.2.1 交换机持久化
RabbitMQ中交换机默认是非持久化的,mq重启后就丢失。 SpringAMQP中可以通过代码指定交换机持久化:
@Bean
public DirectExchange simpleExchange(){
// 三个参数:交换机名称、是否持久化、当没有queue与其绑定时是否自动删除
return new DirectExchange("simple.direct", true, false);
// 默认情况下,由SpringAMQP声明的交换机都是持久化的。因此等价于
// return new DirectExchange("simple.direct");
}
【注】但事实上,默认情况下,由SpringAMQP声明的交换机都是持久化的。
1.2.2 队列持久化
RabbitMQ中队列默认是非持久化的,mq重启后就丢失。SpringAMQP中可以通过代码指定交换机持久化:
@Bean
public Queue simpleQueue(){
// 使用QueueBuilder构建队列,durable就是持久化的
return QueueBuilder.durable("simple.queue").build();
// 默认情况下,由SpringAMQP声明的队列都是持久化的,因此等价于
// return new Queue("simple.queue");
}
【注】但事实上,默认情况下,由SpringAMQP声明的队列都是持久化的
1.2.3 消息持久化
// 等价于
rabbitTemplate.convertAndSend("task.direct", "task", message, correlationData);
【注】但默认情况下,SpringAMQP发出的任何消息都是持久化的,不用特意指定
1.3 消费者确认机制
修改consumer服务的application.yml文件,添加下面内容
spring:
rabbitmq:
listener:
simple:
acknowledge-mode: auto # none关闭ack;manual手动ack;auto自动ack
在异常位置打断点,再次发送消息,程序卡在断点时,可以发现此时消息状态为unack(未确定状态) 。抛出异常后,因为Spring会自动返回nack,所以消息恢复至Ready状态,并且没有被RabbitMQ删除 。
当消费者出现异常后,消息会不断requeue(重入队)到队列,再重新发送给消费者,然后再次异常,再次requeue,无限循环,导致mq的消息处理飙升,带来不必要的压力:
1.4 消息失败重试机制
1.4.1 本地重试
我们可以利用Spring的retry机制,在消费者出现异常时利用本地重试,而不是无限制的requeue到mq队列。
修改consumer服务的application.yml文件,添加内容:
spring:
rabbitmq:
listener:
simple:
retry:
enabled: true # 开启消费者失败重试
initial-interval: 1000 # 初识的失败等待时长为1秒
multiplier: 1 # 失败的等待时长倍数,下次等待时长 = multiplier * last-interval
max-attempts: 3 # 最大重试次数
stateless: true # true无状态;false有状态。如果业务中包含事务,这里改为false
重启consumer服务,重复之前的测试。可以发现:
①在重试3次后,SpringAMQP会抛出异常AmqpRejectAndDontRequeueException,说明本地重试触发了
②查看RabbitMQ控制台,发现消息被删除了,说明最后SpringAMQP返回的是ack,mq删除消息了结论:
①开启本地重试时,消息处理过程中抛出异常,不会requeue到队列,而是在消费者本地重试
②重试达到最大次数后,Spring会返回ack,消息会被丢弃,这是由Spring内部机制决定的
1.4.2 失败策略
在开启重试模式后,重试次数耗尽,如果消息依然失败,则需要有MessageRecovery接口来处理,它包含三种不同的实现:①RejectAndDontRequeueRecoverer:重试耗尽后,直接reject,丢弃消息。默认就是这种方式
②ImmediateRequeueMessageRecoverer:重试耗尽后,返回nack,消息重新入队
③RepublishMessageRecoverer:重试耗尽后,将失败消息投递到指定的交换机【推荐】
测试RepublishMessageRecoverer,失败后将消息投递到一个指定的,专门存放异常消息的队列,后续由人工集中处理。
@Configuration
public class ErrorMessageConfig {
@Bean
public DirectExchange errorMessageExchange(){
return new DirectExchange("error.direct");
}
@Bean
public Queue errorQueue(){
return new Queue("error.queue", true);
}
@Bean
public Binding errorBinding(Queue errorQueue, DirectExchange errorMessageExchange){
return BindingBuilder.bind(errorQueue).to(errorMessageExchange).with("error");
}
@Bean
public MessageRecoverer republishMessageRecoverer(RabbitTemplate rabbitTemplate){
return new RepublishMessageRecoverer(rabbitTemplate, "error.direct", "error");
}
}
1.5 总计:如何确保RabbitMQ消息的可靠性?
2、死信交换机-解决延迟消息问题
2.1 初识死信交换机
当一个队列中的消息满足下列情况之一时,可以成为死信(dead letter):
• 消费者使用 basic.reject 或 basic.nack 声明消费失败,并且消息的 requeue 参数设置为false。即• 消息被消费者 reject 或者返回 nack• 消息超时未消费• 要投递的队列消息堆积满了,最早的消息可能成为死信
如何给队列绑定死信交换机?
如果该队列配置了dead-letter-exchange属性,指定了一个交换机,那么队列中的死信就会投递到这个交换机中,而这个交换机称为死信交换机(Dead Letter Exchange,简称DLX)。
队列将死信投递给死信交换机时,必须知道两个信息:①死信交换机名称②死信交换机与死信队列绑定的RoutingKey
这样才能确保投递的消息能到达死信交换机,并且正确的路由到死信队列。
利用死信交换机接收死信(拓展)
在失败重试策略中,默认的RejectAndDontRequeueRecoverer会在本地重试次数耗尽后,发送reject给RabbitMQ,消息变成死信,被丢弃。
我们可以给simple.queue添加一个死信交换机,给死信交换机绑定一个队列。这样消息变成死信后也不会丢弃,而是最终投递到死信交换机,路由到与死信交换机绑定的队列
我们在consumer服务中,定义一组死信交换机、死信队列:
// 声明普通的 simple.queue队列,并且为其指定死信交换机:dl.direct
@Bean
public Queue simpleQueue2(){
return QueueBuilder.durable("simple.queue") // 指定队列名称,并持久化
.deadLetterExchange("dl.direct") // 指定死信交换机
.build();
}
// 声明死信交换机 dl.direct
@Bean
public DirectExchange dlExchange(){
return new DirectExchange("dl.direct", true, false);
}
// 声明存储死信的队列 dl.queue
@Bean
public Queue dlQueue(){
return new Queue("dl.queue", true);
}
// 将死信队列 与 死信交换机绑定
@Bean
public Binding dlBinding(){
return BindingBuilder.bind(dlQueue()).to(dlExchange()).with("simple");
}
2.2 TTL(存活时间)
TTL,也就是Time-To-Live。如果一个队列中的消息TTL结束仍未消费,则会变为死信,ttl超时分为两种情况:
• 消息所在的队列设置了存活时间• 消息本身设置了存活时间 (消息到达队列的那一刻,开始倒计时)![]()
2.2.1 接收超时死信的死信交换机
声明一组死信交换机和队列,基于注解方式
@RabbitListener(bindings = @QueueBinding(
value = @Queue(name = "dl.queue", durable = "true"),
exchange = @Exchange(name = "dl.direct"),
key = "dl"
))
public void listenDlQueue(String msg){
log.info("接收到 dl.ttl.queue的延迟消息:{}", msg);
}
2.2.2 声明一个队列,并且指定TTL
要给队列设置超时时间,需要在声明队列时配置x-message-ttl属性 (消息所在的队列设置了存活时间)
@Configuration
public class TTLMessageConfig {
@Bean
public DirectExchange ttlDirectExchange(){
return new DirectExchange("ttl.direct");
}
@Bean
public Queue ttlQueue(){
return QueueBuilder
.durable("ttl.queue")
.ttl(10000)
.deadLetterExchange("dl.direct")
.deadLetterRoutingKey("dl")
.build();
}
@Bean
public Binding ttlBinding(){
return BindingBuilder.bind(ttlQueue()).to(ttlDirectExchange()).with("ttl");
}
}
发送消息
@Test
public void testTTLMessage() {
// 1.准备消息
Message message = MessageBuilder
.withBody("hello, ttl messsage".getBytes(StandardCharsets.UTF_8))
.setDeliveryMode(MessageDeliveryMode.PERSISTENT)
.build();
// 2.发送消息
rabbitTemplate.convertAndSend("ttl.direct", "ttl", message);
// 3.记录日志
log.info("消息已经成功发送!");
}
2.2.3 发送消息时,设定ttl
@Test
public void testTTLMessage() {
// 1.准备消息
Message message = MessageBuilder
.withBody("hello, ttl messsage".getBytes(StandardCharsets.UTF_8))
.setDeliveryMode(MessageDeliveryMode.PERSISTENT)
.setExpiration("5000")
.build();
// 2.发送消息
rabbitTemplate.convertAndSend("ttl.direct", "ttl", message);
// 3.记录日志
log.info("消息已经成功发送!");
}
【注】两者共存时,以时间短的ttl为准
2.3 延迟队列
利用TTL结合死信交换机,我们实现了消息发出后,消费者延迟收到消息的效果。这种消息模式就称为延迟队列(Delay Queue)模式。
延迟队列的使用场景包括:
• 延迟发送短信• 用户下单, 如果用户在 15 分钟内未支付,则自动取消• 预约工作会议, 20 分钟后自动通知所有参会人员
因为延迟队列的需求非常多,所以RabbitMQ的官方也推出了一个插件,原生支持延迟队列效果。
详细安装过程参考课前资料文档《RabbitMQ部署指南.md》中的第2节《安装DelayExchange插件》
使用DelayExchange
插件的使用也非常简单:声明一个交换机,交换机的类型可以是任意类型,只需要设定delayed属性为true即可,然后声明队列与其绑定即可。
2.3.1 声明DelayExchange交换机
基于注解
基于Bean
2.3.2 发送消息
然后我们向这个delay为true的交换机中发送消息,一定要给消息添加一个header:x-delay,值为延迟的时间,单位为毫秒:
发送消息时,因为设置了队列延迟时间,所以会报错,因此修改1.1.2
@Slf4j
@Configuration
public class CommonConfig implements ApplicationContextAware {
@Override
public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
// 获取RabbitTemplate对象
RabbitTemplate rabbitTemplate = applicationContext.getBean(RabbitTemplate.class);
// 配置ReturnCallback
rabbitTemplate.setReturnCallback((message, replyCode, replyText, exchange, routingKey) -> {
// 判断是否是延迟消息
Integer receivedDelay = message.getMessageProperties().getReceivedDelay();
if (receivedDelay != null && receivedDelay > 0) {
// 是一个延迟消息,忽略这个错误提示
return;
}
// 记录日志
log.error("消息发送到队列失败,响应码:{}, 失败原因:{}, 交换机: {}, 路由key:{}, 消息: {}",
replyCode, replyText, exchange, routingKey, message.toString());
// 如果有需要的话,重发消息
});
}
}
3、惰性队列-解决消息堆积问题
3.1 消息堆积问题
当生产者发送消息的速度超过了消费者处理消息的速度,就会导致队列中的消息堆积,直到队列存储消息达到上限。最早接收到的消息,可能就会成为死信,会被丢弃,这就是消息堆积问题。
解决消息堆积有三种种思路:
•增加更多消费者,提高消费速度
•在消费者内开启线程池加快消息处理速度
•扩大队列容积,提高堆积上限
3.2 惰性队列
从RabbitMQ的3.6.0版本开始,就增加了Lazy Queues的概念,也就是惰性队列。
惰性队列的特征如下:
• 接收到消息后 直接存入磁盘而非内存• 消费者要消费消息时才会从磁盘中读取并加载到内存• 支持数百万条的消息存储
3.2.1.基于命令行设置lazy-queue
而要设置一个队列为惰性队列,只需要在声明队列时,指定x-queue-mode属性为lazy即可。可以通过命令行将一个运行中的队列修改为惰性队列
rabbitmqctl set_policy Lazy "^lazy-queue$" '{"queue-mode":"lazy"}' --apply-to queues
3.2.2.基于@Bean声明lazy-queue
3.2.3.基于@RabbitListener声明LazyQueue
3.3.总结
4、MQ集群-解决高可用问题
4.1 集群分类
RabbitMQ的是基于Erlang语言编写,而Erlang又是一个面向并发的语言,天然支持集群模式。RabbitMQ的集群有两种模式:
•普通集群:是一种分布式集群,将队列分散到集群的各个节点,从而提高整个集群的并发能力。
•镜像集群:是一种主从集群,普通集群的基础上,添加了主从备份功能,提高集群的数据可用性。
镜像集群虽然支持主从,但主从同步并不是强一致的,某些情况下可能有数据丢失的风险。
因此在RabbitMQ的3.8版本以后,推出了新的功能:
仲裁队列来代替镜像集群,底层采用Raft协议确保主从的数据一致性。
4.2 普通集群
普通集群,或者叫标准集群(classic cluster),具备下列特征:
•会在集群的各个节点间共享部分数据,包括:交换机、队列元信息。不包含队列中的消息。
•当访问集群某节点时,如果队列不在该节点,会从数据所在节点传递到当前节点并返回
•队列所在节点宕机,队列中的消息就会丢失《RabbitMQ部署指南.md》
4.3 镜像集群
镜像集群:本质是主从模式,具备下面的特征:
•交换机、队列、队列中的消息会在各个mq的镜像节点之间同步备份。
•创建队列的节点被称为该队列的主节点,备份到的其它节点叫做该队列的镜像节点。
•一个队列的主节点可能是另一个队列的镜像节点
•所有操作都是主节点完成,然后同步给镜像节点
•主宕机后,镜像节点会替代成新的主《RabbitMQ部署指南.md》
4.4 仲裁队列
仲裁队列:仲裁队列是3.8版本以后才有的新功能,用来替代镜像队列,具备下列特征:
•与镜像队列一样,都是主从模式,支持主从数据同步
•使用非常简单,没有复杂的配置
•主从同步基于Raft协议,强一致
《RabbitMQ部署指南.md》
SpringAMQP连接集群,只需要在yaml中配置即可: