RabbitMQ消息可靠性(一)-- 生产者消息确认

前言

在项目中,引入了RabbitMQ这一中间件,必然也需要在业务中增加对数据安全性的一层考虑,来保证RabbitMQ消息的可靠性,否则一个个消息丢失可能导致整个业务的数据出现不一致等问题,对系统带来巨大的影响,消息的可靠性可以主要在三个方面去考虑:生产者消息确认,消费者消息确认,消息持久化,这篇文件说明生产者消息确认的。


一、消息确认流程图

RabbitMQ消息可靠性(一)-- 生产者消息确认_第1张图片

由图可知,消息确认是分为生产者确认和消费者确认的,生产者和MQ之间的消息确认机制为生产者消息确认,MQ和消费者之间的消息确认机制为消费者消息确认

消息丢失的情景有三种情况:

  1. 发送消息过程中出现网络问题:生产者以为发送成功,但MQ没有收到;(需要生产者消息确认)
  2. 接收到消息后由于MQ服务器宕机或重启等原因(消息默认存在内存中)导致消息丢失;(需要消息持久化)
  3. 消费者接收到消息后处理消息出错,没有完成消息的处理,但是自动返回ack(这时候需要开启手动确认模式,消费者消息确认)

二、生产者消息确认

RabbitMQ提供了publisher confirm机制来避免消息投递到MQ过程中丢失。这种机制下每个message都必须要有一个独一无二的ID,来区分开不同的消息,避免ack(消息确认参数)冲突。每当消息发送到MQ成功后,MQ都会返回一个结果给生产者,以保证生产者消息确认。在生产者消息确认时,又有两种返回结果方式(通常两个都要实现)来确保消息投递可靠性,分别为publisher-confirm和publisher-return,以下作出说明。

1、publisher-confirm(发送者确认)

消息成功投递到交换机,返回ack

消息未投递到交换机,返回nack

2、publisher-return(发送者回执)

消息投递到交换机了,但是没有路由到队列。返回ACK,及路由失败原因。


三、代码实现

1、配置文件

spring:
  rabbitmq:
    host: localhost
    port: 5672
    username: guest
    password: guest
    #确认消息已发送到交换机(Exchange)
    publisher-confirm-type: correlated
    #确认消息已发送到队列(Queue)
    publisher-returns: true

publish-confirm-type有三个值,

  1. none:禁用发布确认模式,是默认值
  2. simple:同步等待confirm结果,直到超时
  3. correlated:异步回调,定义ConfirmCallback,MQ返回结果时会回调这个ConfirmCallback

publisher-returns:开启消息失败回调,回调函数ReturnCallback

2、配置ConfirmCallback函数和ReturnCallback函数

/**
 * 生产者消息回调配置类
 */
@Configuration
@Slf4j
public class ProviderCallBackConfig {

    @Resource
    private CachingConnectionFactory cachingConnectionFactory;

    @Bean
    public RabbitTemplate rabbitTemplate() {
        RabbitTemplate rabbitTemplate = new RabbitTemplate(cachingConnectionFactory);
        // 当mandatory设置为true时,若exchange根据自身类型和消息routingKey无法找到一个合适的queue存储消息,
        // 那么broker会调用basic.return方法将消息返还给生产者。当mandatory设置为false时,出现上述情况broker会直接将消息丢弃。
        rabbitTemplate.setMandatory(true);

        /**
         * TODO RabbitMQ发送者消息确认回调,解决消息可靠性问题
         * 消息确认回调,确认消息是否到达broker
         * data:消息唯一标识
         * ack:确认结果
         * cause:失败原因
         */
        rabbitTemplate.setConfirmCallback((data, ack, cause) -> {
            log.info("消息唯一标识: {}", data);
            log.info("确认状态: {}", ack);
            log.info("造成原因: {}", cause);
            if (ack) {
                //消息发送成功后,更新数据库消息状态等逻辑
                log.info("消息发送成功");
            } else {
                //信息发送失败,打印日志后,可以根据业务选择是否重发消息
                log.error("消息发送失败");
            }
        });

        /**
         * TODO RabbitMQ发送者消息失败回调,解决消息可靠性问题
         * 消息失败回调,比如router不到queue时回调
         */
        rabbitTemplate.setReturnsCallback((res) -> {
            //若发送失败,打印错误信息,然后可以根据业务选择重发消息
            log.error("消息发送queue时失败");
            log.error("ReturnCallback:     "+"消息:"+res.getMessage());
            log.error("ReturnCallback:     "+"回应码:"+res.getReplyCode());
            log.error("ReturnCallback:     "+"回应信息:"+res.getReplyText());
            log.error("ReturnCallback:     "+"交换机:"+res.getExchange());
            log.error("ReturnCallback:     "+"路由键:"+res.getRoutingKey());
        });
        return rabbitTemplate;
    }

}

