1. 总体架构
RocketMQ通过主从架构和多副本机制来实现高可用和支撑高并发。Broker有Master和Slave两种角色。一个Master可能有多个Slave。
同时还有一个NameServer集群来保存Broker的路由信息，每个Broker都会向NameServer注册，然后每隔30秒发送一个心跳包保持和NameServer的通信。
不管是生产者还是消费者，如果想要从RocketMQ中获取消息，都要通过NameServer获取路由信息，再去找到对应的Broker获取消息。
SlaveBroker会不停的发请求到MasterBroker拉取消息进行同步。
2. RocketMQ的读写分离
写入消息是在MasterBroker上进行的，然后同步给SlaveBroker。但是消费者获取消息的时候一般先从Master上获取，然后Master根据本身的负载情况判断是否要告诉消费者下一次从Slave获取。如果消费者从Slave上获取消息时，Slave发现自己的消息滞后很多，会告诉消费者下次从Master获取。所以RocketMQ的读写是一个动态变化的过程，写操作是一定发生在Master上，读操作两者都可能发生。
3. 高可用
理论上讲，SlaveBroker宕机了不会有什么影响。MasterBroker宕机的话，RocketMQ 4.5版本之前需要人工运维从Slave中选择一个切换MasterBroker。4.5之后通过Dledger来实现选主操作，实际上就是基于Raft算法自动从Slave中选择一个作为新的MasterBroker。
4. 分布式存储
RocketMQ的每个topic的消息都可以分散存储在多台MasterBroker上。这里的分散存储并不是相同数据，和Slave的副本保存不一样。例如某个topic有1000w条消息，那么它们可能分成了4份保存到了4个不同的MasterBroker上，每个Master中保存250w条消息。这些Master的Slave会另外对其做副本保存操作。
实际上在创建topic的时候，我们会指定它对应的MessageQueue的大小。例如上面的例子，一开始设置了MessageQueue的个数为4，那么1000w条数据可能会分散保存在这4个不同的MessageQueue中，可能并不是平均分配。而这4个MessageQueue其实也是分散在不同的MasterBroker上的。如下图：
THE END.
