RocketMQ常见问题分析

目录

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、事务消息机制的作用

整体来说，在订单这个场景下，消息不丢失的问题实际上就还是转化成了下单这个业务与下游服务的业务的分布式事务一致性问题。而事务一致性问题一直以来都是一个非常复杂的问题。而RocketMQ的事务消息机制，实际上只保证了整个事务消息的一半，他保证的是订单系统下单和发消息这两个事件的事务一致性，而对下游服务的事务并没有保证。但是即便如此，也是分布式事务的一个很好的降级方案。目前来看，也是业内最好的降级方案。

1.2.2 保证消息存储不丢失

        从1.1分析消息场景中得知，消息存储丢失有两个场景：

场景1：消息保存到内存中，还没来得及刷盘到磁盘，机器宕机或者重启，导致内存中消息丢失。

场景2：为了提高可用性，Broker通常采用一主多从的部署方式，为了确保消息不丢失，消息需要被复制到从节点。当消息发送到master但是还没同步到slave broker时，master broker磁盘损坏，导致消息数据丢失。或者master宕机，consumer切换到slave消费数据，消息丢失。

        那我们逐个解决一下这两个问题；

场景1解决方案：

        默认情况下，消息在到达 Broker 端后会首先被保存在内存中，并立即向生产者返回确认响应。随后，Broker 会定期批量将一组消息异步刷入磁盘。这种方式减少了 I/O 操作次数，提高了性能。然而，如果发生机器掉电、异常宕机等情况，未及时将消息刷入磁盘，就可能导致消息丢失的情况。因此，我们可以通过改变RocketMQ的刷盘方式来确保 Broker 端不丢失消息并保证消息的可靠性。们需要修改消息保存机制为同步刷盘方式，即只有当消息成功存储到磁盘后才返回响应。可以通过flushDiskType = SYNC_FLUSH 参数进行控制。

针对场景2解决方案：

        在默认方式下，当消息成功写入主节点时，就会返回确认响应给生产者，并异步将消息复制到从节点。然而，如果主节点突然宕机且无法恢复，尚未复制到从节点的消息将会丢失。
        方案一：为了进一步提高消息的可靠性，我们可以采用同步复制方式。主节点将会同步等待从节点完成复制，然后才返回确认响应。这样可以确保消息的可靠性。可以通过brokerRole=SYNC_MASTER参数进行控制。

        方案二： 使用Dledger技术搭建的RocketMQ集群。Dledger的文件同步详解见下述章节1.2.2.1 Dledger的文件同步。

        注意，同步刷盘 和 同步复制 虽然能够保证消息不丢失，但是会严重降低性能，生产实践中需要根据实际情况综合评估。

1.2.2.1 Dledger的文件同步

​         在使用Dledger技术搭建的RocketMQ集群中，Dledger会通过两阶段提交的方式保证文件在主从之间成功同步。

​ Dledger是由开源组织OpenMessage带入到RocketMQ中的一种高可用集群方案。Dledger的主要作用有两个，一是进行Broker自动选主。二是接管Broker的CommitLog文件写入过程。将单机的文件写入，转为基于多数同意机制的分布式消息写入。

​ 简单来说，数据同步会通过两个阶段，一个是uncommitted阶段，一个是commited阶段。

​ Leader Broker上的Dledger收到一条数据后，会标记为uncommitted状态，然后他通过自己的DledgerServer组件把这个uncommitted数据发给Follower Broker的DledgerServer组件。

​ 接着Follower Broker的DledgerServer收到uncommitted消息之后，必须返回一个ack给Leader Broker的Dledger。然后如果Leader Broker收到超过半数的Follower Broker返回的ack之后，就会把消息标记为committed状态。

​ 再接下来， Leader Broker上的DledgerServer就会发送committed消息给Follower Broker上的DledgerServer，让他们把消息也标记为committed状态。这样，就基于Raft协议完成了两阶段的数据同步。

​ 另外，在实现层面，Dledger还有很多细节机制，保证消息的安全性。

