带你一起一步步推理出RocketMQ的架构

消息队列（MQ）主要是为了解决系统之间的通信。

我们平时开发的业务系统基本都会使用数据库，而MQ内部比数据库简单，从而性能也比数据库要高的多，将消息发送到消息队列很快，从而MQ可以在系统之间起到缓冲的作用。

Producer

使用MQ肯定需要向MQ发送消息，RocketMQ中的 Producer 就是承担了消息发送的职责。

我们的业务系统使用Producer API来发送消息。消息发送到哪呢？发送到我们下面要说的Broker。

Broker

Broker负责接收从生产者发送来的消息并存储、同时为消费者的拉取请求作准备。

Consumer

有人生产消息，必然会有人来消费消息，承担消费消息角色的就是Consumer，从哪消费呢？当然是Broker，消息是发送到Broker上呢！

我们的业务系统使用Consumer API 从Broker获取消息，业务系统根据获取的消息来执行业务逻辑。

Producer的消息并不是直接发送给Consumer的，而是发送给MQ，然后Consumer从MQ中来消费消息。这里的MQ准确的说就是Broker，负责消息的存储等工作。

此时我们脑海中应该建立了下面这幅图

Broker Cluster

上面的模型很简单，但在有些情况下会存在问题，比如有很多Producer高并发向Broker发送大量的消息，此时Boker就会面临高并发的压力、消息存储的压力（磁盘存满）。

如何解决高并发压力和存储压力的问题？大家平时做开发时肯定使用过MySQL，MySQL是如何应对这两个问题的呢？答案就是读写分离、分库分表。

RocketMQ也是采用同样的思路， RocketMQ就是通过扩展Broker数量来应对并发和存储压力的。

使用称为Slave角色的Broker来应对读并发，使用称为Master角色的Broker来应对写并发（注：Master Broker也可以读）压力，同时Master会将消息同步给Slave。这样，Master和Slave上就会有相同的消息。

即Master可读写、Slave只读，见下图

采用上述的模型，通过扩展Slave Broker来提升RocketMQ的读并发。

但此时还会存在问题，我们可以不断的扩展Slave数量来提升读并发，但写消息却只能在Master上写，一个Master无法应对高并发写。同时Slave都从Master上同步数据，这样Master不仅承担了Consumer的读，还需要应对Slave的读，显然Master是个瓶颈。

此时有同学会问，为什么不让Slave也可以写呢？这样的所有的Broker都可读可写，让读写的压力均匀的分配到所有的Broker上。

其实也不是不可以，设计本来就是取舍，只是通用的做法还是通过扩展Master数量来解决写压力，扩展Slave数量来解决读压力，见下图

现在有多个 Master-Slave ，Producer可以将消息写到不同的 Master 上，多个Master共同承担了写消息和存消息的压力

而Consumer也可以从更多个Master-Slave 上来消费消息。如果Master的压力还是很大，我们可以继续增加Master-Slave

高并发读写、大数据量存储的问题是不是都可以通过Master-Slave 集群解决了。

此时又有了新的问题，集群中有多个Master、多个Slave，那么Produce向哪个Master Broker 发送消息？地址是什么？Consumer从哪个Broker来消费消息呢？地址是什么？

此时我们就需要对Broker进行管理，RocketMQ中使用NameServer 来承担这个角色，接下来我们看看NameServer

NameServer

NameServer说白了就是用来保存所有Broker相关信息的组件。

所有的Broker向NamerServer注册自己的消息，然后所有的Producer和Consumer从NameServer获取Broker的信息，有了Broker的信息就可以与之进行通信了。

系统中仅仅有一个NameServer有什么问题？单点故障问题，即唯一的NameServer挂了，新的Producer、Consumer从哪里获取Broker的信息来进行通信呢？所以NameServer应该部署多台

目前为止，我们经过一步步推理，对RocketMQ的架构有了简单的认识， 但心里可能很多关于RocketMQ细节性的疑问，后续我们会逐步深入讲解这些细节问题，一步步剖析RocketMQ的内部原理。