RocketMQ初级解析

起飞的猪^(*￣(oo)￣)^

已于 2023-11-28 14:59:25 修改

阅读量79

点赞数

分类专栏： RocketMQ 文章标签： java-rocketmq java spring boot

于 2023-03-03 14:02:07 首次发布

本文链接：https://blog.csdn.net/weixin_50405726/article/details/129313670

版权

RocketMQ 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

1、你们为什么使用mq？具体的使用场景是什么？

mq的作用很简单，削峰填谷。以电商交易下单的场景来说，正向交易的过程可能涉及到创建订单、扣减库存、扣减活动预算、扣减积分等等。每个接口的耗时如果是100ms，那么理论上整个下单的链路就需要耗费400ms，这个时间显然是太长了。

如果这些操作全部同步处理的话，首先调用链路太长影响接口性能，其次分布式事务的问题很难处理，这时候像扣减预算和积分这种对实时一致性要求没有那么高的请求，完全就可以通过mq异步的方式去处理了。同时，考虑到异步带来的不一致的问题，我们可以通过job去重试保证接口调用成功，而且一般公司都会有核对的平台，比如下单成功但是未扣减积分的这种问题可以通过核对作为兜底的处理方案。

使用mq之后我们的链路变简单了，同时异步发送消息我们的整个系统的抗压能力也上升了。

2、你上面提到异步发送，那消息可靠性怎么保证？

生产者发送消息时，由于网络故障或broker的master节点宕机，导致消息丢失。

2. 消息已经发送到RocketMQ了，消息暂存在内存，而后台线程还没有将消息刷到磁盘中，此时服务宕机或存储磁盘故障，导致消息丢失。

3. 消息已经发送到RocketMQ了，但是消费者在消费的时候，还未消费完就返回ack，此时消费者宕机了，但是MQ认为消费成功了，将消费消息offset跳到了下一个消息，此时也相当于出现消息丢失的情况。

解决方案：

场景1：

保证消息不丢失的方案是使用RocketMQ自带的事务机制来发送消息，大致流程为

（1）首先生产者执行事务消息，先发送一个half消息给broker，broker收到后，给事务消息返回成功收到half消息，事务消息监听接口收到broker的成功后，开始执行接口实现类里写的代码

（half message发送成功之后RocketMQ的消费者并不能消费这条消息，因为消息存储在Topic为 RMQ_SYS_TRANS_HALF_TOPIC 的消息消费队列中，而不是原先的Topic）

（2）假如接口实现类里写的是插入数据库代码，数据库插入成功，return 事务执行成（COMMIT）/ 数据库插入失败，return 事务执行失败（ROLLBACK）/ 程序超时响应或未知状态， broker会自动认为事务等待回查（UNKNOWN）

（3）broker在收到事务实现类的返回后，COMMIT时，将事务消费队列的消息复制到指向的topic和queue里（就是在执行了一次正常的发送机制）/ ROLLBACK时，直接将该消息在事务队列里删除 /

UNKNOWN时，根据重试机制调用事务接口实现类，等待返回值，在事务实现类可以获取重试次数，当重试次数超过，记录该消息的数据便于日后手动处理，并返回ROLLBACK删除该消息。

Rocketmq并不会无休止的的信息事务状态回查，默认回查15次，如果15次回查还是无法得知事务状态，rocketmq默认回滚该消息。

场景2：

如果生产者保证消息发送到MQ，而MQ收到消息后还在内存中，这时候宕机了又没来得及同步给从节点，就有可能导致消息丢失。

（1）同步刷盘、异步刷盘

RocketMQ的消息是存储到磁盘上的，这样既能保证断电后恢复，又可以让存储的消息量超出内存的限制。RocketMQ为了提高性能，会尽可能地保证磁盘的顺序写。消息在通过Producer写入RocketMQ的时候，有两种写磁盘方式：

