【分布式&微服务】RabbitMQ实践

一、MQ基础

1.什么是MQ

为什么会用到MQ呢？
答：1>在传统的系统中，当遇到相对复杂的业务中，一次用户请求可能会同步调用N个系统的接口，则需要等待所有的接口都返回了，才能真正的获取执行结果。这种同步调用接口的方式总耗时比较长，非常影响用户的体验，特别是在网络不稳定的情况下，非常容易出现接口超时问题。

2>在进行系统设计的时候，一般会将复杂的业务系统拆分成为多个子系统。例如用户下单，请求会先通过订单系统，然后分别调用：支付系统、库存系统和物流系统等系统。系统之间耦合性太高，如果调用的任何一个子系统出现异常，整个请求都会异常，对系统的稳定性非常不利。

3>秒杀活动，对系统的稳定性要求很高。如果用户比较少，则不会影响系统的稳定性。但如果用户突增，一时间所有的请求都到数据库，可能会导致数据库无法承受这么大的压力，响应变慢或者直接挂掉。

那如何解决上述三个问题呢？
答：mq
解决问题一：同步接口调用导致响应时间长的问题，使用mq之后，将同步调用改成异步，能够显著减少系统响应时间。提升用户体验和系统吞吐量（单位时间内处理请求的数目）

解决问题二：使用mq之后，我们只需要依赖于mq，避免了各个子系统间的强依赖问题。
订单系统作为消息生产者，只需要保证自己没问题就可以了，不会受到库存系统等业务子系统的异常影响，并且各个消费者业务子系统之间，也互不影响。这样就把之前复杂的业务子系统的依赖关系，转换为只依赖于mq的简单依赖，从而显著的降低了系统间的耦合度，提升容错性和可维护性。

解决问题三：业务系统接收到用户请求之后，将请求直接发送到mq，然后消费者从mq中消费消息。如果出现请求峰值的情况，由于消费者的消费能力有限，通过限流操作按照自己的节奏来消费消息，多余的消息会保留在mq的队列中，不会对系统的稳定性造成影响。

优势总结：
1>异步提速：提升用户体验和系统吞吐量
2>应用解耦：提高系统容错性和可维护性
3>削峰填谷：提高系统稳定性

劣势：
1>系统可用性降低：随着外部依赖引入的增多，系统稳定性将会越差。如果 MQ 宕机，就会对业务造成影响。（如何保证MQ的高可用？）
2>系统复杂度提高：MQ 的引入将会增加系统的复杂度，以前系统间是同步的远程调用，现在是通过 MQ 进行异步调用。（如何保证消息不被丢失等情况？）

2.什么是RabbitMQ

RabbitMQ是实现了高级消息队列协议（AMQP）的开源分布式消息中间件，服务端是用Erlang语言编写的。RabbitMQ 凭借其高可靠、易扩展、高可用及丰富的功能特性，不管是互联网行业还是传统行业都在大量地使用。
RabbitMQ 基础架构如下图：

RabbitMQ 中的相关概念：
1>Broker：接收和分发消息的应用，RabbitMQ Server就是 Message Broker
2>Virtual host：出于多租户和安全因素设计的，把 AMQP 的基本组件划分到一个虚拟的分组中，类似于网络中的 namespace 概念。当多个不同的用户使用同一个 RabbitMQ server 提供的服务时，可以划分出多个vhost，每个用户在自己的 vhost 创建 exchange／queue 等
3>Connection：publisher／consumer 和 broker 之间的 TCP 连接
4>Channel：如果每一次访问 RabbitMQ 都建立一个 Connection，在消息量大的时候建立 TCP Connection的开销将是巨大的，效率也较低。Channel 是在 connection 内部建立的逻辑连接，如果应用程序支持多线程，通常每个thread创建单独的 channel 进行通讯，AMQP method 包含了channel id 帮助客户端和message broker 识别 channel，所以 channel 之间是完全隔离的。Channel 作为轻量级的 Connection 极大减少了操作系统建立 TCP connection 的开销
5>Exchange：message 到达 broker 的第一站，根据分发规则，匹配查询表中的 routing key，分发消息到queue 中去。常用的类型有：direct (point-to-point), topic (publish-subscribe) and fanout (multicast)
6>Queue：消息最终被送到这里等待 consumer 取走
7>Binding：exchange 和 queue 之间的虚拟连接，binding 中可以包含 routing key。Binding 信息被保存到 exchange 中的查询表中，用于 message 的分发依据

RabbitMQ 提供了 6 种工作模式：简单模式、work queues、Publish/Subscribe 发布与订阅模式、Routing 路由模式、Topics 主题模式、RPC 远程调用模式（远程调用，使用的比较少）。
官网对应模式介绍：https://www.rabbitmq.com/getstarted.html

工作模式总结：
1>简单模式：一个生产者、一个消费者，不需要设置交换机（使用默认的交换机）；
2>工作队列模式 Work Queue： 一个生产者、多个消费者（竞争关系），不需要设置交换机（使用默认的交换机）。
3>发布订阅模式 Publish/subscribe：需要设置类型为 fanout 的交换机，并且交换机和队列进行绑定，当发送消息到交换机后，交换机会将消息发送到绑定的队列。
4>路由模式 Routing：需要设置类型为 direct 的交换机，交换机和队列进行绑定，并且指定 routing key，当发送消息到交换机后，交换机会根据 routing key 将消息发送到对应的队列。
5>通配符模式 Topic：需要设置类型为 topic 的交换机，交换机和队列进行绑定，并且指定通配符方式的 routing key，当发送消息到交换机后，交换机会根据 routing key 将消息发送到对应的队列。
Topic 类型与 Direct 相比，都是可以根据 RoutingKey 把消息路由到不同的队列。但是 Topic 类型的队列在绑定 Routing key 的时候使用通配符（通配符规则：# 匹配一个或多个词，* 匹配不多不少恰好1个词，例如：key.# 能够匹配 key.msg.a 或者 key.msg，key.* 只能匹配 key.msg）。

二、实践

0.基础配置

1> pom.xml

<dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-amqp</artifactId>
    </dependency>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
      <groupId>io.springfox</groupId>
      <artifactId>springfox-swagger2</artifactId>
      <version>2.6.0</version>
    </dependency>
    <dependency>
      <groupId>io.springfox</groupId>
      <artifactId>springfox-swagger-ui</artifactId>
      <version>2.6.0</version>
    </dependency>

    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.12</version>
      <scope>test</scope>
    </dependency>

    <dependency>
      <groupId>org.aspectj</groupId>
      <artifactId>aspectjweaver</artifactId>
      <version>1.9.6</version>
    </dependency>
    <dependency>
      <groupId>org.projectlombok</groupId>
      <artifactId>lombok</artifactId>
    </dependency>
      <dependency>
          <groupId>org.springframework</groupId>
          <artifactId>spring-messaging</artifactId>
      </dependency>
    <dependency>
      <groupId>com.alibaba</groupId>
      <artifactId>fastjson</artifactId>
      <version>1.2.73</version>
    </dependency>
      <dependency>
          <groupId>org.springframework</groupId>
          <artifactId>spring-test</artifactId>
          <scope>test</scope>
      </dependency>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-test</artifactId>
      <scope>test</scope>
    </dependency>

2>application.properties

server.port=8888
#基本配置
spring.rabbitmq.port=5672
spring.rabbitmq.username=root
spring.rabbitmq.password=root
spring.rabbitmq.addresses=localhost
spring.rabbitmq.virtual-host=/
#消息的可靠性投递
#1.消息发送方消息确认参数
#springboot版本为2.1.4的时候才有这个属性
#spring.rabbitmq.publisher-confirms=true
spring.rabbitmq.publisher-returns=true
spring.rabbitmq.publisher-confirm-type=correlated
#2.消费者消息确认参数
spring.rabbitmq.listener.simple.acknowledge-mode=manual
#并行消费者数量
spring.rabbitmq.listener.simple.concurrency=3
#最大并行消费者数量
spring.rabbitmq.listener.simple.max-concurrency=5
#消费端限流
spring.rabbitmq.listener.simple.prefetch=100

1.消息可靠性投递

1-1 应用场景

在使用RabbitMQ的时候，为了防止出现消息丢失或者投递失败场景，RabbitMQ提供了两种方式用来控制消息的投递可靠性模式：
1>confirm确认模式
2>return退回模式

rabbitmq 整个消息投递的路径为：producer—>exchange—>queue—>consumer
消息从 producer 到 exchange 则会返回一个 confirmCallback 。
消息从 exchange–>queue 投递失败则会返回一个 returnCallback 。

1-2 流程图

1-3 代码实现

1-3-1 RabbitMq配置

#springboot版本为2.1.4的时候才有这个属性
#spring.rabbitmq.publisher-confirms=true
spring.rabbitmq.publisher-returns=true
spring.rabbitmq.publisher-confirm-type=correlated

import org.springframework.amqp.core.*;
import org.springframework.amqp.rabbit.connection.CorrelationData;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.amqp.support.converter.Jackson2JsonMessageConverter;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

import javax.annotation.PostConstruct;
import javax.annotation.Resource;
import java.util.HashMap;
import java.util.Map;

@Configuration
public class RabbitMqConfig {

    @Resource
    private RabbitTemplate rabbitTemplate;

    /**
     * 生产方的消息到达确认机制
     * ConfirmCallback 不管消息有没有正确到达exchange,都会被触发
     * --如果到达exchange,则confirm回调，ack=true
     * --如果未道道exchange,则confirm回调，ack=false
     * ReturnCallback 消息未正确到达队列时触发
     * --如果到达queue，则不会触发回调
     * --如果未到达queue，则触发回调
     *
     * @return
     */
    @PostConstruct
    public RabbitTemplate initRabbitTemplate() {

        rabbitTemplate.setMessageConverter(new Jackson2JsonMessageConverter());
        **rabbitTemplate.setMandatory(Boolean.TRUE); // 是否允许执行returnCallback方法**

        // 不论消息是否正确到达交换机，都会触发回调
        rabbitTemplate.setConfirmCallback(new RabbitTemplate.ConfirmCallback() {
            /**
             * @param correlationData 消息
             * @param ack 是否到达交换机的确认结果 true到达交换机 false未到达交换机
             * @param cause 未到达交换机的原因
             */
            @Override
            public void confirm(CorrelationData correlationData, boolean ack, String cause) {
                // CorrelationData springboot提供的参数，不是必须的。失败后返回的一个信息，一般就可以将失败的订单ID返回
                // 我们可以在发送消息的时候附带一个CorrelationData参数 这个对象可以设置一个id，可以是你的业务id 方便进行对应的操作
//                                CorrelationData correlationData = new CorrelationData(UUID.randomUUID().toString());
//                                rabbitTemplate.convertAndSend("directExchange", "direct.key123123", "hello",correlationData);
                //System.out.println("confirm方法被执行了...."+correlationData.getId());

                //ack 为  true表示 消息已经到达交换机
                if (ack) {
                    //接收成功
                    System.out.println("接收成功消息" + cause);
                } else {
                    //接收失败
                    System.out.println("接收失败消息" + cause);
                    //做一些处理，让消息再次发送。
                }

            }
        });

        **// 只有消息未正确到达队列时，才会回调**
        rabbitTemplate.setReturnCallback(new RabbitTemplate.ReturnCallback() {
            /**
             * @param message 消息
             * @param replyCode 失败码
             * @param replyText 失败原因
             * @param exchange 使用的交换机
             * @param routingKey 使用的路由键
             */
            @Override
            public void returnedMessage(Message message, int replyCode, String replyText, String exchange, String routingKey) {
                System.out.println("return 执行了....");

                System.out.println("message:" + message);
                System.out.println("replyCode:" + replyCode);
                System.out.println("replyText:" + replyText);
                System.out.println("exchange:" + exchange);
                System.out.println("routingKey:" + routingKey);
            }
        });
        return rabbitTemplate;
    }

    //声明队列
    @Bean
    public Queue topicMqQ1() {
        return new Queue("topic_mq_q1");
    }

   //声明exchange
    @Bean
    public TopicExchange setTopicMqExchange() {
        return new TopicExchange("topicMqExchange");
    }

    //声明binding，需要声明一个routingKey
    @Bean
    public Binding bindTopicMqQ1() {
        return BindingBuilder.bind(topicMqQ1()).to(setTopicMqExchange()).with("topic_mq_q1_msg");
    }
}