1.2.3 保证消息消费不丢失

        正常情况下，消费者端都是需要先处理本地事务，然后再给MQ一个ACK响应，这时MQ就会修改Offset，将消息标记为已消费，从而不再往其他消费者推送消息。所以在Broker的这种重新推送机制下，消息是不会在传输过程中丢失的。但是也会有下面这种情况会造成服务端消息丢失：

 DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("please_rename_unique_group_name_4");
        consumer.registerMessageListener(new MessageListenerConcurrently() {
            @Override
            public ConsumeConcurrentlyStatus consumeMessage(List msgs,
                                                            ConsumeConcurrentlyContext context) {
                new Thread(){
                    public void run(){
                        //处理业务逻辑
                        System.out.printf("%s Receive New Messages: %s %n", Thread.currentThread().getName(), msgs);
                    }
                };
                return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
            }
        });

        ​ 这种异步消费的方式，就有可能造成消息状态返回后消费者本地业务逻辑处理失败造成消息丢失的可能。所以，在消费端我们不要使用异步消费机制来保证消息不丢失；

        在不使用异步机制的情况下，我们如何保证消费端不导致消息丢失呢？

        跟消息生产一样，就是 「消息确认机制」和「失败重试机制」。

        消费者从RocketMQ拉取消息后，需要返回"CONSUME_SUCCESS"来表示业务方已经正常完成消费。只有返回"CONSUME_SUCCESS"才算作消费完成。这就是消费时的「消息确认机制」。

        如果返回"CONSUME_LATER"，则会按照不同的消息延迟级别进行再次消费，延迟级别从秒到小时不等，最长延迟时间为2个小时后再次尝试消费。这就是消费时的「失败重试机制」。

        重试消息会被存入名为 "%RETRY%+消费组名称" 的Topic中，原始主题Topic会存入属性中。然后会基于定时任务机制，在到期时将任务再次拉取出来。

        另外，RocketMQ跟kafka不同的是，天然支持了 「死信队列机制」。

        如果在尝试消费的过程中达到了最大重试次数（通常为16次），仍然无法成功消费，则消息将被发送到死信队列，以确保消息存储的可靠性。后续业务可以根据死信队列，来做相关补偿措施。

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

         NameServer在RocketMQ中，是扮演的一个路由中心的角色，提供到Broker的路由功能。但是其实路由中心这样的功能，在所有的MQ中都是需要的。kafka是用zookeeper和一个作为Controller的Broker一起来提供路由服务，整个功能是相当复杂纠结的。而RabbitMQ是由每一个Broker来提供路由服务。而只有RocketMQ把这个路由中心单独抽取了出来，并独立部署。

        ​ 这个NameServer之前都了解过，集群中任意多的节点挂掉，都不会影响他提供的路由功能。那如果集群中所有的NameServer节点都挂了呢？

        ​ 有很多人就会认为在生产者和消费者中都会有全部路由信息的缓存副本，那整个服务可以正常工作一段时间。其实这个问题大家可以做一下实验，当NameServer全部挂了后，生产者和消费者是立即就无法工作了的。至于为什么，可以去源码中找找答案。

        ​ 那再回到我们的消息不丢失的问题，在这种情况下，RocketMQ相当于整个服务都不可用了，那他本身肯定无法给我们保证消息不丢失了。我们只能自己设计一个降级方案来处理这个问题了。例如在订单系统中，如果多次尝试发送RocketMQ不成功，那就只能另外找给地方(Redis、文件或者内存等)把订单消息缓存下来，然后起一个线程定时的扫描这些失败的订单消息，尝试往RocketMQ发送。这样等RocketMQ的服务恢复过来后，就能第一时间把这些消息重新发送出去。

1.3 rocketMQ消息零丢失方案总结

完整分析过后，整个RocketMQ消息零丢失的方案其实挺简单

• 生产者使用事务消息机制和不使用单项发送消息发送模式。
• Broker配置同步刷盘+Dledger主从架构
• 消费者不要使用异步消费。
• 整个MQ挂了之后准备降级方案

