持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第22天，点击查看活动详情
面试官：RocketMQ的broker原理了解过吗？
为了保证MQ的数据不丢失而且具备一定的高可用性，一般都是将broker部署成Master-Slave模式的。Slave也会向所有的NameServer进行注册并且发送心跳。
RocketMQ的Master-Slave模式采取的是Slave不停的发送请求到Master去拉取消息的方式。
面试官：RocketMQ实现读写分离了吗？
Master主要是接收系统写入的消息。
作为消费者，在获取消息进行消费时，有可能从Master获取消息，也有可能从Slave获取消息。
消费者在获取消息时会先发送请求到Master，请求获取一批消息，此时Master是会返回一批消息给消费者的，并且会根据当前Master的负载情况和Slave的同步情况，向消费者系统建议下一次拉取消息时是从Master拉取还是从Slave拉取。
面试官：如果Slave broker挂了有什么影响？
有一点影响，但是影响不大。因为写入消息全部都是发送给Master的，然后获取消息也可以走Master，只不过有一些消息获取是从Slave走的。
此时如果Slave挂了，无论发送消息还是获取消息都是可以走Master的，对整体运行不影响，但此时读写压力都集中在Master上。
面试官：如果Master broker挂了怎么办？
这个时候对消息的写入和获取都有一定的影响了。但本质上而言，Slave也是跟Master一样有一份备份数据的，只不过Slave上的数据可能有部分没来得及从Master上拉取。
在RocketMQ4.5之前Master故障了，Slave是不能自动切换成为Master的，需要手动做运维操作。所以这种Master-Slave模式不是彻底的高可用模式，他没法实现自动把Slave切换成Master。
RocketMQ高可用自动切换
在RocketMQ4.5之后，支持了一种新的机制，叫Dledger。把Dledger融入RocketMQ之后，就可以让一个Master对应多个Slave，一份数据可以有多个备份。
此时一旦Master宕机了，就可以在多个Slave之中，通过Dledger技术和Raft协议算法进行leader选举，直接将一个Slave选举成为一个新的Master，这个新的Master继续对外提供服务。
broker跟NameServer通信
在RocketMQ的实现中，采用的是TCP长连接进行通信。
broker会跟每一个NameServer都建立一个TCP长连接，然后定时通过TCP长连接发送心跳请求过去。
核心数据模型
面试官：Topic到底是什么？
生产者和消费者都会向MQ中写入或获取消息，MQ中的核心数据模型就是Topic。他表达的意思就是一个数据集合。Topic作为一个数据集合在RocketMQ集群中是分布式存储的。
生产者在发送消息之前，得先有一个Topic，在发送消息时需要指定发送到哪个Topic里面去。NameServer的路由信息中包括：集群里有哪些broker，有哪些Topic，每个Topic都存储在哪些broker上。
然后生产者系统可以通过路由信息找到自己投递消息的topic分布在哪些broker上，此时可以根据负载均衡算法从里面选择一台broker机器出来建立一个TCP长连接，通过长连接向broker发送消息即可。
要注意的一点是，生产者一定是投递消息到Master broker的，然后Master会同步数据到Slave。消费者系统消费消息与生产者系统原理是类似的，也要与broker建立长连接。
