Rocketmq整体架构

接下来，我们再细说一下RocketMQ的架构
在这里插入图片描述

如上图

整体由4部分组成

namesrv

当broker服务启动后，会向namesrv注册信息，比如broker中的主题、消费偏移量、队列、ip、端口等，由broker的心跳发送到namesrv。

broker cluster中的每一个节点都会注册到namesrv上。

比如你有4个broker节点，2个namesrv，那么注册如下

在这里插入图片描述

这种情况的话，即使一个namesrv节点挂了，剩下的一个namesrv节点仍然包含所有的broker信息。

需要注意的是： namesrv是无状态的， namesrv之间不会相互通信，跟zk是不一样的。一个namesrv挂了，不会影响另外一个namesrv，这俩namesrv是没有关联的。

来南下每个broker的组成吧

在这里插入图片描述

每一个broker节点，储存消息，都会对应一个commitlog , commitlog 负责存储真实的消息的内容。

broker中的每个topic , 如果不设置的话，默认创建4个队列，队列编号 0 ， 1 ，2 ， 3. 每个队列都会对应一个持久化文件。

当producer向broker中的topic发送消息的时候，如果发现队列没有创建持久化文件，会自动创建。然后该队列的持久化信息都会存放在该持久化文件中。

每个broker下面会创建一个consumerOffset.json文件. 这个json文件用来记录当前你消费节点已经消费的数据位置，即消费的偏移量。这个也是需要持久化的。这个偏移量的来源是 consumer 来上报的。（如下图）

在这里插入图片描述

consumer从broker中拉取消息后，要进行消费，消费了多多少消息，要把消费这些对应的这些偏移量上报到broker上去。主要是为了什么呢？ ---->最大可能的避免消息重复的推送。

Q: producer & consumer 到底选择跟哪个broker去连接，去消费哪个broker中的消息？

A: producer & consumer也是无状态的，每一个producer之间，每一个consumer之间都不会通信， 每个producer和consumer内部都有自己的一套负载均衡的算法，默认的选择策略：已发送的消息数量对queuecount取mod .

消费者的两种消费模式主要有两种：推跟拉

拉取式消费（Pull Consumer）：Consumer消费的一种类型，应用通常主动调用Consumer的拉消息方法从Broker服务器拉消息、主动权由应用控制。一旦获取了批量消息，应用就会启动消费过程。
推动式消费（Push Consumer）：Consumer消费的一种类型，该模式下Broker收到数据后会主动推送给消费端，该消费模式一般实时性较高。

pull的方式，由客户端来主动获取，通过定时任务或者需要的时候从broker端获取，这种方式用的比较少。如果消息量比较少，堆积也不会太多，对安全性要求不高的应用，可以考虑。

与此对应的另外一种push方式：

push的方式，在RocketMQ中其实也是基于pull模式的一个深度封装，consumer对broker进行一个长轮询，一直监听broker中的数据，就好像是broker主动推送给consumer似的。