RabbitMQ如何保证消息不丢失

最新推荐文章于 2024-03-05 16:47:38 发布

破晓.K

最新推荐文章于 2024-03-05 16:47:38 发布

阅读量2.9k

点赞数 3

分类专栏：中间件文章标签： java-rabbitmq rabbitmq 分布式

本文链接：https://blog.csdn.net/can_meng_yun/article/details/127142268

版权

中间件专栏收录该内容

4 篇文章 0 订阅

订阅专栏

RabbitMQ如何保证消息不丢失

解决消息在发送时消息丢失（发布确认）
解决MQ宕机导致内存中消息丢失（持久化机制）
- 队列实现持久化
- 消息实现持久化
解决消费者未处理完消息宕机导致消息丢失问题（消息应答）
- 自动应答
- 手动应答

先来看看消息都有可能再哪些环节丢失在这里插入图片描述

消息发送时由于网络异常导致消息发送失败
MQ把消息发送给消费者前宕机，存贮在内存中的消息丢失
消费者在处理完消息之前宕机，MQ认为消息已经发送成功，并把存储在内存中的消息删除，导致消息丢失

针对这三种情况来进行解决：

解决消息在发送时消息丢失（发布确认）

MQ接收消息后通知生产者我已经接收到消息了（这个过程交ack回调）

发布确认的原理

生产者将信道设置成 confirm 模式，一旦信道进入 confirm 模式，所有在该信道上面发布的消息都将会被指派一个唯一的 ID(从 1 开始)，一旦消息被投递到所有匹配的队列之后，broker就会发送一个确认给生产者(包含消息的唯一 ID)，这就使得生产者知道消息已经正确到达目的队列了，如果消息和队列是可持久化的，那么确认消息会在将消息写入磁盘之后发出，broker 回传给生产者的确认消息中 delivery-tag 域包含了确认消息的序列号，此外 broker 也可以设置basic.ack 的 multiple 域，表示到这个序列号之前的所有消息都已经得到了处理。confirm 模式最大的好处在于他是异步的，一旦发布一条消息，生产者应用程序就可以在等信道返回确认的同时继续发送下一条消息，当消息最终得到确认之后，生产者应用便可以通过回调方法来处理该确认消息，如果 RabbitMQ 因为自身内部错误导致消息丢失，就会发送一条 nack 消息，生产者应用程序同样可以在回调方法中处理该 nack 消息。

开启发布确认

发布确认默认是没有开启的，如果要开启需要调用方法 confirmSelect，每当你要想使用发布确认，都需要在 channel 上调用该方法。

Channel channel = connection.createChannel();
// 开启confirm模式
channel.confirmSelect();

发布确认有三种类型

单个确认发布

这是一种简单的确认方式，它是一种同步确认发布的方式，也就是发布一个消息之后只有它被确认发布，后续的消息才能继续发布，waitForConfirmsOrDie(long)这个方法只有在消息被确认的时候才返回，如果在指定时间范围内这个消息没有被确认那么它将抛出异常。

这种确认方式有一个最大的缺点就是:发布速度特别的慢，因为如果没有确认发布的消息就会阻塞所有后续消息的发布，这种方式最多提供每秒不超过数百条发布消息的吞吐量。当然对于某些应用程序来说这可能已经足够了。

// 单个确认
public static void publishMessageIndividually() throws Exception {
    Channel channel = RabbitMQUtils.getChannel();
    // 开启发布确认
    channel.confirmSelect();
    // 队列声明
    String queueName = UUID.randomUUID().toString();
    channel.queueDeclare(queueName, true, false, false, null);
    // 开始时间
    long begin = System.currentTimeMillis();

    for (int i= 0; i < MESSAGE_COUNT; i++) {
        channel.basicPublish("", queueName, MessageProperties.PERSISTENT_TEXT_PLAIN, "hello".getBytes());
        // 当个消息马上进行发布确认
        boolean b = channel.waitForConfirms();
        if (b) {
            System.out.println("消息发送成功");
        }
    }
    // 结束时间
    long end = System.currentTimeMillis();
    System.out.println("单个确认发布" + MESSAGE_COUNT + "条消息耗时：" + (end - begin) + "ms");
}

测试：单个确认发布1000条消息耗时：1223ms

批量确认发布

