1、RocketMQ是如何集群化部署来承载高并发访问的？
- 让NameServer集群化部署，部署在三台机器上，NameServer的设计是采用的Peer-to-Peer的模式来做的，也就是可以集群化部署，但是里面任何一台机器都是独立运行的，跟其他的机器没有任何通信。每台NameServer实际上都会有完整的集群路由信息，包括所有的Broker节点信息，我们的数据息。所以只要任何一台NameServer存活下来，就可以保证MQ系统正常运行，不会出现故障。
2.基于Dledger的Broker主从架构部署,Dledger技术是要求至少得是一个Master带两个Slave，这样有三个Broke组成一个Group，也就是作为一个分组来运行。一旦Master宕机，他就可以从剩余的两个Slave中选举出来一个新的Master对外提供服务
2、如果RocketMQ要存储海量的消息，如何实现分布式存储架构？
每台机器上部署的RocketMQ进程一般称之为Broker，每个Broker都会收到不同的消息，然后就会把这批消息存储在自己本地的磁盘文件里
3、高可用保障：万一Broker宕机了怎么办？
RocketMQ的解决思路是Broker主从架构以及多副本策略。
4、数据路由：怎么知道访问哪个Broker？
NameServer是独立部署在几台机器上的，然后所有的Broker都会把自己注册到NameServer上去，要负责去管理集群里所有Broker的信息
5、是发送消息的时候面对N多台机器，到底应该向哪一台上面的Broker发送过去
6、RocketMQ的数据模型是什么，我们发送消息过去的时候，是发送到什么里面去，队列还是什么？
7、RocketMQ接收到数据之后是直接写磁盘吗，那性能会不会太差了
8、如到底是Broker主动推送消息给消费者？还是消费者自己从Broke里拉取消息？
9、NameServer是可以集群化部署的
10、Broker是把自己的信息注册到哪个NameServer上去？
- 每个Broker启动都得向所有的NameServer进行注册
11、系统如何从NameServer获取Broker信息？
12、如果Broker挂了，NameServer是怎么感知到的？
- 靠的是Broker跟NameServer之间的心跳机制，Broker会每隔30s给所有的NameServer发送心跳，告诉每个NameServer自己目前还活着
13、然后NameServer会每隔10s运行一个任务，去检查一下各个Broker的最近一次心跳时间，如果某个Broker超过120s都没发送心跳了，那么就认为这个Broker已经挂掉了
14、Broker挂了，系统是怎么感知到的？
时突然挂了一个Broker，120s没发心跳给NameServer，NameServer是知道现在只有9个Broker了，但是此时其他系统是不知道只有9个Broker的，还以为有10个Broker，此时可能某个系统就会发送消息到那个已经挂掉的Broker上去，此时是绝对不可能成功发送消息的
- 首先，你可以考虑不发送消息到那台Broker，改成发到其他Broker上去。
- 假设你必须要发送消息给那台Broker，那么他挂了，他的Slave机器是一个备份，可以继续使用，你是不是可以考虑等一会儿去跟他的Slave进行通信？
15、kafka的路由中心
- Kafka的路由中心实际上是一个非常复杂、混乱的存在。他是由ZooKeeper以及某个作为Controller的Broker共同完成的。
16、NameServer集群整体都故障了，RocketMQ还能正常运行吗
17、Master Broker是如何将消息同步给Slave Broker的？
- Slave Broker发送请求到Master Broker去拉取
18、如果Master Broker挂掉了该怎么办？
在RocketMQ 4.5版本之前，都是用Slave Broker同步数据，尽量保证数据不丢失，但是一旦Master故障了，Slave是没法自动切换成Master的。
19、基于Dledger实现RocketMQ高可用自动切换
Dledger是基于Raft协议实现的一个机制
Master Broker宕机了，就可以在多个副本，也就是多个Slave中，通过Dledger技术和Raft协议算法进行leader选举，直接将一个Slave Broker选举为新的Master Broker，然后这个新的Master Broker就可以对外提供服务了
