RocketMQ面试题及答案

1.多个MQ如何选型?

RabbitMQ：erlang开发，对消息堆积的支持并不好，当大量消息积压的时候，会导致RabbitMq的性能急剧下降，每秒可以处理几万到几十万条消息。

RocketMQ：java开发，面向互联网集群化，功能丰富，对在线业务的响应延迟做了很多优化，大多数情况下可以做到毫秒级的响应，每秒钟大概能处理几十万条消息。

kafka：scala开发，面向日志，功能丰富，性能最高，当你的业务中，每秒钟消息数量没那么多的时候，Kafka的时延反而会比较高，所以kafka不太适合在线业务场景。

ActiveMQ：java开发，简单，稳定，性能不如其他的，小型系统用也可以，但不推荐使用。

2.为什么要使用MQ?

解耦：降低系统之间的耦合度。
异步。
流量削峰：请求达到峰值后，后端service开可以用固定消费速率消费，不会被压垮。

3.RockerMQ有哪些角色组成?

nameServer：无状态，动态列表。
producer：消息生产者，负责发送消息到broker。
broker：就是MQ本身，负责收发消息，持久化消息等。
consumer：消息消费者，负责从broker上拉取消息进行消费，消费完进行ack。

4.MQ的工作流程?

1.启动nameServer，nameServer启动后开始监听端口，等待Broker Producer，Consumer连接。

2.启动Broker时，Broker会与所有nameServer建立并保持长连接，然后每30秒向nameServer定时发送心跳包

3.发送消息前，可以先创建Topic，创建Topic时需要指定该Topic要存储在哪些Broker上，当然，在创建Topic时也会将Topic与Broker的关系写入到NameServer中，不过这步时可选的，也可以在发送消息时自动创建topic。

4.Produce发送消息，启动共时先跟nameServer集群中的其中一台建立长连接，并从nameServer中获取路由信息，即当前发送的Topic消息的queue与broleer的地址的映射关系，然后根据算法策略从队列选择一个queue，与队列所在的Broker建立长连接，从而向broker发送消息，当然，在获取到路由信息后，producer会首先将路由信息缓存到本地，再每30秒从nameServer更新一次路由信息。

5.Consumer跟Producer类似，跟其中一台NameServer建立连接，获取其所订阅Topic的路由信息，然后根据算法策略从路由信息中获取到其所要消费的Queue，然后直接跟broker建立长连接，开始消费其中的消息，Consumer在获取到路由信息后，同样也会每30秒从nameService更新一次路由信息，不过不同与producer的是，Consumer还会向broker发送心跳，以确保broker的存活状态。

5.RocketMQ Broker中的消息被拉取后会立即删除吗?

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

6.消息会堆积吗?什么时候清理过期的消息?

如果消息出现堆积可能有三种情况:
1.消息的生产者生产消息过快。
2.broker发生了阻塞。
3.消息的消费者消费消息过慢。

4.6版本默认48小时后会删除，不再使用commitLog文件
检查这个文件的最后访问时间
判断是否大于过期时间
指定删除时间，默认凌晨4点

7.RockerMQ有几种消费模式?

集群消费：一条消息指挥被同group的一个consumer消费，多个group同时消费一个topic时，每个group都会有一个consumer消费到数据。

广播消费：消息将对一个consumer group下的各个consumer实例都消费一遍。

8.消费消息是push 还是 pull?

RockerMQ没有真正意义上的push，都是pull，虽然有push类，但实际上底层实现采用的都是长轮询机制。

9.为什么要主动要拉取消息, 而不是使用事件监听方式?

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

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

10.消息会重复消费吗?

引起重复消费的原因有两个：
ACK问题：正常情况下再consumer真正消费完消息后应该发送ack通知broker该消息已经正常消费，从queue中剔除，当ack因为网络原因无法发送到broker，broker会认为该消息没有被消费，此后会开启消息重推机制把消息再次投递到consumer。
消费模式：在clustering模式下，消息在broker中会保证相同group的consumer消费一次，但是针对不同的group的consumer会推送多次。

解决方案就是采用唯一标识，防止消费重复数据。

11.如何让RockerMQ的消息保证顺序消费?

queue时典型的FIFO，天然顺序，多个queue同时消费时无法绝对保证消息的有序性，所以同一个topic，同一个queue 发消息的时候，一个线程去发送消息，消费的时候一个线程去消费一个queue里的消息。

12.怎么保证消息发送到同一个queue上?

rocket mq给我们提供了一个messageQueueSelector接口，可以自己重写里面的接口，实现自己的算法。

13.RockerMQ如何保证消息不丢失?

producer端：可以采取send() 同步发消息，发送结果时同步感知的，发送失败后可以重试，设置重试次数，默认3次。

broker端：可以将刷盘策略改为同步刷盘，默认情况下时异步刷盘。 consumer端：完全消费正常后在进行手动ack确认。

14.RocketMQ消息堆积如何处理?

首先要找到消息堆积的原因，是producer太多，还是consumer太少，还是消息消费速度异常，正常的话，可以上线更多的consumer临时解决消息堆积问题。

15.消息堆积时间长, 消息会超时吗?

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

16.堆积的消息会不会进私信队列?

不会，消息在消费失败后进入重试队列，默认重试16次，16次之后才会进入死信队列。

17.高吞吐量下如何优化生产者和消费者?

同一个group下，多机部署，并行消费 单个consumer提高消费线程个数。 批量消费。

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

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

19.任何一台broker突然宕机了怎么办?

broker主从架构以及多副本策略，master收到消息后，会同步给slave，这样一条消息就不止一份了。master宕机了还有slave中的消息可用，保证了mq的可靠性和高可用性。

20.Broker把自己的信息注册到哪个namerserver上?

broker会向所有的nameServer注册自己的信息

21.为什么自己写nameserver而不用ZK呢?

1.nameServer是自己写的，方便扩展去中心化，只要有一个nameServer在 ，整个注册中心环境就可以使用。
2.Zookeeper选举需要满足过半机制才可以使用。