RocketMq如何保证消息不丢失？如何处理消息堆积？-CSDN博客

本文链接：https://blog.csdn.net/2301_79818243/article/details/147430305

RocketMQ的消息想要确保不丢失，需要生产者、消费者以及Broker的共同努力，缺一不可。

生产

在生产阶段，主要通过请求确认机制，来保证消息的可靠传递。

1、同步发送消息的情况下，要注意处理响应结果和异常。如果返回响应 OK，表示消息成功发送到了 Broker，如果响应失败，或者发生其它异常，都应该重试。

消息的发送会同步阻塞等待Broker返回结果，在Broker确认收到消息之后，生产者才会拿到SendResult。如果这个过程中发生异常，那么就说明消息发送可能失败了，就需要生产者进行重新发送消息。
但是Broker其实并不会立即把消息存储到磁盘上，而是先存储到内存中，内存存储成功之后，就返回给确认结果给生产者了，然后再通过异步刷盘的方式将内存中的数据存储到磁盘上。但是这个过程中，如果机器挂了，那么就可能会导致数据丢失。
如果想要保证消息不丢失，可以将消息保存机制修改为同步刷盘，这样，Broker会在同步请求中把数据保存在磁盘上，确保保存成功后再返回确认结果给生产者。
2、异步发送，异步发送的话就需要生产者重写SendCallback的onSuccess和onException的回调方法，用于给Broker进行回调。在方法中实现消息的确认或者重新发送

存储

持久化：消息只要持久化到 CommitLog（日志文件）中，即使 Broker 宕机，未消费的消息也能重新恢复再消费。
主从集群：为了保证消息不丢失，RocketMQ肯定要通过一主多从集群方式进行部署，Broker通常采用一主多从部署方式，并且采用主从同步的方式做数据复制。
同步复制：Broker 通过主从模式来保证高可用，Broker 支持 Master 和 Slave 同步复制、Master 和 Slave 异步复制模式，生产者的消息都是发送给 Master，但是消费既可以从 Master 消费，也可以从 Slave 消费。同步复制模式可以保证即使 Master 宕机，消息肯定在 Slave 中有备份，保证了消息不会丢失。
冗余备份：当主Broker宕机时，从Broker会接管主Broker的工作，保证消息不丢失。同时，RocketMQ的Broker还可以配置多个实例，消息会在多个Broker之间进行冗余备份，从而保证数据的可靠性，
默认方式下，Broker在接收消息后，写入 master 成功，就可以返回确认响应给生产者了，接着消息将会异步复制到 slave 节点。但是如果这个过程中，Master的磁盘损坏了。那就会导致数据丢失了。
如果想要解决这个问题，可以配置同步复制的方式，即Master在将数据同步到Slave节点后，再返回给生产者确认结果。

消费

在消费者端，**保证消息成功消费的关键在于确认的时机，不要在收到消息后就立即发送消费确认，而是应该在执行完所有消费业务逻辑之后，再发送消费确认。**需要确保在消息拉取并消费成功之后再给Broker返回ACK，就可以保证消息不丢失了，如果这个过程中Broker一直没收到ACK，那么就可以重试:
所以，在消费者的代码中，一定要在业务逻辑的最后一步returnConsumeConcurrentlyStatus.CONSUME_SUCESS :当然，也可以先把数据保存在数据库中，就返回，然后自己再慢慢处理。
但是，需要注意的是RocketMQ和Kafka一样，只能最大限度的保证消息不丢失，但是没办法做到100%保证不丢失。

RocketMQ的消息堆积，一股都是因为客户端本地消费过程中，由于消费耗时过长或消费并发度较小等原因，导致客户端消费能力不足，出现消息堆积的问题
当线上出现消息堆积的问题时，一般有以下几种方式来解决:

增加消费者数量\提升消费者消费速度:消息堆积了，消费不过来了，那就把消费者的数量增加一下，让更多人的实例来消费这些消息。想办法提升消费速度，比如引入线程池,本地消息存储后即返回成功后续再慢慢消费等。
丢弃过期消息:有一些过期消息、或者一直无法成功的消息，在业务做评估之后，如果无影响或者影响不大其实是可以清理的。
调整 RocketMQ 的配置参数:RocketMQ 提供了很多可配置的参数，例如消息消费模式、消息拉取间隔时间等，可以根据实际情况来调整这些参数，从而优化消息消费的效率。
增加 Topic 队列数:如果一个 Topic 的队列数比较少，那么就容易出现消息堆积的情况。可以通过增加队列数来提高消息的处理并发度，从而减少消息堆积。
消息迁移 Queue 扩容：如果当前 Topic 的 Message Queue 的数量小于或者等于消费者数量，这种情况，再扩容消费者就没什么用，就得考虑扩容 Message Queue。可以新建一个临时的 Topic，临时的 Topic 多设置一些 Message Queue，然后先用一些消费者把消费的数据丢到临时的 Topic，因为不用业务处理，只是转发一下消息，还是很快的。接下来用扩容的消费者去消费新的 Topic 里的数据，消费完了之后，恢复原状。