上面那种方式非常慢，与单个等待确认消息相比，先发布一批消息然后一起确认可以极大地提高吞吐量，当然这种方式的缺点就是:当发生故障导致发布出现问题时，不知道是哪个消息出现问题了，我们必须将整个批处理保存在内存中，以记录重要的信息而后重新发布消息。当然这种方案仍然是同步的，也一样阻塞消息的发布。

// 批量确认
public static void publishMessageBatch() throws Exception {
    Channel channel = RabbitMQUtils.getChannel();
    // 开启发布确认
    channel.confirmSelect();
    // 队列声明
    String queueName = UUID.randomUUID().toString();
    channel.queueDeclare(queueName, true, false, false, null);
    // 开始时间
    long begin = System.currentTimeMillis();

    for (int i= 0; i < MESSAGE_COUNT; i++) {
        channel.basicPublish("", queueName, MessageProperties.PERSISTENT_TEXT_PLAIN, "hello".getBytes());
        // 当个消息马上进行发布确认
        if (i % 100 == 0) {
            boolean b = channel.waitForConfirms();
            if (b) {
                System.out.println("消息发送成功");
            }
        }
    }
    // 结束时间
    long end = System.currentTimeMillis();
    System.out.println("批量确认发布" + MESSAGE_COUNT + "条消息耗时：" + (end - begin) + "ms");
}

测试：批量确认发布1000条消息耗时：121ms

异步确认发布

异步确认虽然编程逻辑比上两个要复杂，但是性价比最高，无论是可靠性还是效率都没得说，
他是利用回调函数来达到消息可靠性传递的，这个中间件也是通过函数回调来保证是否投递成功。
在这里插入图片描述

// 异步发送确认
public static void publishMessageAsync() throws Exception {
    Channel channel = RabbitMQUtils.getChannel();
    // 开启发布确认
    channel.confirmSelect();
    // 队列声明
    String queueName = UUID.randomUUID().toString();
    channel.queueDeclare(queueName, true, false, false, null);

    ConcurrentSkipListMap<Long, Object> map = new ConcurrentSkipListMap<>();

    // 开始时间
    long begin = System.currentTimeMillis();

    /**
     * 消息监听器 监听哪些消息发送成功，哪些消息发送失败
     */
    channel.addConfirmListener((deliveryTag, multiple) -> {
        // 消息确认成功回调函数
        System.out.println("确认消息：" + deliveryTag);
        if (multiple) {
            map.headMap(deliveryTag, true).clear();
        } else {
            map.remove(deliveryTag);
        }
    }, (deliveryTag, multiple) -> {
        // 消息确认失败回调函数
        String message = (String) map.get(deliveryTag);
        System.out.println("未确认消息是：" + message);
    });

    for (int i= 0; i < MESSAGE_COUNT; i++) {
        channel.basicPublish("", queueName, MessageProperties.PERSISTENT_TEXT_PLAIN, "hello".getBytes());
        map.put(channel.getNextPublishSeqNo() - 1, "hello");
    }
    // 结束时间
    long end = System.currentTimeMillis();
    System.out.println("异步确认发布" + MESSAGE_COUNT + "条消息耗时：" + (end - begin) + "ms");
}

测试：异步确认发布1000条消息耗时：34ms
异步确认发布不是发布一条就确认一条，当连续发送多条数据时，返回multiple为true，代表序号deliveryTag之前的消息一并确认。

如何处理异步未确认消息

最好的解决的解决方案就是把未确认的消息放到一个基于内存的能被发布线程访问的队列，比如说用 ConcurrentLinkedQueue 这个队列在 confirm callbacks 与发布线程之间进行消息的传递。

以上 3 种发布确认速度对比

确认发布类型	特点
单个确认发布	同步等待确认，简单，但吞吐量非常有限
批量确认发布	同步，简单，合理的吞吐量，一旦出现问题但很难推断出是那条消息出现了问题
单个确认发布	最佳性能和资源使用，在出现错误的情况下可以很好地控制，但是实现起来稍微难些

解决MQ宕机导致内存中消息丢失（持久化机制）

RabbitMQ持久化概念

如何保障当 RabbitMQ 服务停掉以后消息生产者发送过来的消息不丢失。默认情况下 RabbitMQ 退出或由于某种原因崩溃时，它忽视队列和消息，除非告知它不要这样做。确保消息不会丢失需要做两件事：我们需要将队列和消息都标记为持久化。

