本文主要是介绍RocketMQ第5集，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
一 RocketMQ的工作流程
1.1 生产环节producer
Producer可以将消息写入到某Broker中的某Queue中：其中Producer发送消息之前，会先向NameServer发出获取消息Topic的路由信息的请求，NameServer返回该Topic的路由表及Broker列表。简单的说：路由表的key为Topic名称，value则为所有涉及该Topic的BrokerName列表。
1.2 MQ的存储
RocketMQ中的消息存储在本地文件系统中，这些相关文件默认在当前用户主目录下的store目录中。
abort：该文件在Broker启动后会自动创建，正常关闭Broker，该文件会自动消失。若在没有启动Broker的情况下，发现这个文件是存在的，则说明之前Broker的关闭是非正常关闭。
1.2.1 mq的commitlog
commitlog目录中存放着很多的mappedFile文件，当前Broker中的所有消息都是落盘到这些mappedFile文件中的。需要注意的是，一个Broker中仅包含一个commitlog目录，所有的mappedFile文件都是存放在该目录中的。
mappedFile文件是顺序读写的文件，所有其访问效率很高。
1.2.2 mq的consumequeue
consumequeue文件是commitlog的索引文件，可以根据consumequeue定位到具体的消息，consumequeue文件名也由20位数字构成，表示当前文件的第一个索引条目的起始位移偏移量
1.2.3 mq的存储读写流程
1.3 rocketmq与kafka性能比较*
首先，RocketMQ对文件的读写操作是通过mmap零拷贝进行的，将对文件的操作转化为直接对内存地址进行操作，从而极大地提高了文件的读写效率。
其次，consumequeue中的数据是顺序存放的，还引入了PageCache的预读取机制，使得对consumequeue文件的读取几乎接近于内存读取，即使在有消息堆积情况下也不会影响性能。
RocketMQ中的commitlog目录与consumequeue的结合就类似于Kafka中的partition分区目录。 mappedFile文件就类似于Kafka中的segment段。
Kafka中消息存放的目录结构是：topic目录下有partition目录，partition目录下有segment文件。
Kafka中无需索引文件。因为生产者是将消息直接写在了partition中的，消费者也是直接从partition中读取数据的。
1.4 rocketmq的消费方式
消费者从Broker中获取消息的方式有两种：pull拉取方式和push推动方式。消费者组对于消息消费的模式又分为两种：集群消费Clustering和广播消费Broadcasting。
Pull拉取方式：
由于拉取时间间隔是由用户指定的，主动权自己掌控。所以在设置该间隔时需要注意平稳：间隔太短，空请求比例会增加；间隔太长，消息的实时性太差
Push方式：
该模式下Broker收到数据后会主动推送给Consumer。该获取方式一般实时性较高。而这些都是基于Consumer与Broker间的长连接的。长连接的维护是需要消耗系统资源的。
集群消费模式下，相同Consumer Group的每个Consumer实例平均分摊同一个Topic的消息。即每条消息只会被发送到Consumer Group中的某个Consumer。
这篇关于RocketMQ第5集的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