1）异步刷盘方式：在返回写成功状态时，消息可能只是被写入了内存的PAGECACHE，写操作的返回快，吞吐量大；当内存里的消息量积累到一定程度时，统一触发写磁盘操作，快速写入

优点：性能高

缺点：Master宕机，磁盘损坏的情况下，会丢失少量的消息, 导致MQ的消息状态和生产者/消费者的消息状态不一致

2）同步刷盘方式：在返回应用写成功状态前，消息已经被写入磁盘。具体流程是，消息写入内存的PAGECACHE后，立刻通知刷盘线程刷盘，然后等待刷盘完成，刷盘线程执行完成后唤醒等待的线程，给应用返回消息写成功的状态。优点：可以保持MQ的消息状态和生产者/消费者的消息状态一致

缺点：性能比异步的低

同步刷盘还是异步刷盘，是通过Broker配置文件里的flushDiskType参数设置的，这个参数被设置成SYNC_FLUSH, ASYNC_FLUSH中的一个。

（2）同步复制、异步复制

如果一个broker组有Master和Slave，消息需要从Master复制到Slave上，有同步和异步两种复制方式。

1）同步复制方式：等Master和Slave均写成功后才反馈给客户端写成功状态

优点：如果Master出故障，Slave上有全部的备份数据，容易恢复，消费者仍可以从Slave消费, 消息不丢失

缺点：增大数据写入延迟，降低系统吞吐量，性能比异步复制模式略低，大约低10%左右，发送单个Master的响应时间会略高

2）异步复制方式：只要Master写成功即可反馈给客户端写成功状态

优点：系统拥有较低的延迟和较高的吞吐量. Master宕机之后，消费者仍可以从Slave消费，此过程对应用透明，不需要人工干预，性能同多个Master模式几乎一样

缺点：如果Master出了故障，有些数据因为没有被写入Slave，而丢失少量消息。

同步复制和异步复制是通过Broker配置文件里的brokerRole参数进行设置的，这个参数可以被设置成ASYNC_MASTER、SYNC_MASTER、SLAVE三个值中的一个。

总结

消息零丢失是一把双刃剑，要想用好，还是要视具体的业务场景，在性能和消息零丢失上做平衡。实际应用中，推荐把Master和Slave设置成ASYNC_FLUSH的异步刷盘方式，主从之间配置成SYNC_MASTER的同步复制方式，这样即使有一台机器出故障，仍然可以保证数据不丢。

场景3：

消费者消息处理失败原因：

producer发送失败

consumer消费异常

consumer根本就没收到消息

就consumer根本就没收到消息说明：

这个就不得不提到RocketMQ中的一个概念，「消息消费要满足订阅关系一致性，即一个consumerGroup中的所有消费者订阅的topic和tag必须保持一致，不然就会造成消息丢失」。

如下图场景，发送了4条消息，consumer1订阅了topica-taga，而consumer2订阅了topica-tab。consumer1消费q0中的数据，consumer2消费q1中的数据。

投递到q0的msg-1和msg-3只有msg-1能被正常消费，而msg-3则是CONSUMED_BUT_FILTERED。因为msg-3被投递到q0，但是consumer1不消费tagb的消息导致消息被过滤，造成消息丢失。

同理msg-2这条消息也会丢失。

想获取一个 topic下不同的 tag ,需要在消费者配置不同consumerGroup

示例：

3、RocketMQ消费模式有几种？广播模式和集群模式

负载均衡模式：适用场景&注意事项

1.消费端集群化部署，每条消息只需要被处理一次。

2.由于消费进度在服务端维护，可靠性更高。

3.集群消费模式下，每一条消息都只会被分发到一台机器上处理。如果需要被集群下的每一台机器都处理，请使用广播模式。

4.集群消费模式下，不保证每一次失败重投的消息路由到同一台机器上，因此处理消息时不应该做任何确定性假设。

广播模式：适用场景&注意事项

1.每条消息都需要被相同逻辑的多台机器处理。