队列实现持久化

之前我们创建的队列都是非持久化的，rabbitmq 如果重启的化，该队列就会被删除掉，如果要队列实现持久化需要在声明队列的时候把 durable 参数设置为持久化。

// 定义队列持久化
boolean durable = true;
channel.queueDeclare(queueName, durable, false, false, null);

但是需要注意的就是如果之前声明的队列不是持久化的，需要把原先队列先删除，或者重新创建一个持久化的队列，不然就会出现错误！
在这里插入图片描述
持久化的队列在控制台可以看到’D’标识，这个时候即使重启 rabbitmq 队列也依然存在。

消息实现持久化

要想让消息实现持久化需要在消息生产者发布消息时，第三个参数上添加MessageProperties.PERSISTENT_TEXT_PLAIN 这个属性。

channel.basicPublish("", queueName, MessageProperties.PERSISTENT_TEXT_PLAIN, "hello".getBytes());

将消息标记为持久化并不能完全保证不会丢失消息。尽管它告诉 RabbitMQ 将消息保存到磁盘，但是这里依然存在当消息刚准备存储在磁盘的时候但是还没有存储完，消息还在缓存的一个间隔点。此时并没有真正写入磁盘。持久性保证并不强，但是对于我们的简单任务队列而言，这已经绰绰有余了。如果需要更强有力的持久化策略，可以配合发布确认，来使用。
当消息被持久化到磁盘之后再向生产者确认ack，可以有效的避免消息丢失。

解决消费者未处理完消息宕机导致消息丢失问题（消息应答）

概念

消费者完成一个任务可能需要一段时间，如果其中一个消费者处理一个长的任务并仅只完成了部分突然它挂掉了，会发生什么情况。RabbitMQ 一旦向消费者传递了一条消息，便立即将该消息标记为删除。在这种情况下，突然有个消费者挂掉了，我们将丢失正在处理的消息。
为了保证消息在发送过程中不丢失，rabbitmq 引入消息应答机制，消息应答就是：消费者在接收到消息并且处理该消息之后，告诉 rabbitmq 它已经处理了，rabbitmq 可以把该消息删除了。

自动应答

消息发送后立即被认为已经传送成功，这种模式需要在高吞吐量和数据传输安全性方面做权衡，因为这种模式如果消息在接收到之前，消费者那边出现连接或者 channel 关闭，那么消息就丢失了，当然另一方面这种模式消费者那边可以传递过载的消息，没有对传递的消息数量进行限制，当然这样有可能使得消费者这边由于接收太多还来不及处理的消息，导致这些消息的积压，最终使得内存耗尽，最终这些消费者线程被操作系统杀死，所以这种模式仅适用在消费者可以高效并以某种速率能够处理这些消息的情况下使用。

消费者在接收消息时可以指定是否自动应答：

// 是否自动应答
boolean autoAck = true;
channel.basicConsume("console", autoAck, (x, y) -> {
    System.out.println("消息：" + new String(y.getBody(), StandardCharsets.UTF_8));
}, System.out::println);

手动应答

默认消息采用的是自动应答，所以我们要想实现消息消费过程中不丢失，需要把自动应答改为手动应答，将Boolean类型的autoAck改成false。

// 是否自动应答
boolean autoAck = false;
 channel.basicConsume("return_queue", autoAck, (x, y) -> {
     System.out.println("消息：" + new String(y.getBody(), StandardCharsets.UTF_8));
     // 处理完消息手动应答
     channel.basicAck(y.getEnvelope().getDeliveryTag(), false);
 }, System.out::println);

消息应答的方法

Channel.basicAck(用于肯定确认)
RabbitMQ 已知道该消息并且成功的处理消息，可以将其丢弃了
Channel.basicNack(用于否定确认)
Channel.basicReject(用于否定确认)
与 Channel.basicNack 相比少一个参数，不处理该消息了直接拒绝，可以将其丢弃了

Multiple 的解释在这里插入图片描述
multiple 的 true 和 false 代表不同意思

true 代表批量应答 channel 上未应答的消息
比如说 channel 上有传送 tag 的消息 5,6,7,8 当前 tag 是 8，那么此时，5-8 的这些还未应答的消息都会被确认收到消息应答
false 同上面相比
只会应答 tag=8 的消息 5,6,7 这三个消息依然不会被确认收到消息应答