1-3-2 消费者

    @RabbitListener(queues = "topic_mq_q1")
	public void topicReceiveMqq1Msg1(Channel channel, @Payload String message, @Header(AmqpHeaders.DELIVERY_TAG) long deliveryTag) throws Exception {
		try {
			// 业务代码
			System.out.println("Topic模式 topic_mq_q1 received  message1 : " +message);
		}  finally {
			channel.basicAck(deliveryTag,false);
		}
	}

1-3-3 测试类

    @Test
    public void test() {
        String str1 = "I am the queen of computers";
        rabbitTemplate.convertAndSend("topicMqExchange","topic_mq_q1_msg",str1);
    }

运行结果为：

1-4 小结

消息的可靠性投递（消息发送方）：
1> producer -> exchange
注：在springboot2.2.0.RELEASE 版本之前使用的是spring.rabbitmq.publisher-confirms来配置消息发送到交换器之后是否触发回调方法，但是在2.2.0及之后该属性不再使用，使用spring.rabbitmq.publisher-confirm-type属性配置代替。
1-1>设置ConnectionFactory的publisher-confirms=“true” 或 spring.rabbitmq.publisher-confirm-type=correlated 开启确认模式；
1-2>使用rabbitTemplate.setConfirmCallback设置回调函数。当消息发送到exchange后回调confirm方法。在方法中判断ack，如果为true，则发送成功，如果为false，则发送失败，需要处理。

2> exchange -> queue
2-1>设置ConnectionFactory的publisher-returns=“true” 开启 退回模式；
2-2>设置rabbitTemplate.setMandatory(true)；
2-3>使用rabbitTemplate.setReturnCallback设置退回函数，当消息从exchange路由到queue失败后，如果设置了rabbitTemplate.setMandatory(true)参数，则会将消息退回给producer。并执行回调函数returnedMessage。

2.Consumer ACK

2-1 应用场景

ack指Acknowledge，表示消费端收到消息后的确认方式。
有三种确认方式：
自动确认：acknowledge=“none”
手动确认：acknowledge=“manual”
根据异常情况确认：acknowledge=“auto”

其中自动确认是指，当消息一旦被Consumer接收到，则自动进行确认收到，并将相应消息从 RabbitMQ 的消息缓存中移除。但是在实际业务处理中，很可能出现消息虽然接收到了但是业务处理出现了异常，但是此时该消息已经被自动确认了，就会出现消息丢失的情况。如果设置了手动确认方式，则需要在业务处理成功后，调用channel.basicAck()，手动签收，如果出现异常，则调用channel.basicNack()方法，让其自动重新发送消息。

// 手动确认
channel.basicAck(deliveryTag,false);
// 当channel.basicNack 第三个参数设为true时，消息签收失败会继续进入消息队列等待消费
// 当channel.basicNack 第三个参数设为false时，消息签收失败,此时消息进入死信队列，完成消费
channel.basicNack(deliveryTag,false,false);

2-2 流程图

2-3 代码实现

2-3-1 RabbitMq配置

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

import org.springframework.amqp.core.*;
import org.springframework.amqp.rabbit.connection.CorrelationData;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.amqp.support.converter.Jackson2JsonMessageConverter;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

import javax.annotation.PostConstruct;
import javax.annotation.Resource;
import java.util.HashMap;
import java.util.Map;

@Configuration
public class RabbitMqConfig {

    //声明队列
    @Bean
    public Queue topicMqQ1() {
        return new Queue("topic_mq_q1");
    }

   //声明exchange
    @Bean
    public TopicExchange setTopicMqExchange() {
        return new TopicExchange("topicMqExchange");
    }

    //声明binding，需要声明一个routingKey
    @Bean
    public Binding bindTopicMqQ1() {
        return BindingBuilder.bind(topicMqQ1()).to(setTopicMqExchange()).with("topic_mq_q1_msg");
    }
}

2-3-2 消费者

@RabbitListener(queues="topic_mq_q1")
	public void topicReceiveMqq1Msg1(Channel channel, @Payload String message, @Header(AmqpHeaders.DELIVERY_TAG) long deliveryTag) throws Exception {
		System.out.println("Topic模式 topic_mq_q1 received  message : " +message);
		try {
			// 业务代码
		} finally {
			channel.basicAck(deliveryTag,false);
		}
	}

2-3-3 测试类

    @Test
    public void test() {
        String str1 = "I am the queen of computers";
        rabbitTemplate.convertAndSend("topicMqExchange","topic_mq_q1_msg",str1);
    }

运行结果为：

2-4 小结

消息的可靠性投递（消费端）：
1>在rabbit:listener-container标签中设置acknowledge属性（spring.rabbitmq.listener.simple.acknowledge-mode），设置ack方式 none（自动确认）、manual（手动确认）；
2>如果在消费端没有出现异常，则调用channel.basicAck(deliveryTag,false);方法确认签收消息；如果出现异常，则在catch中调用 basicNack或 basicReject，拒绝消息，让MQ重新发送消息。

3.消费端限流

3-1 应用场景

当RabbitMQ服务器积压了有上万条未处理的消息，我们随便打开一个消费者客户端，会出现这样情况: 巨量的消息瞬间全部推送过来，但是我们单个客户端无法同时处理这么多数据。当数据量特别大的时候，我们对消息发送端限流肯定是不科学的，因为有时候并发量就是特别大，有时候并发量又特别少，我们无法约束发送端，这是用户的行为。所以我们应该对消费端进行限流，用于保持消费端的稳定，当消息数量激增的时候很有可能造成资源耗尽，以及影响服务的性能，导致系统的卡顿甚至直接崩溃。

3-2 流程图

3-3 代码实现

3-3-1 RabbitMq配置

spring.rabbitmq.listener.simple.concurrency=3
spring.rabbitmq.listener.simple.prefetch=100

import org.springframework.amqp.core.*;
import org.springframework.amqp.rabbit.connection.CorrelationData;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.amqp.support.converter.Jackson2JsonMessageConverter;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

import javax.annotation.PostConstruct;
import javax.annotation.Resource;
import java.util.HashMap;
import java.util.Map;

@Configuration
public class RabbitMqConfig {