​         那这套方案是不是就很完美呢？其实很明显，这整套的消息零丢失方案，在各个环节都大量的降低了系统的处理性能以及吞吐量。在很多场景下，这套方案带来的性能损失的代价可能远远大于部分消息丢失的代价。所以，我们在设计RocketMQ使用方案时，要根据实际的业务情况来考虑。例如，如果针对所有服务器都在同一个机房的场景，完全可以把Broker配置成异步刷盘来提升吞吐量。而在有些对消息可靠性要求没有那么高的场景，在生产者端就可以采用其他一些更简单的方案来提升吞吐，而采用定时对账、补偿的机制来提高消息的可靠性。而如果消费者不需要进行消息存盘，那使用异步消费的机制带来的性能提升也是非常显著的。

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

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

        在正常情况下，使用MQ都会要尽量保证他的消息生产速度和消费速度整体上是平衡的，但是如果部分消费者系统出现故障，就会造成大量的消息积累。这类问题通常在实际工作中会出现得比较隐蔽。

导致消息积压场景举例：

场景一：例如某一天一个数据库突然挂了，大家大概率就会集中处理数据库的问题。等好不容易把数据库恢复过来了，这时基于这个数据库服务的消费者程序就会积累大量的消息。

场景二：或者网络波动等情况，也会导致消息大量的积累。

        ​ 对于消息积压，如果是RocketMQ或者kafka还好，他们的消息积压不会对性能造成很大的影响。而如果是RabbitMQ的话，那就惨了，大量的消息积压可以瞬间造成性能直线下滑。

​ RocketMQ确定消息是否有积压的方式:

方式一：使用web控制台，就能直接看到消息的积压情况。

​ 在Web控制台的主题页面，可以通过 Consumer管理 按钮实时看到消息的积压情况。

​ 方式二： 使用指令

通过mqadmin指令在后台检查各个Topic的消息延迟情况。

方式三: 查看文件

​ RocketMQ会在他的 ${storePathRootDir}/config 目录下落地一系列的json文件，也可以用来跟踪消息积压情况。

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

方案一：如果消息不是很重要，那么RocketMQ的管理控制台就直接提供了跳过堆积的功能。

方案二： 如果消息很重要，又确实是因为消费者端处理能力不不够，造成消息大量积压，那么我们可以设计出一套消息转移的方案。

​ 如果Topic下的MessageQueue配置得是足够多的，那每个Consumer实际上会分配多个MessageQueue来进行消费。这个时候，就可以简单的通过增加Consumer的服务节点数量来加快消息的消费，等积压消息消费完了，再恢复成正常情况。最极限的情况是把Consumer的节点个数设置成跟MessageQueue的个数相同。但是如果此时再继续增加Consumer的服务节点就没有用了。

​ 而如果Topic下的MessageQueue配置得不够多的话，那就不能用上面这种增加Consumer节点个数的方法了。这时怎么办呢？ 这时如果要快速处理积压的消息，可以创建一个新的Topic，配置足够多的MessageQueue。然后把所有消费者节点的目标Topic转向新的Topic，并紧急上线一组新的消费者，只负责消费旧Topic中的消息，并转储到新的Topic中，这个速度是可以很快的。然后在新的Topic上，就可以通过增加消费者个数来提高消费速度了。之后再根据情况恢复成正常情况。

注意

在官网中，还分析了一个特殊的情况。就是如果RocketMQ原本是采用的普通方式搭建主从架构，而现在想要中途改为使用Dledger高可用集群，这时候如果不想历史消息丢失，就需要先将消息进行对齐，也就是要消费者把所有的消息都消费完，再来切换主从架构。因为Dledger集群会接管RocketMQ原有的CommitLog日志，所以切换主从架构时，如果有消息没有消费完，这些消息是存在旧的CommitLog中的，就无法再进行消费了。这个场景下也是需要尽快的处理掉积压的消息。