比较深入的了解RockerMQ的架构原理
对上图进行简单的说明
基于Dledger的Broker主从架构部署
RocketMQ的4.5版本之前如果master故障，是无法自动将slave切换成master的，必须得人工介入，修改配置然后重启。4.5版本之后，引入Dledger技术之后可以实现自动切换。Dledger技术是要求必须得是一个Master带两个slave，这样三个Broker组成一个Group，也就是一个分组来运行，一旦Master宕机，它就可以从剩余的两个slave中选举出一个新的master对外提供服务。
Broker是如何跟NameServer进行通信的
Broker和NameServer之间的通信协议是基于TCP长连接进行通信的。也就是说，Broker会跟每个NameServer都建立一个TCP的长连接，然后定时通过TCP长连接发送心跳请求过去。
RockerMQ的核心数据模型是什么
它的核心数据模型是：topic，它表达的意思就是数据集合的意思。
Topic是如何在Broker集群中存储的。
topic里面的数据是分布式存储的。比如在创建topic的时候是可以指定它里面的数据分散存储在多台Broker机器上的。比如一个topic里有1000万数据，此时有2台Broker，那么就可以让每台Broker上都放500万数据。另外一个重要的事情就是，每个Broker在进行定时的心跳汇报给NameServer的时候，都会告诉NameServer自己当前的数据情况，比如都有哪些topic的那些数据在自己这里，这样每个NameServer就都知道了集群中 的Broker都存放了哪些topic的数据了。
生产者是如何将消息发送给Broker的
生产者会向NameServer拉取路由信息，找到自己要发送信息的topic是在那台机器上，此时根据负载均衡算法，从里面选择一台Broker机器出来，比如采用round robine轮询算法，或者hash算法等。这里需要注意的就是，生产者一定是发送信息给Master Broker的，然后Master Broker再同步数据给它的Slave Brokers，实现一分数据多分副本。
消费者是如何从Broker上拉取消息的
消费者系统其实和生产者类似的，它们也会和Nameserver建立长连接，然后拉取路由信息，接着找到自己要获取消息的topic在那几台Broker上，就可以和Broker建立长连接，从里面拉取消息了。这里需要注意的一点就是，消费者系统可能会从Master Broker拉取消息，也可能会从Slave Broker拉取消息，都有可能，会根据当时Master Broker节点的负载情况和slave的数据同步情况，再从master broker拉取消息的时候，master broker会返回下次该去哪里拉取消息的建议，是该继续从master上拉取还是从slave上拉取。