    //声明队列
    @Bean
    public Queue topicMqQ1() {
        return new Queue("topic_mq_q1");
    }

   //声明exchange
    @Bean
    public TopicExchange setTopicMqExchange() {
        return new TopicExchange("topicMqExchange");
    }

    //声明binding，需要声明一个routingKey
    @Bean
    public Binding bindTopicMqQ1() {
        return BindingBuilder.bind(topicMqQ1()).to(setTopicMqExchange()).with("topic_mq_q1_msg");
    }
}

3-3-2 消费者

@RabbitListener(queues="topic_mq_q1")
	public void topicReceiveMqq1Msg(Channel channel, @Payload String message, @Header(AmqpHeaders.DELIVERY_TAG) long deliveryTag) throws IOException {
		System.out.println(deliveryTag + "-" +message);
		channel.basicAck(deliveryTag,false);
	}

3-3-3 测试类

@Test
    public  void testQos() throws InterruptedException {
       for (int i = 0; i < 10; i++) {
           rabbitTemplate.convertAndSend("topicMqExchange","topic_mq_q1_msg","test" + i);
       }
}

运行结果如下：

@Test
    public  void testQos() throws InterruptedException {
       for (int i = 0; i < 500; i++) {
           rabbitTemplate.convertAndSend("topicMqExchange","topic_mq_q1_msg","test" + i);
       }
}

运行结果如下：

3-4 源码解析

项目中大部分使用@RabbitmqListener注解的方式处理业务代码中MQ的消费，这个注解用于监听指定的队列，如果containerFactory未指定，默认使用SimpleRabbitListenerContainerFactory实例对象创建一个消息监听容器(SimpleMessageListenerContainer)。默认情况下，rabbitmq的消费者为单线程串行消费，这也是队列的特性。从SimpleMessageListenerContainer的源码可以看到设置并发消费属性concurrentConsumers=1，从字面意义也可以分析出该字段是设置并发消费者的数量,默认为一个监听器设置一个消费者。

private volatile int concurrentConsumers = 1;

rabbitmq容器启动的时候根据设置的concurrentConsumers创建N个BlockingQueueConsumer(N个消费者队列)

protected int initializeConsumers() {
        int count = 0;
        synchronized(this.consumersMonitor) {
            if (this.consumers == null) {
                this.cancellationLock.reset();
                this.consumers = new HashSet(this.concurrentConsumers);

                for(int i = 0; i < this.concurrentConsumers; ++i) {
                    BlockingQueueConsumer consumer = this.createBlockingQueueConsumer();
                    this.consumers.add(consumer);
                    ++count;
                }
            }

            return count;
        }
    }

另外它继承的抽象类AbstractMessageListenerContainer的构造函数,代码中prefetchCount为设置并发消费的另一个关键属性,prefetchCount指一个消费者每次一次性从broker里面取出的待消费的消息个数，默认值prefetchCount=250。

public AbstractMessageListenerContainer() {
        this.proxy = this.delegate;
        this.shutdownTimeout = 5000L;
        this.transactionAttribute = new DefaultTransactionAttribute();
        this.taskExecutor = new SimpleAsyncTaskExecutor();
        this.recoveryBackOff = new FixedBackOff(5000L, 9223372036854775807L);
        this.messagePropertiesConverter = new DefaultMessagePropertiesConverter();
        this.missingQueuesFatal = true;
        this.possibleAuthenticationFailureFatal = true;
        this.autoDeclare = true;
        this.mismatchedQueuesFatal = false;
        this.failedDeclarationRetryInterval = 5000L;
        this.autoStartup = true;
        this.phase = 2147483647;
        this.active = false;
        this.running = false;
        this.lifecycleMonitor = new Object();
        this.queueNames = new CopyOnWriteArrayList();
        this.errorHandler = new ConditionalRejectingErrorHandler();
        this.exposeListenerChannel = true;
        this.acknowledgeMode = AcknowledgeMode.AUTO;
        this.deBatchingEnabled = true;
        this.adviceChain = new Advice[0];
        this.defaultRequeueRejected = true;
        **this.prefetchCount = 250;**
        this.lastReceive = System.currentTimeMillis();
        this.statefulRetryFatalWithNullMessageId = true;
        this.exclusiveConsumerExceptionLogger = new AbstractMessageListenerContainer.DefaultExclusiveConsumerLogger();
        this.lookupKeyQualifier = "";
        this.forceCloseChannel = true;
    }

上面我们已经根据concurrentConsumer的值设置了N个消费者队列，从下面代码中最后一行可以看出消费者队列中维护了一个阻塞队列，其中阻塞队列的大小就由prefetchCount决定。

public BlockingQueueConsumer(ConnectionFactory connectionFactory, MessagePropertiesConverter messagePropertiesConverter, ActiveObjectCounter<BlockingQueueConsumer> activeObjectCounter, AcknowledgeMode acknowledgeMode, boolean transactional, int prefetchCount, boolean defaultRequeueRejected, Map<String, Object> consumerArgs, boolean noLocal, boolean exclusive, String... queues) {
        this.cancelled = new AtomicBoolean(false);
        this.consumerArgs = new HashMap();
        this.deliveryTags = new LinkedHashSet();
        this.consumerTags = new ConcurrentHashMap();
        this.missingQueues = Collections.synchronizedSet(new HashSet());
        this.retryDeclarationInterval = 60000L;
        this.failedDeclarationRetryInterval = 5000L;
        this.declarationRetries = 3;
        this.connectionFactory = connectionFactory;
        this.messagePropertiesConverter = messagePropertiesConverter;
        this.activeObjectCounter = activeObjectCounter;
        this.acknowledgeMode = acknowledgeMode;
        this.transactional = transactional;
        this.prefetchCount = prefetchCount;
        this.defaultRequeueRejected = defaultRequeueRejected;
        if (consumerArgs != null && consumerArgs.size() > 0) {
            this.consumerArgs.putAll(consumerArgs);
        }

        this.noLocal = noLocal;
        this.exclusive = exclusive;
        this.queues = (String[])Arrays.copyOf(queues, queues.length);
        this.queue = new LinkedBlockingQueue(prefetchCount);
    }

