yrl's blog
0%

rocketmq 常见面试题

发表于 分类于 ， ，

为什么要使用MQ？

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

解耦：系统耦合度降低，没有强依赖关系

异步：不需要同步执行的远程调用可以有效提高响应时间

削峰：请求达到峰值后，后端service还可以保持固定消费速率消费，不会被压垮

多个mq如何选型？

RabbitMQ：erlang开发，延迟比较低

RocketMQ：java开发，面向互联网集群化功能丰富

kafka：Scala开发，面向日志功能丰富

ActiveMQ：java开发，简单，稳定

小项目：ActiveMQ

大项目：RocketMQ或kafka、RabbitMq

RocketMQ中的Topic和ActiveMQ有什么区别？

ActiveMQ 

1
2
3
4
5
6
有destination的概念，即消息目的地
destination分为两类：
- topic
  - 广播消息
- queue
  - 队列消息

RocketMQ

1
2
RocketMQ的Topic是一组Message Queue的集合=>对应在多个brokert的ConsumeQueue逻辑文件
一条消息是广播消息还是队列消息由客户端消费决定

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

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

消息会堆积吗？什么时候清理过期消息？

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

  • 检查这个文件最后访问时间
  • 判断是否大于过期时间
  • 指定时间删除，默认凌晨4点

rocketMq的消息堆积如何处理

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

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

具体表现为 ui中转圈圈

对于大规模消息发送接收可以使用pull模式，手动处理消息拉取速度,消费的时候统计消费时间以供参考

保证消息消费速度固定，即可通过上线更多consumer临时解决消息堆积问题

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

RocketMQ中的消息只会在commitLog被删除的时候才会消失，不会超时

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

不会，消息在消费失败后会进入重试队列（%RETRY%+consumergroup），多次（默认16）才会进入死信队列（%DLQ%+consumergroup）

RocketMQ消费模式有几种？

消费模型由consumer决定，消费维度为Topic

集群消费

一组consumer同时消费一个topic，可以分配消费负载均衡策略分配consumer对应消费topic下的哪些queue

多个group同时消费一个topic时，每个group都会消费到数据

一条消息只会被一个group中的consumer消费，

广播消费

消息将对一 个Consumer Group 下的各个 Consumer 实例都消费一遍。即即使这些 Consumer 属于同一个Consumer Group ，消息也会被 Consumer Group 中的每个 Consumer 都消费一次。

消费消息时使用的是push还是pull？

在刚开始的时候就要决定使用哪种方式消费

两种：

DefaultLitePullConsumerImpl 拉

DefaultMQPushConsumerImpl推

两个实现 DefaultLitePullConsumerImpl DefaultMQPushConsumerImpl都实现了MQConsumerInner接口接口

名称上看起来是一个推，一个拉，但实际底层实现都是采用的长轮询机制，即拉取方式

DefaultMQPushConsumerImpl帮我们定义好了拉取数据的规则；DefaultMQPullConsumerImpl需要我们自己定义拉取规则

broker端属性 longPollingEnable 标记是否开启长轮询。可以配置hold住的时间长短，默认true为5s，false则为1s

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

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

如果broker主动推送消息的话有可能push速度快，消费速度慢的情况，那么就会造成消息在consumer端堆积过多，同时又不能被其他consumer消费的情况，如果改由consumer主动拉取的方式，则主动权在客户端，可以根据实际消费能力进行消费。

broker如何处理拉取请求的？

consumer首次请求broker

  • broker中是否有符合条件的消息
  • 有 ->
    • 响应consumer
    • 等待下次consumer的请求
  • 没有
    • 挂起consumer的请求，即不断开连接，也不返回数据
    • 挂起时间长短，写死在代码里的吗？长轮询写死，短轮询可以配
    • 使用consumer的offset，
      • DefaultMessageStore#ReputMessageService#run方法
        • 每隔1ms检查commitLog中是否有新消息，有的话写入到pullRequestTable
        • 当有新消息的时候返回请求
      • PullRequestHoldService 来Hold连接，每个5s执行一次检查pullRequestTable有没有消息，有的话立即推送

消息丢失

producer在发送同步/异步可靠消息后，会接收到SendResult，表示消息发送成功

SendResult其中属性sendStatus表示了broker是否真正完成了消息存储

当sendStatus!=”ok”的时候，应该重新发送消息，避免丢失

当producer.setRetryAnotherBrokerWhenNotStoreOK

消息重复消费

引起重复消费的原因

ACK(网络的不确定性)

1
2
3
正常情况下在consumer真正消费完消息后应该发送ack，通知broker该消息已正常消费，从queue中剔除

当ack因为网络原因无法发送到broker，broker会认为词条消息没有被消费，此后会开启消息重投机制把消息再次投递到consumer

group

1
2
3
在CLUSTERING模式下，消息在broker中会保证相同group的consumer消费一次，但是针对不同group的consumer会推送多次

也可能是因为consumer首次启动引起重复消费：需要设置`consumer.setConsumeFromWhere`，只对一个新的consumeGroup第一次启动时有效,设置从头消费还是从维护开始消费

解决方案

数据库表：处理消息前，使用消息主键在表中带有约束的字段中insert

Map：单机时可以使用map ConcurrentHashMap -> putIfAbsent guava cache

Redis：使用主键或set操作

RocketMQ如何保证消息不丢失

  1. 生产端如何保证投递出去的消息不丢失：消息在半路丢失，或者在MQ内存中宕机导致丢失，此时你如何基于MQ的功能保证消息不要丢失？

  2. MQ自身如何保证消息不丢失？

  3. 消费端如何保证消费到的消息不丢失：如果你处理到一半消费端宕机，导致消息丢失，此时怎么办？

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

你们线上业务用消息中间件的时候，是否需要保证消息的顺序性?

如果不需要保证消息顺序，为什么不需要?假如我有一个场景要保证消息的顺序，你们应该如何保证?

  • 同一topic

  • 同一个QUEUE

  • 发消息的时候一个线程去发送消息

  • 消费的时候 一个线程 消费一个queue里的消息或者使用MessageListenerOrderly

  • 多个queue 只能保证单个queue里的顺序

RocketMQ 是如何保证数据的高容错性的?

  • 在不开启容错的情况下，轮询队列进行发送，如果失败了，重试的时候过滤失败的Broker
  • 如果开启了容错策略，会通过RocketMQ的预测机制来预测一个Broker是否可用
  • 如果上次失败的Broker可用那么还是会选择该Broker的队列
  • 如果上述情况失败，则随机选择一个进行发送
  • 在发送消息的时候会记录一下调用的时间与是否报错，根据该时间去预测broker的可用时间