RocketMQ面试题

1.MQ如何集群化部署来支撑高并发访问?

RocketMQ单机可以支撑10万+的并发访问，集群部署可以让流量分散在多台机器上来支撑高并发。

2.MQ如果要存储海量消息应该怎么做？

MQ会收到大量的消息，并不是立马就会被所有的消费方获取过去消费的，所以一般MQ都得把消息在自己本地磁盘存储起来，然后等待消费方获取消息去处理。
本质上RocketMQ存储海量消息的机制就是分布式的存储。所谓分布式存储，就是把数据分散在多台机器上来存储，每台机器存储一部分消息，这样多台机器加起来就可以存储海量消息了

3.如何保证高可用，万一Broker宕机了怎么办？

Broker主从架构以及多副本策略，Master Broker收到消息之后会同步给Slave Broker，这样Slave Broker上就能有一模一样的一份副本数据。即使Master出现故障，还有Slave上有一份数据副本，可以保证数据不丢失，继续对外提供服务，保证了MQ的可靠性和高可用性。

4.数据路由：怎么知道访问哪个Broker？

RocketMQ为了解决这个问题，有一个NameServer的概念，他也是独立部署在几台机器上的，然后所有的Broker都会把自己注册到NameServer上去，对于系统而言，如果他要发送消息到Broker，会找NameServer去获取路由信息，就是集群里有哪些Broker等信息.如果系统要从Broker获取消息，也会找NameServer获取路由信息，去找到对应的Broker获取消息。

5.NameServer如何实现高可用？

NameServer支持部署多台机器的，起到高可用的效果，保证任何一台机器宕机，其他机器上的NameServer可以继续对外提供服务。

6.Broker是把自己的信息注册到哪个NameServer上去？

每个Broker启动都得向所有的NameServer进行注册也就是说，每个NameServer都会有一份集群中所有Broker的信息。

7.系统如何从NameServer获取Broker信息？

系统自己每隔一段时间，定时发送请求到NameServer去拉取最新的集群Broker信息。

8.Broker挂了，NameServer是怎么感知到的？

在RocketMQ的实现中，采用的是TCP长连接进行通信。Broker会跟每个NameServer都建立一个TCP长连接，然后定时通过TCP长连接发送心跳请求过去靠的是Broker跟NameServer之间的心跳机制，Broker会每隔30s给所有的NameServer发送心跳，告诉每个NameServer自己目前还活着。每次NameServer收到一个Broker的心跳，就可以更新一下他的最近一次心跳的时间。然后NameServer会每隔10s运行一个任务，去检查一下各个Broker的最近一次心跳时间，如果某个Broker超过120s都没发送心跳了，那么就认为这个Broker已经挂掉了。

9.Broker挂了，系统是怎么感知到的？

如果Broker挂掉了，那么作为生产者和消费者的系统是怎么感知到的呢？有两种解决办法。
首先，你可以考虑不发送消息到那台Broker，改成发到其他Broker上去。
其次，假设你必须要发送消息给那台Broker，那么他挂了，他的Slave机器是一个备份，可以继续使用，可以考虑等一会儿去跟他的Slave进行通信。
总之，这些都是思路，但是现在我们先知道，对于生产者而言，他是有一套容错机制的，即使一下子没感知到某个Broker挂了，他可以有别的方案去应对。而且过一会儿，系统又会重新从NameServer拉取最新的路由信息了，此时就会知道有一个Broker已经宕机了。

10.Master Broker是如何将消息同步给Slave Broker的？

RocketMQ的Master-Slave模式采取的是Slave Broker不停的发送请求到Master Broker去拉取消息。Pull模式拉取消息

11.RocketMQ 实现读写分离了吗？

Master Broker主要是接收系统的消息写入，然后会同步给Slave Broker，那么其实本质上Slave Broker也应该有一份一样的数据。而系统在获取消息的时候，有可能从Master Broker获取消息，也有可能从Slave Broker获取消息。

12.Slave Broke和Master Broker挂掉了有什么影响？

Slave Broke挂掉有一点影响，但是影响不太大
因为消息写入全部是发送到Master Broker的，然后消息获取也可以走Master Broker，只不过有一些消息获取可能是从Slave Broker去走的。所以如果Slave Broker挂了，那么此时无论消息写入还是消息拉取，还是可以继续从Master Broke去走，对整体运行不影响。
只不过少了Slave Broker，会导致所有读写压力都集中在Master Broker上。

Master Broker挂掉对消息的写入和获取都有一定的影响了。但是其实本质上而言，Slave Broker也是跟Master Broker一样有一份数据在的，只不过Slave Broker上的数据可能有部分没来得及从Master Broker同步。

13.Broker是如何跟NameServer进行通信的？

在RocketMQ的实现中，采用的是TCP长连接进行通信。
也就是说，Broker会跟每个NameServer都建立一个TCP长连接，然后定时通过TCP长连接发送心跳请求过去

14.什么是Topic？Topic作为一个数据集合是怎么在Broker集群里存储的？

MQ中的核心数据模型Topic，表达的意思就是一个数据集合的意思。我们可以在创建Topic的时候指定让他里面的数据分散存储在多台Broker机器上，比如一个Topic里有1000万条数据，此时有2台Broker，那么就可以让每台Broker上都放500万条数据。这样就可以把一个Topic代表的数据集合分布式存储在多台机器上了。

15.生产者系统是如何将消息发送给Broker的？消费者是如何从Broker上拉取消息的？

发送消息之前需要先有一个Topic，然后在发送消息的时候指定要发送到哪个Topic。既然已经知道要发送的Topic，那么就可以跟NameServer建立一个TCP长连接，然后定时从他那里拉取到最新的路由信息，包括集群里有哪些Broker，集群里有哪些Topic，每个Topic都存储在哪些Broker上。然后生产者系统自然就可以通过路由信息找到自己要投递消息的Topic分布在哪几台Broker上，此时可以根据负载均衡算法，从里面选择一台Broke机器出来，比如round robine轮询算法，或者是hash算法。
注意:生产者一定是投递消息到Master Broker的，然后Master Broker会同步数据给他的Slave Brokers，实现一份数据多份副本，保证Master故障的时候数据不丢失，而且可以自动把Slave切换为Master提供服务。

消费者系统其实跟生产者系统原理是类似的，他们也会跟NameServer建立长连接，然后拉取路由信息，接着找到自己要获取消息的Topic在哪几台Broker上，就可以跟Broker建立长连接，从里面拉取消息