架构师（JiaGouX）我们都是架构师！架构未来，你来不来？1.RocketMQ的发展历史在年的时候，淘宝实施了“五彩石”项目，“五彩石”用于将交易系统从单机变成分布式，也是在这个过程中产生了阿里巴巴第一代消息引擎——Notify。在年的时候，阿里巴巴BB部门基于ActiveMQ的5.1版本也开发了自己的一款消息引擎，称为Napoli，这款消息引擎在BB里面广泛地被使用，不仅仅是在交易领域，在很多的后台异步解耦等方面也得到了广泛的应用。在年的时候，业界出现了现在被很多大数据领域所推崇的Kafka消息引擎，阿里在研究了Kafka的整体机制和架构设计之后，基于Kafka的设计使用Java进行了完全重写并推出了MetaQ1.0版本，主要是用于解决顺序消息和海量堆积的问题。而在01年，阿里对于MetaQ进行了架构重组升级，开发出了MetaQ.0，这时就发现MetaQ原本基于Kafka的架构在阿里巴巴如此庞大的体系下很难进行水平扩展，所以在01年的时候就开发了RocketMQ.0版本。很多人会问到RocketMQ.0和MetaQ.0的区别，其实这两者是等价的版本，只不过阿里内部使用的称为MetaQ.0，外部开源称之为RocketMQ.0。在年，又基于RocketMQ开发了阿里云上的AliwareMQ和Notify.0。在年的时候，阿里巴巴将RocketMQ的内核引擎捐赠给了Apache基金会。以上就是RocketMQ的整体发展历史，其实在阿里巴巴内部围绕着RocketMQ内核打造了三款产品，分别是MetaQ、Notify和AliwareMQ。这三者分别采用了不同的模型，MetaQ主要使用了拉模型，解决了顺序消息和海量堆积问题；Notify主要使用了推模型，解决了事务消息；而云产品AliwareMQ则是提供了商业化的版本。如图：
下图是RocketMQ在历年双11的消息流转体量：
单位：十亿
.RocketMQ的原理和架构
RocketMQ消息队列的整体部署架构如下图所示：
RocketMQ消息队列集群中的几个角色：
NameServer：
命名发现服务，更新和路由发现broker；
其在RocketMQ中起着中转承接的作用，是一个无状态的服务，多个NameServer之间不通信。
Broker-Master：
broker消息主机服务器。
Broker-Slave：
broker消息从机服务器。
Producer：
消息生产者。
Consumer：
消息消费者。
RocketMQ集群的一部分通信如下：
Broker启动后需要完成一次将自己注册至NameServer的操作；
随后每隔0s时间定期向NameServer上报Topic路由信息；
消息生产者Producer作为客户端发送消息时候，需要根据Msg的Topic从本地缓存的TopicPublishInfoTable获取路由信息。
如果没有则更新路由信息会从NameServer上重新拉取；
消息生产者Producer根据所获取的路由信息选择一个队列（MessageQueue）进行消息发送；
Broker作为消息的接收者接收消息并落盘存储。
从上面可以看出在消息生产者，在Broker和NameServer间都会发生通信（这里只说了MQ的部分通信），因此如何设计一个良好的网络通信模块在MQ中至关重要，它将决定RocketMQ集群整体的消息传输能力与最终性能。
rocketmq-remoting模块是RocketMQ消息队列中负责网络通信的模块，它几乎被其他所有需要网络通信的模块（诸如rocketmq-client、rocketmq-broker、rocketmq-namesrv）所依赖和引用。
为了实现客户端与服务器之间高效的数据请求与接收，RocketMQ消息队列自定义了通信协议并在Netty的基础之上扩展了通信模块。
鉴于RocketMQ通信模块的底层源码是Netty实现的，在阅读RocketMQ的源码之前，建议读者先对Netty的多线程模型、JAVANIO模型均有一定的了解，以便快速理解RocketMQ源码。
1.源码目录结构介绍
本文使用的RocketMQ版本是4.4.0,依赖的netty版本是4.0.4.Final.请参考：Netty基本原理
RocketMQ的代码结构图如下：
RocketMQ源码主要分为以下几个package：
rocketmq-broker：mq的核心，它能接收producer和consumer的请求，并调用store层服务对消息进行处理。HA服务的基本单元，支持同步双写，异步双写等模式。
rocketmq-client：mq客户端实现，目前官方仅仅开源了java版本的mq客户端，c++，go客户端有社区开源贡献。
rocketmq-