根据队列的特性可知，如果阻塞队列中一个消息阻塞了，那么所有消息将会被阻塞，如果使用默认设置,concurrentConsumer=1，prefetchCount=250，那么当消费者队列中有一个消息由于某种原因阻塞了，那么该消息的后续消息同样不能被消费。为了防止这种情况的发生，我们可以增大concurrentConsumer的设置，使多个消费者可以并发消费。而prefetchCount该如何设置呢?假设conrrentConsumer=2，prefetchCount采用默认值，rabbitmq容器会初始化两个并发的消费者，每个消费者的阻塞队列大小为250，rabbitmq的机制是将消息投递给consumer1，先为consumer1投递满250个message，再往consumer2投递250个message，如果consumer1的message一直小于250个，consumer2一直处于空闲状态，那么并发消费退化为单消费者。
关于concurrentConsumer的设置有两种方式，一种是单个固定的值，如concurrentConsumer=4，另一种是concurrentConsumer=1-4。

public void setConcurrency(String concurrency) {
        try {
            int separatorIndex = concurrency.indexOf(45);
            if (separatorIndex != -1) {
                this.setConcurrentConsumers(Integer.parseInt(concurrency.substring(0, separatorIndex)));
                this.setMaxConcurrentConsumers(Integer.parseInt(concurrency.substring(separatorIndex + 1, concurrency.length())));
            } else {
                this.setConcurrentConsumers(Integer.parseInt(concurrency));
            }

        } catch (NumberFormatException var3) {
            throw new IllegalArgumentException("Invalid concurrency value [" + concurrency + "]: only single fixed integer (e.g. \"5\") and minimum-maximum combo (e.g. \"3-5\") supported.");
        }
    }

concurrency即为我们设置的参数，45为’-’的ascii码，容器首先设置了一个并发消费者，然后设置了最大并发消费者。maxConcurrentConsumer用于处理在极端情况下，可以实例化的最大的消费者数量。可以对比理解成线程池的核心线程数与最大线程数，在每次消费之初都会判断maxConcurrentConsumers是否为空，如果非空会判断是否对消费者进行弹性扩容，其中consecutiveMessages与consecutiveIdles变量控制是需要新增/减少消费者的标志位，对应的参考值分别为consecutiveActiveTrigger和consecutiveIdleTrigger，两个变量的默认值为10。

if (consecutiveMessages++ > SimpleMessageListenerContainer.this.consecutiveActiveTrigger) {
	SimpleMessageListenerContainer.this.considerAddingAConsumer();
    consecutiveMessages = 0;
}

if (consecutiveIdles++ > SimpleMessageListenerContainer.this.consecutiveIdleTrigger) {
    SimpleMessageListenerContainer.this.considerStoppingAConsumer(this.consumer);
    consecutiveIdles = 0;
}

当单个消费者连续接受的消息数量达到10个的时候，开始调用considerAddingAConsumer,判断时间是否满足要求对并发消费者进行扩容，反之就是减少消费者数量。

private void considerAddingAConsumer() {
        synchronized(this.consumersMonitor) {
            if (this.consumers != null && this.maxConcurrentConsumers != null && this.consumers.size() < this.maxConcurrentConsumers) {
                long now = System.currentTimeMillis();
                if (this.lastConsumerStarted + this.startConsumerMinInterval < now) {
                    this.addAndStartConsumers(1);
                    this.lastConsumerStarted = now;
                }
            }

        }
    }

3-5 小结

RabbitMQ并发消费的两个参数prefetchCount（spring.rabbitmq.listener.simple.prefetch）和concurrentConsumers（spring.rabbitmq.listener.simple.concurrency）：
concurrentConsumers是设置并发消费者的个数，可以进行初始化-最大值动态调整,并发消费者可以提高消息的消费能力，防止消息的堆积。
prefechCount是每个消费者一次性从broker中取出的消息个数,提高这个参数并不能对消息实现并发消费，仅仅是减少了网络传输的时间。
注：1>在rabbit:listener-container 中配置 prefetch属性设置消费端一次拉取多少消息
2>消费端的确认模式一定为手动确认。acknowledge=“manual”

4.TTL

4-1 应用场景

TTL（Time To Live，生存时间），当消息到达存活时间后，还没有被消费，会被自动清除。
RabbitMQ可以对消息设置过期时间，也可以对整个队列（Queue）设置过期时间。

4-2 流程图

4-3 代码实现

4-3-1 RabbitMq配置

 @Bean("topicMqTtlQ1")
    public Queue topicMqTtlQ1() {
        return QueueBuilder.durable("topic_mq_ttl_q1").ttl(10000).build();
    }

    @Bean("topicMqTtlExchange")
    public TopicExchange setTopicMqTtlExchange() {
        return new TopicExchange("topicMqTtlExchange");
    }

    @Bean
    public Binding bindTopicMqTtlQ1(@Qualifier("topicMqTtlExchange") TopicExchange topicExchange,@Qualifier("topicMqTtlQ1") Queue queue) {
        return BindingBuilder.bind(queue).to(topicExchange).with("topic_mq_ttl_q1_msg");
    }

4-3-2 消费者

无，10s后队列中的数据会自动消失

4-3-3 测试类

@Test
    public void testTtl() {
        rabbitTemplate.convertAndSend("topicMqTtlExchange","topic_mq_ttl_q1_msg","test");
    }

4-4 小结

1>设置队列过期时间使用参数：x-message-ttl，单位：ms(毫秒)，会对整个队列消息统一过期。
2>设置消息过期时间使用参数：expiration。单位：ms(毫秒)，当该消息在队列头部时（消费时），会单独判断这一消息是否过期。
如果两者都进行了设置，以时间短的为准。

 @Test
    public void testMsgTtl() throws UnsupportedEncodingException {
        String message = "I am the queen of computers";
        //设置部分请求参数
        MessageProperties messageProperties = new MessageProperties();
        messageProperties.setContentType(MessageProperties.CONTENT_TYPE_TEXT_PLAIN);
        messageProperties.setExpiration("1000");
        //发消息
        rabbitTemplate.send("topicMqExchange","topic_mq_q1_msg",new Message(message.getBytes(StandardCharsets.UTF_8),messageProperties));
    }

5.延迟队列

5-1 应用场景

1>下单后，30分钟未支付，取消订单，回滚库存；订单成功支付则什么都不做。
2>新用户注册成功7天后，发送短信问候。