2.消费进度在客户端维护，出现重复的概率稍大于集群模式。

3.广播模式下，消息队列 RocketMQ 保证每条消息至少被每台客户端消费一次，但是并不会对消费失败的消息进行失败重投，因此业务方需要关注消费失败的情况。

4.广播模式下，客户端每一次重启都会从最新消息消费。客户端在被停止期间发送至服务端的消息将会被自动跳过，请谨慎选择。

5.广播模式下，每条消息都会被大量的客户端重复处理，因此推荐尽可能使用集群模式。

6.目前仅 Java 客户端支持广播模式。

7.广播消费模式下不支持顺序消息。

8.广播消费模式下不支持重置消费位点。

9. 广播模式下服务端不维护消费进度，所以消息队列 RocketMQ 控制台不支持消息堆积查询、消息堆积报警和订阅关系查询功能。

有趣的一点有待认证

当2个消费者订阅同一个 consumerGroup 、topic、tag

第一个消费者设置集群模式，第2个消费者设置广播模式，会出现乱序，2个消费者有时只有一个接收消息，有时2个都会接收消息

4、Name Server

Name Server是RocketMQ的寻址服务。用于把Broker的路由信息做聚合。客户端依靠Name Server决定去获取对应topic的路由信息，从而决定对哪些Broker做连接。

Name Server是一个几乎无状态的结点，Name Server之间采取share-nothing的设计，互不通信。对于一个Name Server集群列表，客户端连接Name Server的时候，只会选择随机连接一个结点，以做到负载均衡。

Name Server所有状态都从Broker上报而来，本身不存储任何状态，所有数据均在内存。如果中途所有Name Server全都挂了，影响到路由信息的更新，不会影响和Broker的通信。

5、Broker

Broker是处理消息存储，转发等处理的服务器。Broker以group分开，每个group只允许一个master，若干个slave。

只有master才能进行写入操作，slave不允许。slave从master中同步数据。同步策略取决于master的配置，可以采用同步双写，异步复制两种。客户端消费可以从master和slave消费。

在默认情况下，消费者都从master消费，在master挂后，客户端由于从Name Server中感知到Broker挂机，就会从slave消费。Broker向所有的NameServer结点建立长连接，注册Topic信息。

6、消息堆积

消息堆积常见于以下几种情况：

（1）新上线的消费者功能有BUG，消息无法被消费。

（2）消费者实例宕机或因网络问题暂时无法同Broker建立连接。

（3）生产者短时间内推送大量消息至Broker，消费者消费能力不足。

（4）生产者未感知Broker消费堆积持续向Broker推送消息。

下游消费系统如果宕机了，导致几百万条消息在消息中间件里积压，此时怎么处理?

你们线上是否遇到过消息积压的生产故障?如果没遇到过，你考虑一下如何应对?

首先要找到是什么原因导致的消息堆积，是Producer太多了，Consumer太少了导致的还是说其他情况，总之先定位问题。然后看下消息消费速度是否正常，正常的话，可以通过上线更多consumer临时解决消息堆积问题。

如果Consumer和Queue不对等，上线了多台也在短时间内无法消费完堆积的消息怎么办？

• 准备一个临时的topic

• queue的数量是堆积的几倍

• queue分布到多Broker中

• 上线一台Consumer做消息的搬运工，把原来Topic中的消息挪到新的Topic里，不做业务逻辑处理，只是挪过去

• 上线N台Consumer同时消费临时Topic中的数据

• 改bug

• 恢复原来的Consumer，继续消费之前的Topic

堆积时间过长消息超时了？

RocketMQ中的消息只会在commitLog被删除的时候才会消失，不会超时。也就是说未被消费的消息不会存在超时删除这情况。

堆积的消息会不会进死信队列？

不会，消息在消费失败后会进入重试队列（%RETRY%+ConsumerGroup），

7、什么是死信队列

