03-rabbitMQ可靠性投递与高可用

最新推荐文章于 2023-03-28 20:14:17 发布

VwenbinV

最新推荐文章于 2023-03-28 20:14:17 发布

阅读量156

点赞数

文章标签：队列交换机分布式数据库 redis

本文链接：https://blog.csdn.net/weixin_39169791/article/details/105099027

版权

rabbitMQ可靠性投递与高可用

可靠性投递

在使用RabbitMQ实现异步通信的时候，消息丢了怎么办，消息重复消费怎么办?

在RabbitMQ里面提供了很多保证消息可靠投递的机制，这个也是RabbitMQ的一个特性。

我们在讲可靠性投递的时候，必须要明确一个问题，因为效率与可靠性是无法兼得的，如果要保证每一个环节都成功，势必会对消息的收发效率造成影响。所以如果是一些业务实时一致性要求不是特别高的场合，可以牺牲一些可靠性来换取效率。

比如发送通知或者记录日志的这种场景，如果用户没有收到通知，不会造成业务影响，只要再次发送就可以了。

我们再来回顾一下RabbitMQ的工作模型。

在我们使用 RabbitMQ 收发消息的时候，有几个主要环节:

代表消息从生产者发送到Broker。生产者把消息发到Broker之后，怎么知道自己的消息有没有被Broker 成功接收?
代表消息从Exchange路由到Queue。Exchange是一个绑定列表，如果消息没有办法路由到正确的队列，会发生什么事情?应该怎么处理?
代表消息在 Queue 中存储。队列是一个独立运行的服务，有自己的数据库(Mnesia)，它是真正用来存储消息的。如果还没有消费者来消费，那么消息要一直存储在队列里面。如果队列出了问题，消息肯定会丢失。怎么保证消息在队列稳定地存储呢?
代表消费者订阅Queue并消费消息。队列的特性是什么?FIFO。队列里面的消息是一条一条的投递的，也就是说，只有上一条消息被消费者接收以后，才能把这一条消息从数据库删掉，继续投递下一条消息。那么问题来了，Broker怎么知道消费者已经接收了消息呢?

消息发送到RabbitMQ服务器

第一个环节是生产者发送消息到Broker。可能因为网络或者Broker的问题导致消息发送失败，生产者不能确定Broker有没有正确的接收。

在RabbitMQ里面提供了两种机制服务端确认机制，也就是在生产者发送消息给RabbitMQ的服务端的时候，服务端会通过某种方式返回一个应答，只要生产者收到了这个应答，就知道消息发送成功了。

第一种是Transaction(事务)模式，第二种 Confirm(确认)模式。

Transaction(事务)模式

我们通过一个channel.txSelect()的方法把信道设置成事务模式，然后就可以发布消息给RabbitMQ了，如果 channel.txCommit();的方法调用成功，就说明事务提交成功，则消息一定到达了RabbitMQ中。

如果在事务提交执行之前由于RabbitMQ异常崩溃或者其他原因抛出异常，这个时候我们便可以将其捕获，进而通过执行channel.txRollback()方法来实现事务回滚。

try {
    channel.txSelect();
    // 发送消息
    // String exchange, String routingKey, BasicProperties props, byte[] body
    channel.basicPublish("", QUEUE_NAME, null, (msg).getBytes());
    // int i =1/0;
    channel.txCommit();
    System.out.println("消息发送成功");
} catch (Exception e) {
    channel.txRollback();
    System.out.println("消息已经回滚");
}

在事务模式里面，只有收到了服务端的Commit-OK的指令，才能提交成功。所以可以解决生产者和服务端确认的问题。但是事务模式有一个缺点，它是阻塞的，一条消息没有发送完毕，不能发送下一条消息，它会榨干 RabbitMQ服务器的性能。所以不建议大家在生产环境使用。

Spring Boot 中的设置:

rabbitTemplate.setChannelTransacted(true);

那么有没有其他可以保证消息被 Broker 接收，但是又不大量消耗性能的方式呢?这个就是第二种模式，叫做确认(Confirm)模式。

Confirm(确认)模式

确认模式有三种，一种是普通确认模式。

在生产者这边通过调用 channel.confirmSelect()方法将信道设置为Confirm模式，然后发送消息。一旦消息被投递到所有匹配的队列之后，RabbitMQ就会发送一个确认 (Basic.Ack)给生产者，也就是调用 channel.waitForConfirms()返回true，这样生产者就知道消息被服务端接收了。

这种发送1条确认1条的方式效率还不是太高，所以我们还有一种批量确认的方式。批量确认，就是在开启 Confirm模式后，先发送一批消息。只要channel.waitForConfirmsOrDie();方法没有抛出异常，就代表消息都被服务端接收了。

批量确认的方式比单条确认的方式效率要高，但是也有两个问题，第一个就是批量的数量的确定。对于不同的业务，到底发送多少条消息确认一次?数量太少，效率提升不上去。数量多的话，又会带来另一个问题，比如我们发1000条消息才确认一次，如果前面999条消息都被服务端接收了，如果第1000条消息被拒绝了，那么前面所有的消息都要重发。

有没有一种方式，可以一边发送一边确认的呢?这个就是异步确认模式。

异步确认模式需要添加一个ConfirmListener，并且用一个SortedSet来维护没有被确认的消息。

Confirm 模式是在 Channel 上开启的，因为 RabbitTemplate 对 Channel 进行了封装，叫做 ConfimrCallback。