5-2 流程图

5-3 代码实现

5-3-1 RabbitMq配置

1>application.properties

server.port=8888
spring.rabbitmq.port=5672
spring.rabbitmq.username=root
spring.rabbitmq.password=root
spring.rabbitmq.addresses=localhost
spring.rabbitmq.virtual-host=/
spring.rabbitmq.publisher-confirm-type=CORRELATED
spring.rabbitmq.publisher-returns=true
spring.rabbitmq.listener.simple.acknowledge-mode=manual

2>RabbitMqConfig

package com.practice.springboot.config;

import org.springframework.amqp.core.*;
import org.springframework.amqp.rabbit.connection.CorrelationData;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.amqp.support.converter.Jackson2JsonMessageConverter;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

import javax.annotation.PostConstruct;
import javax.annotation.Resource;
import java.util.HashMap;
import java.util.Map;


@Configuration
public class RabbitMqConfig {

	@Resource
	private RabbitTemplate rabbitTemplate;

	
	@Bean
	public Queue topicMqQ2() {
		Map<String, Object> arguments = new HashMap<>();
		arguments.put("x-dead-letter-exchange","topicMqDelayExchange");
		arguments.put("x-dead-letter-routing-key","topic_mq_delay_q2_msg");
		arguments.put("x-message-ttl",10000);
		return new Queue("topic_mq_q2",true,false,false,arguments);
	}
	
	@Bean
	public Queue topicMqDelayQ2() {
		return new Queue("topic_mq_delay_q2");
	}

	//声明exchange
	@Bean
	public TopicExchange setTopicMqExchange() {
		return new TopicExchange("topicMqExchange");
	}
	
	@Bean
	public TopicExchange setTopicMqDelayExchange() {
		return new TopicExchange("topicMqDelayExchange");
	}

	//声明binding，需要声明一个routingKey
	@Bean
	public Binding bindTopicMqQ2() {
		return BindingBuilder.bind(topicMqQ2()).to(setTopicMqExchange()).with("topic_mq_q2_msg");
	}
	@Bean
	public Binding bindTopicMqDelayQ2() {
		return BindingBuilder.bind(topicMqDelayQ2()).to(setTopicMqDelayExchange()).with("topic_mq_delay_q2_msg");
	}


}

5-3-2 消费者

 @RabbitListener(queues="topic_mq_delay_q2")
    public void topicReceiveMqDelayQ2Msg(Channel channel, @Payload String message, @Header(AmqpHeaders.DELIVERY_TAG) long deliveryTag) throws IOException {
		try {
			// 业务代码
			System.out.println("Topic模式 topic_mq_delay_q2 received  message : " +message);
		}  finally {
			channel.basicAck(deliveryTag,false);
		}
    }

5-3-3 测试类

package com.practice;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.context.junit4.SpringRunner;

import javax.annotation.Resource;

@SpringBootTest
@RunWith(SpringRunner.class)
public class ProducerTest {


    @Resource
    private RabbitTemplate rabbitTemplate;

    /*
     * 测试延时消息
     * */
    @Test
    public  void testDelay() throws InterruptedException {
        //1.发送消息
        rabbitTemplate.convertAndSend("topicMqExchange","topic_mq_q2_msg","test");


        //2.打印倒计时10秒
        for (int i = 10; i > 0 ; i--) {
            System.out.println(i+"...");
            Thread.sleep(1000);
        }

    }

}

运行结果如下：

5-4 源码解析

5-5 小结

1> 延迟队列 指消息进入队列后，可以被延迟一定时间，再进行消费。
2>RabbitMq虽没有提供延迟队列功能，但是可以使用 ： TTL + DLX 来达到延迟队列效果。

6.死信队列

6-1 应用场景

死信，在官网中对应的单词为“Dead Letter”，“死信”是RabbitMQ中的一种消息机制，当你在消费消息时，如果队列里的消息出现以下情况：
1>消息被否定确认，使用 channel.basicNack 或 channel.basicReject ，并且此时requeue 属性被设置为false。
2>消息在队列的存活时间超过设置的生存时间（TTL)时间。
3>消息队列的消息数量已经超过最大队列长度。
那么该消息将成为“死信”。
“死信”消息会被RabbitMQ进行特殊处理，如果配置了死信队列信息，那么该消息将会被丢进死信队列中，如果没有配置，则该消息将会被丢弃。

死信队列的配置：
1>配置业务队列，绑定到业务交换机上
2>为业务队列配置死信交换机和路由key（x-dead-letter-exchange 和 x-dead-letter-routing-key）
3>为死信交换机配置死信队列

6-2 流程图

6-3 代码实现

基础队列消费失败后，进行重试队列，重试三次后进入死信队列

6-3-1 RabbitMq配置

package com.practice.springboot.config;

import org.springframework.amqp.core.*;
import org.springframework.amqp.rabbit.connection.CorrelationData;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.amqp.support.converter.Jackson2JsonMessageConverter;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

import javax.annotation.PostConstruct;
import javax.annotation.Resource;
import java.util.HashMap;
import java.util.Map;


/*
Topics模式  交换机类型 topic
* */
@Configuration
public class RabbitMqConfig {

	@Resource
	private RabbitTemplate rabbitTemplate;

	//声明队列
	@Bean
	public Queue topicMqQ1() {
		return new Queue("topic_mq_q1");
	}
	@Bean
	public Queue topicMqRetryQ1() {
		// x-dead-letter-exchange指定重试时将消息重发给哪一个转发器、x-message-ttl消息到达重试队列后，多长时间后重发
		Map<String, Object> arguments = new HashMap<>();
		arguments.put("x-dead-letter-exchange","topicMqDelayExchange");
		arguments.put("x-dead-letter-routing-key","topic_mq_delay_q1_msg");
		arguments.put("x-message-ttl",10000);
		return new Queue("topic_mq_retry_q1",true,false,false,arguments);
		//return QueueBuilder.durable("topic_mq_retry_q1").deadLetterExchange("directDelayExchange").deadLetterRoutingKey("delay.china.changsha").ttl(10000).build();
	}
	@Bean
	public Queue topicMqDelayQ1() {
		return new Queue("topic_mq_delay_q1");
	}
	//声明exchange
	@Bean
	public TopicExchange setTopicMqExchange() {
		return new TopicExchange("topicMqExchange");
	}
	@Bean
	public TopicExchange setTopicMqRetryExchange() {
		return new TopicExchange("topicMqRetryExchange");
	}
	@Bean
	public TopicExchange setTopicMqDelayExchange() {
		return new TopicExchange("topicMqDelayExchange");
	}