当一条消息初次消费失败，消息队列会自动进行消费重试；达到大重试次数后（默认16次），若消费依然失败，则表明消费者在正常情况下无法正确地消费该消息，此时，消息队列不会立刻将消息丢弃，而是将其发送到该消费者对应的特殊队列中；这个队列就是死信队列（Dead-Letter Queue，DLQ），而其中的消息则称为死信消息（Dead-Letter Message，DLM）。

死信队列是用于处理无法被正常消费的消息的

死信队列具有如下特征：

死信队列中的消息不会再被消费者正常消费，即DLQ对于消费者是不可见的

死信存储有效期与正常消息相同，均为 3 天（commitlog文件的过期时间），3 天后会被自动删除

死信队列就是一个特殊的Topic，名称为%DLQ%consumerGroup@consumerGroup，即每个消费者组都有一个死信队列

如果⼀个消费者组未产生死信消息，则不会为其创建相应的死信队列

4.9.3）死信消息的处理

实际上，当⼀条消息进入死信队列，就意味着系统中某些地方出现了问题，从而导致消费者无法正常消费该消息，比如代码中原本就存在Bug。

因此，对于死信消息，通常需要开发人员进行特殊处理；关键的步骤是要排查可疑因素，解决代码中可能存在的Bug，然后再将原来的死信消息再次进行投递消费。

8、多个mq如何选型？

MQ	描述
RabbitMQ	erlang开发，对消息堆积的支持并不好，当大量消息积压的时候，会导致 RabbitMQ 的性能急剧下降。每秒钟可以处理几万到十几万条消息。
RocketMQ	java开发，面向互联网集群化功能丰富，对在线业务的响应时延做了很多的优化，大多数情况下可以做到毫秒级的响应，每秒钟大概能处理几十万条消息。
Kafka	Scala开发，面向日志功能丰富，性能最高。当你的业务场景中，每秒钟消息数量没有那么多的时候，Kafka 的时延反而会比较高。所以，Kafka 不太适合在线业务场景。
ActiveMQ	java开发，简单，稳定，性能不如前面三个。小型系统用也ok，但是不推荐。推荐用互联网主流的。

9、为什么要使用MQ？

因为项目比较大，做了分布式系统，所有远程服务调用请求都是同步执行经常出问题，所以引入了mq

作用	描述
解耦	系统耦合度降低，没有强依赖关系
异步	不需要同步执行的远程调用可以有效提高响应时间
削峰	请求达到峰值后，后端service还可以保持固定消费速率消费，不会被压垮

10、RocketMQ中的Topic和JMS的queue有什么区别？

queue就是来源于数据结构的FIFO队列。而Topic是个抽象的概念，每个Topic底层对应N个queue，而数据也真实存在queue上的。

11、RocketMQ Broker中的消息被消费后会立即删除吗？

不会，每条消息都会持久化到CommitLog中，每个Consumer连接到Broker后会维持消费进度信息，当有消息消费后只是当前Consumer的消费进度（CommitLog的offset）更新了。

12、追问：那么消息会堆积吗？什么时候清理过期消息？

4.6版本默认48小时后会删除不再使用的CommitLog文件

检查这个文件最后访问时间

判断是否大于过期时间

指定时间删除，默认凌晨4点

13、消费消息是push还是pull？

RocketMQ没有真正意义的push，都是pull，虽然有push类，但实际底层实现采用的是长轮询机制，即拉取方式

broker端属性 longPollingEnable 标记是否开启长轮询。默认开启

14、追问：为什么要主动拉取消息而不使用事件监听方式？

事件驱动方式是建立好长连接，由事件（发送数据）的方式来实时推送。

如果broker主动推送消息的话有可能push速度快，消费速度慢的情况，那么就会造成消息在consumer端堆积过多，同时又不能被其他consumer消费的情况。而pull的方式可以根据当前自身情况来pull，不会造成过多的压力而造成瓶颈。所以采取了pull的方式。

15、Broker把自己的信息注册到哪个NameServer上？

