文章目录
Rocketmq整体架构
RocketMQ-初体验RocketMQ(01)_RocketMQ初体验中 对 RocketMQ 架构图做了一个大体的介绍
接下来，我们再细说一下RocketMQ的架构
如上图
整体由4部分组成
- namesrv
- broker
- producer
- consumer
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的组成吧
每一个broker节点 ，储存消息，都会对应一个commitlog , commitlog 负责存储真实的消息的内容。
broker中的每个topic , 如果不设置的话， 默认创建4个队列， 队列编号 0 ， 1 ，2 ， 3. 每个队列都会对应一个持久化文件 。
当producer向broker中的topic发送消息的时候， 如果发现队列没有创建持久化文件，会自动创建。 然后该队列的持久化信息都会存放在该持久化文件中。
每个broker下面会创建一个consumerOffset.json文件. 这个json文件用来记录当前你消费节点已经消费的数据位置，即消费的偏移量。这个也是需要持久化的。 这个偏移量的来源 是 consumer 来上报的。（如下图）
consumer从broker中拉取消息后，要进行消费，消费了多多少消息，要把消费这些对应的这些偏移量上报到broker上去。 主要是为了什么呢？ ---->最大可能的避免消息重复的推送。
producer & consumer
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似的。
通信方式
producer/consumer broker namesrv 通信方式
producer/consumer 给 broker发送消息/消费消息，或者从 namesrv拉取消息 ， 通信是基于netty的方式，优先选用epoll方式，如果操作系统不支持epoll的话，会选择NIO。