	//声明binding，需要声明一个routingKey
	@Bean
	public Binding bindTopicMqQ1() {
		return BindingBuilder.bind(topicMqQ1()).to(setTopicMqExchange()).with("topic_mq_q1_msg");
	}
	@Bean
	public Binding bindTopicMqRetryQ1() {
		return BindingBuilder.bind(topicMqRetryQ1()).to(setTopicMqRetryExchange()).with("topic_mq_retry_q1_msg");
	}
	@Bean
	public Binding bindTopicMqDelayQ1() {
		return BindingBuilder.bind(topicMqDelayQ1()).to(setTopicMqDelayExchange()).with("topic_mq_delay_q1_msg");
	}
}

6-3-2 消费者

	@RabbitListener(queues="topic_mq_q1")
	public void topicReceiveMqq1Msg1(Channel channel, @Payload String message, @Header(AmqpHeaders.DELIVERY_TAG) long deliveryTag) throws Exception {
		// MessagingMessageListenerAdapter.invokeHandlerAndProcessResult
		// Message message ->  @Payload String message, @Header(AmqpHeaders.DELIVERY_TAG) long deliveryTag
		//  @Headers Map<String,Object> messageMap
		System.out.println("Topic模式 topic_mq_q1 received  message : " +message);
		try {
			// 业务代码
			businessHandle();
		} catch (Exception e) {
			MessageVo vo = new MessageVo(message,1);
			retryHandle(vo,"topicMqRetryExchange","topic_mq_retry_q1_msg");
		} finally {
			channel.basicAck(deliveryTag,false);
		}
	}

	@RabbitListener(queues="topic_mq_retry_q1")
	public void topicReceiveMqRetryQ1Msg(Channel channel, @Payload String message, @Header(AmqpHeaders.DELIVERY_TAG) long deliveryTag) throws Exception {
		MessageVo vo = JSON.parseObject(message, MessageVo.class);
		if (vo.getRetryCount() > 3) {
			// 超过重试次数则不重回队列
			// 当channel.basicNack 第三个参数设为true时，消息签收失败会继续进入消息队列等待消费
			// 当channel.basicNack 第三个参数设为false时，消息签收失败,此时消息进入死信队列，完成消费
			channel.basicNack(deliveryTag,false,false);
			System.out.println("超出重试上限，手动进入死信队列");
			return;
		}
		System.out.println("Topic模式 topic_mq_retry_q1 received  message : " +message + "，重试第"+ vo.getRetryCount() + "次");
		try {
			// 执行业务代码
			businessHandle();
		} catch (Exception e) {
			vo.setRetryCount(vo.getRetryCount()+1);
			retryHandle(vo,"topicMqRetryExchange","topic_mq_retry_q1_msg");
		} finally {
			channel.basicAck(deliveryTag,false);
		}
	}

	@RabbitListener(queues="topic_mq_delay_q1")
	public void topicReceiveMqDelayQ1Msg(Channel channel, @Payload String message, @Header(AmqpHeaders.DELIVERY_TAG) long deliveryTag) throws IOException {
		System.out.println("Topic模式 topic_mq_delay_q1 received  message : " +message);
		channel.basicAck(deliveryTag,false);
	}

	private void businessHandle() throws Exception{
		// todo
		int i = 1/0;
	}

	private void retryHandle(MessageVo vo,String retryExchange,String routingKey) throws Exception{
		MessageProperties messageProperties = new MessageProperties();
		messageProperties.setContentType(MessageProperties.CONTENT_TYPE_TEXT_PLAIN);
		//messageProperties.setExpiration("10000"); // 设置过期时间
		String message = JSONObject.toJSONString(vo);
		rabbitTemplate.send(retryExchange,routingKey,new Message(message.getBytes(StandardCharsets.UTF_8),messageProperties));
	}

6-3-3 测试类

  @Test
    public void test() {
        String str1 = "I am the queen of computers";
        rabbitTemplate.convertAndSend("topicMqExchange","topic_mq_q1_msg",str1);
    }

6-4 源码解析

6-5 小结

7.消息幂等性保障

场景1：消费者在消费完一条消息后，向RabbitMQ 发送一个ACK 确认，但是此时网络断开或者其他原因导致RabbitMQ 没有收到这个ACK，那么RabbitMQ 并不会讲该条消息删除，而是重回队列，当客户端重新建立到连接后，消费者还是会再次收到该条消息，这就造成了消息的重复消费。
场景2：消息在发送的时候，同一条消息也可能发送多次。

解决方案
1>生成全局id，存入redis或者数据库，在消费者消费消息之前，查询一下该消息是否有消费过。
2>如果该消息已经消费过，则告诉mq消息已经消费，将该消息丢弃（手动ack）。
3>如果没有消费过，将该消息进行消费并将消费记录写进redis或者数据库中。
注：还有一种方式，数据库操作可以设置唯一键（消息id），防止重复数据的插入，这样插入只会报错而不会插入重复数据。

8.消息积压

1>消费者宕机积压
2>消费者消费能力不足积压
3>发送者发流量太大

解决方案:上线更多的消费者,进行正常消费上线专门的队列消费服务,将消息先批量取出来,记录数据库,再慢慢处理

三、问题

1.@RabbitListener和@RabbitHandler必须一起使用吗？

答：不是
@RabbitListener可以用于方法和类上，
1>@RabbitListener标注在方法上，直接监听指定的队列，此时接收的参数需要与发送类型一致
发布端：

 @Test
    public void testRabbitHandler() {
        String str1 = "I am the queen of computers";
        rabbitTemplate.convertAndSend("topicMqExchange","topic_mq_q1_msg",str1);
    }

消费端：

@RabbitListener(queues = "topic_mq_q1")
	public void topicReceiveMqq1Msg1(Channel channel, @Payload String message, @Header(AmqpHeaders.DELIVERY_TAG) long deliveryTag) throws Exception {
		try {
			// 业务代码
			System.out.println("Topic模式 topic_mq_q1 received  message1 : " +message);
		}  finally {
			channel.basicAck(deliveryTag,false);
		}
	}

