RocketMQ常见问题分析

发布时间：2023年12月25日

1.?RocketMQ如何保证消息不丢失

1.1 分析消息丢失场景

1.2 解决方案

1.2.1 保证消息生产不丢失

1.2.1.1 生产消息时不使用单向发送消息发送模式

1.2.1.2?生产者使用事务消息机制

1.2.2 保证消息存储不丢失

1.2.3 保证消息消费不丢失

1.2.4?RocketMQ特有的问题，NameServer挂了如何保证消息不丢失？

2.?使用RocketMQ如何快速处理积压消息？

2.1?如何确定RocketMQ有大量的消息积压？

2.2?如何处理大量积压的消息？

1.?RocketMQ如何保证消息不丢失

1.1 分析消息丢失场景

下图是一个MQ的通用场景图：

从上图中，我们可以得到，消息流转的4个环节

1：生产者发送消息到MQ服务
2：主从同步
3：同步磁盘
4：消费者消费消息

????????其中1、3、4这3个环节都是跨网络的，而跨网络，那就可能会丢失消息。

????????关于3这个环节，通常MQ存盘时都会先写入操作系统的缓存page cache中，然后再由操作异步的将消息写入硬盘。这个中间有个时间差，就可能会造成消息丢失。如果服务挂了，缓存中还没有来得及写入硬盘的消息就会丢失。

1.2 解决方案

? ? ? ? 接下来我们看一下，当我们用RocketMQ时,如何解决上述4个环节丢失消息的场景；

1.2.1 保证消息生产不丢失

1.2.1.1 生产消息时不使用单向发送消息发送模式

? ? ? ? 我们想一下，消息生产时为什么会丢失消息。当生产者发送消息时，如果出现了网络抖动或者消息异常，那么消息就有可能丢失。那么这个问题解决思路是什么呢？其实简单的来说就是4个字：应答重试。

? ? ? ? 怎么理解应答重试呢？其实就是当生产者发送消息成功后返回成功确认消息，如果发送失败，客户端就尝试自动重试，避免网络抖动导致消息发送不成功。如果超过一定超时时间还是失败，那就抛出异常，由开发者自己在应用层面进行处理，手动重试发送或者记录失败。

? ? ?不过我们需要特别注意是，RocketMQ支持多种「消息类型」，但是并不是对所有「消息类型」都会有应答重试机制（消息确认机制和失败重试机制）。

????????RocketMQ生产消息时，支持多种「消息类型」和「消息发送模式」。有兴趣同学可以参考org.apache.rocketmq.client.producer.MQProducer这个接口定义即可。接下来我们看一下rocketMQ的消息类型和消息发送模式又哪些以及各自的特点：

消息类型：

普通消息：发送普通消息，异常时默认重试。
普通有序消息：发送普通有序消息，通过指定「消息筛选器selector」，动态决定发送哪个队列。异常默认不重试，可以用户自己重试，并发送到其他队列。
严格有序消息：发送严格有序消息，通过指定队列，保证严格有序，异常默认不重试。

消息发送模式：

同步：调用发送消息方法后，同步阻塞，直到返回SendResult。配置retryTimesWhenSendFailed重试次数。
异步：调用发送消息方法后，立即返回，发送结果会通过开发者自己注册的回调函数SendCallback进行处理。配置retryTimesWhenSendAsyncFailed重试次数。
单向发送：这种方法完全不关心发送后的返回结果。显然，它具有最大吞吐量，但也存在消息丢失的潜在风险。

????????消息类型和消息发送模式是 N * M 的关系，所以存在9种不同组合，RocketMQ也是定义了9种不同接口方法。
这9种方法里面，涉及到「单向发送」模式的3种方法，都是不可靠的，存在丢失消息的风险。其他发送消息的模式和消息类型，可以通过消息确认、mq-client自动「失败重试机制」、业务自定义重试等方式，确保消息发送不丢失。

1.2.1.2?生产者使用事务消息机制