rabbitTemplate.setConfirmCallback(new RabbitTemplate.ConfirmCallback() {
    public void confirm(CorrelationData correlationData, boolean ack, String cause) {
        if (!ack) {
            System.out.println("发送消息失败：" + cause);
            throw new RuntimeException("发送异常：" + cause);
        }
    }
});

消息从交换机路由到队列

第二个环节就是消息从交换机路由到队列。在什么情况下，消息会无法路由到正确的队列?可能因为路由键错误，或者队列不存在。

我们有两种方式处理无法路由的消息，一种就是让服务端重发给生产者，一种是让交换机路由到另一个备份的交换机。

消息回发的方式:使用mandatory参数和ReturnListener(在 Spring AMQP 中是 ReturnCallback)。

RabbitTemplate rabbitTemplate = new RabbitTemplate(connectionFactory);
rabbitTemplate.setMandatory(true);
rabbitTemplate.setReturnCallback(new RabbitTemplate.ReturnCallback(){
    public void returnedMessage(Message message,
                                int replyCode,
                                String replyText,
                                String exchange,
                                String routingKey){
        System.out.println("回发的消息：");
        System.out.println("replyCode: "+replyCode);
        System.out.println("replyText: "+replyText);
        System.out.println("exchange: "+exchange);
        System.out.println("routingKey: "+routingKey);
    }
});

消息路由到备份交换机的方式:在创建交换机的时候，从属性中指定备份交换机。

// 在声明交换机的时候指定备份交换机
Map<String,Object> arguments = new HashMap<String,Object>();
arguments.put("alternate-exchange","ALTERNATE_EXCHANGE");
channel.exchangeDeclare("TEST_EXCHANGE","topic", false, false, false, arguments);

(注意区别，队列可以指定死信交换机;交换机可以指定备份交换机)

消息在队列存储

第三个环节是消息在队列存储，如果没有消费者的话，队列一直存在在数据库中。

如果RabbitMQ的服务或者硬件发生故障，比如系统宕机、重启、关闭等等，可能会导致内存中的消息丢失，所以我们要把消息本身和元数据(队列、交换机、绑定)都保存到磁盘。

解决方案:

1、队列持久化

@Bean("queue")
public Queue queue() {
    return new Queue("QUEUE", true, false, false, new HashMap<>());
}

2、交换机持久化

@Bean("exchange")
public DirectExchange exchange() {
    return new DirectExchange("EXCHANGE", true, false, new HashMap<>());
}

3、消息持久化

messageProperties.setDeliveryMode(MessageDeliveryMode.PERSISTENT);
messageProperties.setContentType("UTF-8");
Message message = new Message("持久化消息".getBytes(), messageProperties);

rabbitTemplate.send("EXCHANGE", "my.test", message);

4、集群

如果只有一个RabbitMQ的节点，即使交换机、队列、消息做了持久化，如果服务崩溃或者硬件发生故障，RabbitMQ的服务一样是不可用的，所以为了提高MQ服务的可用性，保障消息的传输，我们需要有多个RabbitMQ的节点，在下一节会详细讲到。

消息投递到消费者

如果消费者收到消息后没来得及处理即发生异常，或者处理过程中发生异常，会导致④失败。服务端应该以某种方式得知消费者对消息的接收情况，并决定是否重新投递这条消息给其他消费者。

RabbitMQ提供了消费者的消息确认机制(message acknowledgement)，消费者可以自动或者手动地发送ACK给服务端。

没有收到ACK的消息，消费者断开连接后，RabbitMQ会把这条消息发送给其他消费者。如果没有其他消费者，消费者重启后会重新消费这条消息，重复执行业务逻辑。

消费者在订阅队列时，可以指定autoAck参数，当autoAck等于false时，RabbitMQ会等待消费者显式地回复确认信号后才从队列中移去消息。

如何设置手动 ACK?

SimpleRabbitListenerContainer 或者 SimpleRabbitListenerContainerFactory

factory.setAcknowledgeMode(AcknowledgeMode.MANUAL);

application.properties

spring.rabbitmq.listener.direct.acknowledge-mode=manual 
spring.rabbitmq.listener.simple.acknowledge-mode=manual

注意这三个值的区别:

NONE:自动 ACK
MANUAL: 手动 ACK
AUTO:如果方法未抛出异常，则发送 ack。

当抛出 AmqpRejectAndDontRequeueException 异常的时候，则消息会被拒绝，且不重新入队。当抛出 ImmediateAcknowledgeAmqpException异常，则消费者会发送ACK。其他的异常，则消息会被拒绝，且 requeue = true会重新入队。

在Spring Boot中，消费者又怎么调用ACK，或者说怎么获得Channel参数呢? 引入 com.rabbitmq.client.Channel。

public class SecondConsumer {
    @RabbitHandler
    public void process(String msgContent,Channel channel, Message message) throws IOException {
        System.out.println("Second Queue received msg : " + msgContent );
        channel.basicAck(message.getMessageProperties().getDeliveryTag(), false);
    }
}

如果消息无法处理或者消费失败，也有两种拒绝的方式，Basic.reject()拒绝单条， Basic.Nack()批量拒绝。如果requeue参数设置为 true，可以把这条消息重新存入队列，以便发给下一个消费者(当然，只有一个消费者的时候，这种方式可能会出现无限循环重复消费的情况。可以投递到新的队列中，或者只打印异常日志)。