运行结果为：

但是，同时有其它类型的参数会出现报错吗？答案是不会，默认将类型转换成了字符串。

 @Test
    public void testRabbitHandler() {
        String[] str = new String[]{"I"," am ","the queen of computers......"};
        rabbitTemplate.convertAndSend("topicMqExchange","topic_mq_q1_msg",str);
        String str1 = "I am the queen of computers";
        rabbitTemplate.convertAndSend("topicMqExchange","topic_mq_q1_msg",str1);
        char[] str2 = new char[]{'q','u','e','e','n'};
        rabbitTemplate.convertAndSend("topicMqExchange","topic_mq_q1_msg",str2);
}

运行结果为：


2>@RabbitListener 可以标注在类上面，需配合 @RabbitHandler 注解一起使用
@RabbitListener 标注在类上面表示当有收到消息的时候，就交给 @RabbitHandler 的方法处理，根据接受的参数类型进入具体的方法中。
发布端：

 @Test
    public void testRabbitHandler() {
        String[] str = new String[]{"I"," am ","the queen of computers......"};
        rabbitTemplate.convertAndSend("topicMqExchange","topic_mq_q1_msg",str);
        String str1 = "I am the queen of computers";
        rabbitTemplate.convertAndSend("topicMqExchange","topic_mq_q1_msg",str1);
        char[] str2 = new char[]{'q','u','e','e','n'};
        rabbitTemplate.convertAndSend("topicMqExchange","topic_mq_q1_msg",str2);
    }

消费端：

@Component
@RabbitListener(queues = "topic_mq_q1")
public class TopicConcumerReceiver {

	@Autowired
	private RabbitTemplate rabbitTemplate;

	@RabbitHandler
	public void topicReceiveMqq1Msg1(Channel channel, @Payload String message, @Header(AmqpHeaders.DELIVERY_TAG) long deliveryTag) throws Exception {
		try {
			// 业务代码
			System.out.println("Topic模式 topic_mq_q1 received  message1 : " +message);
		}  finally {
			channel.basicAck(deliveryTag,false);
		}
	}

	@RabbitHandler
	public void topicReceiveMqq1Msg1(Channel channel, @Payload String[] message, @Header(AmqpHeaders.DELIVERY_TAG) long deliveryTag) throws Exception {
		try {
			// 业务代码
			System.out.println("Topic模式 topic_mq_q1 received  message2 : " + Arrays.toString(message));
		}  finally {
			channel.basicAck(deliveryTag,false);
		}
	}	
}

运行结果为：

队列中有一条消息并未消费掉，是因为没有对应的char[]类型的消息体进行消费。
重新运行单元测试的方法，会存在报错信息：该报错指的是消费队列中的那一条消息的时候找不到对应的消费者，此时队列中会出现两条未被消费的消息。

2.消息消费的顺序性

为什么要顺序消费？
保证消息的顺序消费是生产业务场景下经常面临的挑战，例如电商的下单逻辑，在用户下单之后，会发送创建订单和扣减库存的消息，我们需要保证扣减库存在创建订单之后执行。
1>处理业务逻辑后，向MQ发送一条消息，再由消费者从 MQ 中获取 消息落盘到MySQL 中。
2>在这个过程中，可能会有增删改的操作，比如执行顺序是增加、修改、删除。
3>消费者可能换了顺序给执行成删除、修改、增加，所以我们要保证消息的顺序消费。

为什么会不按顺序消费？
对于 RabbitMQ 来说，导致上面顺序错乱的原因通常是消费者是集群部署，不同的消费者消费到了同一订单的不同的消息。
1>如消费者1执行了增加，消费者2执行了修改，消费者C执行了删除
2>但是消费者C执行比消费者B快，消费者B又比消费者A快，就会导致消费消息的时候顺序错乱
3>本该顺序是增加、修改、删除，变成了删除、修改、增加.

如何解决?
RabbitMQ 的问题是由于不同的消息都发送到了同一个 queue 中，多个消费者都消费同一个 queue 的消息。

1>我们可以给 RabbitMQ 创建多个 queue，每个消费者固定消费一个 queue 的消息，
1>生产者发送消息的时候，同一个类型的消息发送到同一个 queue 中
1>由于同一个 queue 的消息是一定会保证有序的，那么同一个订单号的消息就只会被一个消费者顺序消费，从而保证了消息的顺序性。

3.消息重复问题

出现场景：
1>消息生产者产生了重复的消息
2>kafka和rocketmq的offset被回调了
3>消息消费者确认失败
4>消息消费者确认时超时了
5>业务系统主动发起重试

不管是由于生产者产生的消息重复，还是由于消费者导致的消息重复，我们都可以在消费者中来进行解决。（消费者在做业务处理时，要做幂等设计）

推荐方法：增加一张消费消息表，使用messageId做唯一索引，在处理业务逻辑之前，先根据messageId查询一下该消息有没有处理过，如果已经处理过了则直接返回成功，如果没有处理过，则继续做业务处理。

4.数据一致性问题

数据一致性分为：强一致性、弱一致性和最终一致性
MQ中遵循的是最终一致性，因此在消费者消费失败后才会增加了重试机制。
重试分为同步重试和异步重试，
同步重试：有些消息量比较小的业务场景，可以采用同步重试，在消费消息时如果处理失败，立刻重试3-5次，如果还是失败，则写入到记录表中。但如果消息量比较大，则不建议使用这种方式，因为如果出现网络异常，可能会导致大量的消息不断重试，影响消息读取速度，造成消息堆积。
异步重试：而消息量比较大的业务场景，建议采用异步重试，在消费者处理失败之后，立刻写入重试表，添加一个job专门定时去重试。还有一种做法是，如果消费失败，自己给同一个topic发一条消息，在后面的某个时间点，自己又会消费到那条消息，起到了重试的效果。但是仅适用于对消息顺序要求不高的场景。

5.消息丢失问题

为了解决这个问题，可以增加一张消息发送表，当生产者发完消息之后，会往该表中写入一条数据，状态status标记为待确认。如果消费者读取消息之后，则更新该消息的status为已确认。