这么问明显在坑你，因为Broker会向所有的NameServer上注册自己的信息，而不是某一个，是每一个，全部！

16、高吞吐量下如何优化生产者和消费者的性能?

开发

同一group下，多机部署，并行消费

单个Consumer提高消费线程个数

批量消费

消息批量拉取

业务逻辑批量处理

运维

网卡调优

jvm调优

多线程与cpu调优

Page Cache

17、RocketMQ在分布式事务支持这块机制的底层原理?

RocketMQ很大的一个特点是对分布式事务的支持，你说说他在分布式事务支持这块机制的底层原理?

分布式系统中的事务可以使用TCC（Try、Confirm、Cancel）、2pc来解决分布式系统中的消息原子性

RocketMQ 4.3+提供分布事务功能，通过 RocketMQ 事务消息能达到分布式事务的最终一致

RocketMQ实现方式：

**Half Message：**预处理消息，当broker收到此类消息后，会存储到RMQ_SYS_TRANS_HALF_TOPIC的消息消费队列中

**检查事务状态：**Broker会开启一个定时任务，消费RMQ_SYS_TRANS_HALF_TOPIC队列中的消息，每次执行任务会向消息发送者确认事务执行状态（提交、回滚、未知），如果是未知，Broker会定时去回调在重新检查。

**超时：**如果超过回查次数，默认回滚消息。

也就是他并未真正进入Topic的queue，而是用了临时queue来放所谓的half message，等提交事务后才会真正的将half message转移到topic下的queue。

18、追问：堆积的消息会不会进死信队列？

不会，消息在消费失败后会进入重试队列（%RETRY%+ConsumerGroup），18次（默认18次，网上所有文章都说是16次，无一例外。但是我没搞懂为啥是16次，这不是18个时间吗？）才会进入死信队列（%DLQ%+ConsumerGroup）。

源码如下：


public class MessageStoreConfig {
    // 每隔如下时间会进行重试，到最后一次时间重试失败的话就进入死信队列了。
 private String messageDelayLevel = "1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h";
}

19、Consumer端如何保证消息不丢失

完全消费正常后在进行手动ack确认。

20、如何让RocketMQ保证消息的顺序消费

你们线上业务用消息中间件的时候，是否需要保证消息的顺序性?
如果不需要保证消息顺序，为什么不需要?假如我有一个场景要保证消息的顺序，你们应该如何保证?

首先多个queue只能保证单个queue里的顺序，queue是典型的FIFO，天然顺序。多个queue同时消费是无法绝对保证消息的有序性的。所以总结如下：

同一topic，同一个QUEUE，发消息的时候一个线程去发送消息，消费的时候一个线程去消费一个queue里的消息。

或者使用顺序消费方法发送消息

21、追问：怎么保证消息发到同一个queue？

Rocket MQ给我们提供了MessageQueueSelector接口，可以自己重写里面的接口，实现自己的算法，举个最简单的例子：判断i % 2 == 0，那就都放到queue1里，否则放到queue2里。


for (int i = 0; i < 5; i++) {
    Message message = new Message("orderTopic", ("hello!" + i).getBytes());
    producer.send(
        // 要发的那条消息
        message,
        // queue 选择器 ，向 topic中的哪个queue去写消息
        new MessageQueueSelector() {
            // 手动 选择一个queue
            @Override
            public MessageQueue select(
                // 当前topic 里面包含的所有queue
                List<MessageQueue> mqs,
                // 具体要发的那条消息
                Message msg,
                // 对应到 send（） 里的 args，也就是2000前面的那个0
                Object arg) {
                // 向固定的一个queue里写消息，比如这里就是向第一个queue里写消息
                if (Integer.parseInt(arg.toString()) % 2 == 0) {
                    return mqs.get(0);
                } else {
                    return mqs.get(1);
                }
            }
        },
        // 自定义参数：0
        // 2000代表2000毫秒超时时间
        i, 2000);
}