到这里,生产者推送消息的消息确认调用回调函数已经完毕。
可以看到上面写了两个回调函数,一个叫 ConfirmCallback ,一个叫 RetrunCallback;
那么以上这两种回调函数都是在什么情况会触发呢?

先从总体的情况分析,推送消息存在3种情况:

①消息推送到server,但是在server里找不到交换机
②消息推送到server,找到交换机了,但是没找到队列
③消息推送成功

①消息推送到server,但是在server里找不到交换机
写个测试接口,把消息推送到名为‘non-existent-exchange’的交换机上(这个交换机是没有创建没有配置的):

@GetMapping("/testProviderMessageBack")
    @ApiOperation(value = "测试生产者消息回调")
    @ApiOperationSupport(order = 5)
    public String testProviderMessageBack() {
        CorrelationData data = new CorrelationData();
        data.setId("111");
        rabbitTemplate.convertAndSend("non-existent-exchange", "TestDirectRouting", "测试生产者消息回调",data);
        return "ok";
    }

调用接口,查看项目的控制台输出情况(原因里面有说,没有找到交换机'non-existent-exchange'):

结论: ①这种情况触发的是 ConfirmCallback 回调函数

消息唯一标识: CorrelationData [id=111]
确认状态: false
造成原因: channel error; protocol method: #method(reply-code=404, reply-text=NOT_FOUND - no exchange 'non-existent-exchange' in vhost '/', class-id=60, method-id=40)
消息发送失败

②消息推送到server,找到交换机了,但是没找到队列  
这种情况就是需要新增一个交换机,但是不给这个交换机绑定队列,我来简单地在DirectRabitConfig里面新增一个直连交换机,名叫‘lonelyDirectExchange’,但没给它做任何绑定配置操作:

    @Bean
    DirectExchange lonelyDirectExchange() {
        return new DirectExchange("lonelyDirectExchange");
    }

然后写个测试接口,把消息推送到名为‘lonelyDirectExchange’的交换机上(这个交换机是没有任何队列配置的):

@GetMapping("/testProviderMessageBack2")
    @ApiOperation(value = "测试生产者消息回调2")
    @ApiOperationSupport(order = 6)
    public String testProviderMessageBack2() {
        CorrelationData data = new CorrelationData();
        data.setId("222");
        rabbitTemplate.convertAndSend("lonelyDirectExchange", "TestLonelyDirectRouting", "测试生产者消息回调2",data);
        return "ok";
    }

消息唯一标识: CorrelationData [id=222]
确认状态: true
造成原因: null
消息发送成功 

消息发送queue时失败
ReturnCallback:     消息:(Body:'测试生产者消息回调2' MessageProperties [headers={spring_returned_message_correlation=222}, contentType=text/plain, contentEncoding=UTF-8, contentLength=0, receivedDeliveryMode=PERSISTENT, priority=0, deliveryTag=0])
ReturnCallback:     回应码:312
ReturnCallback:     回应信息:NO_ROUTE
ReturnCallback:     交换机:lonelyDirectExchange
ReturnCallback:     路由键:TestLonelyDirectRouting

这种情况下,两个函数都被调用了,消息是推送成功到服务器了的,所以ConfirmCallback对消息确认情况是true;
而在RetrunCallback回调函数的打印参数里面可以看到,消息是推送到了交换机成功了,但是在路由分发给队列的时候,找不到队列,所以报了错误 NO_ROUTE 。
结论:②这种情况触发的是 ConfirmCallback和RetrunCallback两个回调函数。

③消息推送成功
那么测试下,按照正常调用之前消息推送的接口就行,就调用下 /sendDirectMessage接口,可以看到控制台输出:

结论:这种情况触发的是 ConfirmCallback 回调函数。

你可能感兴趣的:(#,RabbitMQ,rabbitmq,分布式)