Apache RocketMQ，由阿里开发并开源给Apache组织，具有高性能、高吞吐量的分布式消息中间件。《淘宝技术这十年》所描述，阿里对于消息中间件的研发和升级过程经历了一段很长的历：
2005年开始，由于阿里业务扩张和业务量的飙升，加之之后支付宝从淘宝剥离出来后，各个系统之间面临着消息通知的即时性、重复性、可靠性等方面的问题。起初，选用MQ（Message Queue）来解决这些问题，但MQ面对大量消息时，表现出消息堵塞、顺序混乱、系统宕机等方面的问题。在这种情况下，阿里研发了真正意义上的第一代消息中间件Notify。
Notify架构图如下：
NotifyServer在ConfigServer上负责注册消息服务，消息客户端通过ConfigServer订阅消息服务，某客户端发送消息至NotifyServer，NotifyServer负责将消息发送到所有订阅的客户端。为了保证消息发送接收的可靠性，消息存储在数据库中。在整体架构中，NotifyClient、NotifyServer以及数据库都可以进行水平扩展，理论上讲，这套架构的消息中间件可以支持很高的吞吐量。
Notify之后，随着业务的发展，技术的演进，有开发了Napoli。Notify和Napoli都是基于推模型，采用关系型数据库作为存储。
2011年，阿里将消息中间件升级为MetaQ，MetaQ是一款完全的队列模型消息中间件，服务器使用Java语言编写， 具备跨平台特性，客户端支持Java、C++语言，根据官方Wiki介绍：
MetaQ架构图如下：
MetaQ对外提供的是一个队列服务，内部实现也是完全的队列模型，这里的队列是持久化的磁盘队列，具有非常高的可靠性，并且充分利用了操作系统cache来提高性能。
· 是一个队列模型的消息中间件，具有高性能、高可靠、高实时、分布式特点。
· Producer、Consumer、队列都可以分布式。
· Producer向一些队列轮流发送消息，队列集合称为Topic，Consumer如果做广播消费，则一个consumer实例消费这个Topic对应的所有队列，如果做集群消费，则多个Consumer实例平均消费这个topic对应的队列集合。
· 能够保证严格的消息顺序
· 提供丰富的消息拉取模式
· 高效的订阅者水平扩展能力
· 实时的消息订阅机制
· 亿级消息堆积能力
2012年，开始研发RocketMQ，在第一代推模型和第二代拉模型的经验上，RocketMQ基于长轮询拉取方式，兼有前两代优点。
RocketMQ架构图：
RocketMQ基本概念请参照https://github.com/apache/rocketmq/blob/master/docs/cn/concept.md
RocketMQ架构设计请参照https://github.com/apache/rocketmq/blob/master/docs/cn/architecture.md
根据如上架构图，在整个架构中，包含以下角色：
· Producer：消息生产者，支持分布式集群部署。
· Consumer：消息消费者，支持分布式集群部署。
· NameServer：Topic路由注册中心，支持Broker动态注册于发现。主要包括两个功能：Broker管理和路由信息管理。
· Broker管理：NameServer接受Broker集群的注册信息并且保存下来作为路由信息的基本数据。然后提供心跳检测机制，检查Broker是否还存活。
· 路由信息管理：每个NameServer将保存关于Broker集群的整个路由信息和用于客户端查询的队列信息。
· BrokerServer：负责消息存储、投递和查询以及服务高可用保证。其中，BrokerServer为了实现这些功能，包含负责处理clients请求的Remoting Module、负责客户端管理和Topic维护的Client Manager、负责消息持久化和查询的Store Service、提供主从节点同步的HA Service、提供消息的快速查询的Index Service。