????????org.apache.rocketmq.client.producer.MQProducer还定义了「事务消息」的发送模式，接下来我们理解一下事务机制；因为RocketMQ的事务消息机制就是为了保证零丢失来设计的，并且经过阿里的验证，肯定是非常靠谱的。所以事务机制也可以报纸生产者生产消息时不丢失消息。接下来我们用一个场景来简单分析一下事务消息机制是如何保证消息不丢失的。我们看下下面这个流程图：

1、为什么要发送个half消息？有什么用？

这个half消息是在订单系统进行下单操作前发送，并且对下游服务的消费者是不可见的。那这个消息的作用更多的体现在确认RocketMQ的服务是否正常。相当于嗅探下RocketMQ服务是否正常，并且通知RocketMQ，我马上就要发一个很重要的消息了，你做好准备。

2.half消息如果写入失败了怎么办？

如果没有half消息这个流程，那我们通常是会在订单系统中先完成下单，再发送消息给MQ。这时候写入消息到MQ如果失败就会非常尴尬了。而half消息如果写入失败，我们就可以认为MQ的服务是有问题的，这时，就不能通知下游服务了。我们可以在下单时给订单一个状态标记，然后等待MQ服务正常后再进行补偿操作，等MQ服务正常后重新下单通知下游服务。

3.订单系统写数据库失败了怎么办？

这个问题我们同样比较下没有使用事务消息机制时会怎么办？如果没有使用事务消息，我们只能判断下单失败，抛出了异常，那就不往MQ发消息了，这样至少保证不会对下游服务进行错误的通知。但是这样的话，如果过一段时间数据库恢复过来了，这个消息就无法再次发送了。当然，也可以设计另外的补偿机制，例如将订单数据缓存起来，再启动一个线程定时尝试往数据库写。而如果使用事务消息机制，就可以有一种更优雅的方案。

如果下单时，写数据库失败(可能是数据库崩了，需要等一段时间才能恢复)。那我们可以另外找个地方把订单消息先缓存起来(Redis、文本或者其他方式)，然后给RocketMQ返回一个UNKNOWN状态。这样RocketMQ就会过一段时间来回查事务状态。我们就可以在回查事务状态时再尝试把订单数据写入数据库，如果数据库这时候已经恢复了，那就能完整正常的下单，再继续后面的业务。这样这个订单的消息就不会因为数据库临时崩了而丢失。

4.half消息写入成功后RocketMQ挂了怎么办？

我们需要注意下，在事务消息的处理机制中，未知状态的事务状态回查是由RocketMQ的Broker主动发起的。也就是说如果出现了这种情况，那RocketMQ就不会回调到事务消息中回查事务状态的服务。这时，我们就可以将订单一直标记为"新下单"的状态。而等RocketMQ恢复后，只要存储的消息没有丢失，RocketMQ就会再次继续状态回查的流程。

5.下单成功后如何优雅的等待支付成功？

在订单场景下，通常会要求下单完成后，客户在一定时间内，例如10分钟，内完成订单支付，支付完成后才会通知下游服务进行进一步的营销补偿。

如果不用事务消息，那通常会怎么办？

最简单的方式是启动一个定时任务，每隔一段时间扫描订单表，比对未支付的订单的下单时间，将超过时间的订单回收。这种方式显然是有很大问题的，需要定时扫描很庞大的一个订单信息，这对系统是个不小的压力。

那更进一步的方案是什么呢？是不是就可以使用RocketMQ提供的延迟消息机制。往MQ发一个延迟1分钟的消息，消费到这个消息后去检查订单的支付状态，如果订单已经支付，就往下游发送下单的通知。而如果没有支付，就再发一个延迟1分钟的消息。最终在第十个消息时把订单回收。这个方案就不用对全部的订单表进行扫描，而只需要每次处理一个单独的订单消息。

那如果使用上了事务消息呢？我们就可以用事务消息的状态回查机制来替代定时的任务。在下单时，给Broker返回一个UNKNOWN的未知状态。而在状态回查的方法中去查询订单的支付状态。这样整个业务逻辑就会简单很多。我们只需要配置RocketMQ中的事务消息回查次数(默认15次)和事务回查间隔时间(messageDelayLevel)，就可以更优雅的完成这个支付状态检查的需求。

6、事务消息机制的作用