rabbitmq保证消息不重复消费，消息不丢失，消息积压问题处理_怎么保证mq消费积压

不重复消费和顺序消费

不重复消费

生产端

由于生产者发送消息给MQ，在MQ确认的时候出现了网络波动或者其他情况，生产者没有收到确认，实际上MQ已经接收到了消息。这时候生产者就会重新发送一遍这条消息。
生产者中如果消息未被确认，或确认失败，我们可以使用定时任务+（redis/db）来进行消息重试
在发送消息的时候写入redis 或者 db ，当没有收到确认的时候，通过定时任务先查reids或者db里面是否存在，存在就不重复发送，不存在则发送

消费端

消费者消费成功后，再给MQ确认的时候出现了网络波动或者其他情况，MQ没有接收到确认，为了保证消息被消费，MQ就会继续给消费者投递之前的消息。这时候消费者就接收到了两条一样的消息。
由于重复消息是由于网络原因造成的，因此不可避免重复消息。但是我们需要保证消息的幂等性。

保证接口幂等

消费者获取到消息后先根据id去查询redis/db是否存在该消息
如果不存在，则正常消费，消费完毕后写入redis/db
如果存在，则证明消息被消费过，直接丢弃

消息丢失

消息发送方

configrm消息确认机制

生产端投递的消息一旦投递到RabbitMQ后，RabbitMQ就会发送一个确认消息给生产端，让生产端知道我已经收到消息了，否则这条消息就可能已经丢失了，需要生产端重新发送消息了。

可以手动开启确认模式

channel.confirmSelect();// 开启发送方确认模式
1
2

开启异步监听确认和未确认的消息

channel.addConfirmListener(new ConfirmListener() {
    //消息正确到达broker
    @Override
    public void handleAck(long deliveryTag, boolean multiple) throws IOException {
        System.out.println("已收到消息");
        //做一些其他处理
    }
    //RabbitMQ因为自身内部错误导致消息丢失，就会发送一条nack消息
    @Override
    public void handleNack(long deliveryTag, boolean multiple) throws IOException {
        System.out.println("未确认消息，标识：" + deliveryTag);
        //做一些其他处理，比如消息重发等
    }
});
1
2
3
4
5
6
7
8
9
10
11
12
13
14

极端情况（服务器挂了，mq挂了）

Rabbitmq收到消息暂时存到了内存中，如果这个时候RabbitMQ挂了，重启之后数据就丢失了，所以我们要持久化数据到硬盘。
message消息到达RabbitMQ后先是到exchange交换机，然后路由给queue队列，最后发送给消费端

所以message,queue和message都进行持久化：

message持久化：

//第三个参数MessageProperties.PERSISTENT_TEXT_PLAIN表示这条消息持久化
channel.basicPublish(EXCHANGE_NAME, ROUTING_KEY, MessageProperties.PERSISTENT_TEXT_PLAIN, message.getBytes(StandardCharsets.UTF_8));
1
2

exchange持久化

//第三个参数true表示这个exchange持久化
channel.exchangeDeclare(EXCHANGE_NAME, "direct", true);
1
2

queue持久化

//第二个参数true表示这个queue持久化
channel.queueDeclare(QUEUE_NAME, true, false, false, null);
1
2

这样，如果RabbitMQ收到消息后挂了，重启后会自行恢复消息。

恶心情况

比如RabbitMq还没来得及将消息持久化到硬盘时，Rabbitmq挂了，这时候消息还是丢失了，或者由于网络问题导致生产端没有收到确认消息，这时候消息还是会丢失

消息入库

将消息存入数据库
这里有可能会出现上面说的两种情况，所以生产端这边开一个定时器，定时检索消息表，将status=0并且超过固定时间后（可能消息刚发出去还没来得及确认这边定时器刚好检索到这条status=0的消息，所以给个时间）还没收到确认的消息取出重发（第二种情况下这里会造成消息重复，消费者端要做幂等性），可能重发还会失败，所以可以做一个最大重发次数，超过就做另外的处理。

消息接收方

丢失情况：

• 在RabbitMQ将消息发出后，消费端还没接收到消息之前，发生网络故障，消费端与RabbitMQ断开连接，此时消息会丢失；
• 在RabbitMQ将消息发出后，消费端还没接收到消息之前，消费端挂了，此时消息会丢失；
• 消费端正确接收到消息，但在处理消息的过程中发生异常或宕机了，消息也会丢失。

消费端导致消息丢失的情况主要是RabbitMQ的自动ack机制，默认mq在消息发出后将这条消息删除，而不管消费端是否接收到。

所以需要将自动ACK改为手动ACK
手动确认代码

DeliverCallback deliverCallback = (consumerTag, delivery) -> {
    try {
        //接收到消息，做处理
        //手动确认
        channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false);
    } catch (Exception e) {
        //出错处理，这里可以让消息重回队列重新发送或直接丢弃消息
    }
};
//第二个参数autoAck设为false表示关闭自动确认机制，需手动确认
channel.basicConsume(QUEUE_NAME, false, deliverCallback, consumerTag -> {});
1
2
3
4
5
6
7
8
9
10
11

这样，当autoAck参数置为false，对于RabbitMQ服务端而言，队列中的消息分成了两个部分：

• 一部分是等待投递给消费端的消息；
• 一部分是已经投递给消费端，但是还没有收到消费端确认信号的消息。

如果RabbitMQ一直没有收到消费端的确认信号，并且消费此消息的消费端已经断开连接或宕机，则RabbitMQ会安排该消息重新进入队列（放在队列头部），等待投递给下一个消费者，当然也有可能还是原来的那个消费端，当然消费端也需要确保幂等性。

消息积压

消息积压几种产生情况

• 消费者宕机，导致消息队列中的消息无法及时被消费，出现积压。
• 消费者没有宕机，但因为本身逻辑处理数据耗时，导致消费者消费能力不足，引起队列消息积压。
• 消息生产方单位时间内产生消息过多，比如“双11大促活动”，导致消费者处理不过来。

根据原因给出几种解决方案

• 先修复consumer的问题，确保其恢复消费速度，然后将现有cnosumer都停掉
• 新建一个topic，partition是原来的10倍，临时建立好原先10倍或者20倍的queue数量
• 然后写一个临时的分发数据的consumer程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的10倍数量的queue
• 接着临时征用10倍的机器来部署consumer，每一批consumer消费一个临时queue的数据
• 这种做法相当于是临时将queue资源和consumer资源扩大10倍，以正常的10倍速度来消费数据
• 等快速消费完积压数据之后，得恢复原先部署架构，重新用原先的consumer机器来消费消息

这种是限流