简介
近年来，淘宝天猫“双十一”活动影响了整个中国互联网电商的发展，在“双十一”的背后，有一系列开放平台技术的使用来保障电商平台的在高峰流量下正常运行。而消息中间件RocketMQ就是其中一个重要的技术。RocketMQ是阿里推出的一款开源的消息中间件。其前身是MetaQ （Metamorphosis），它并不遵循任何规范（如JMS,AMQP等），但是参考了各种规范与同类产品的设计思想，但其主要借鉴的产品是Apache Kafka。
就特性来说，RocketMQ主要具有以下几个特点：
l 能够保证严格的消息顺序
l 提供推/拉两种消息模式
l 高效的订阅者水平扩展能力
l 实时的消息订阅机制
l 亿级消息堆积能力
RocketMQ经历了三个主要版本迭代
- Metaq（Metamorphosis） 1.x
由开源社区killme2008（庄晓丹）维护，最后一次MetaQ的更新时间为2013年。 - Metaq 2.x
于2012 年10 月份上线，在淘宝内部被广泛使用。 - RocketMQ 3.x
基于阿里巴巴公司内部开源共建原则，RocketMQ项目只维护核心功能，且去除了所有其他运行时依赖，核心功能最简化。每个产品的个性化需求都在RocketMQ项目之上进行深度定制。
RocketMQ目前在GitHub上的版本更新较慢，但是阿里对外提供了消息中间件的云服务，并已正式商业运行。目前来说，GitHub上的RocketMQ并没有主备自动切换，事务等方面的功能。
一、RocketMQ部署架构介绍
RocketMQ使用Name Server集群加Broker集群的方式来搭建。
RocketMQ需要部署Name Server（名称服务器），Name Server是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。
Broker（消息服务器）部署相对复杂，Broker分为Master与Slave，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master。
每个Broker与Name Server集群中的所有节点建立长连接，定时注册Topic信息到所有Name Server。
Producer与Name Server集群中的其中一个节点（随机选择）建立长连接，定期从Name Server取Topic（消息的主题，也是消息的目的地）路由信息，并向提供Topic服务的Master建立长连接，且定时向Master发送心跳。Producer完全无状态，可集群部署。
Consumer与Name Server集群中的其中一个节点（随机选择）建立长连接，定期从Name Server取Topic路由信息，并向提供Topic服务的Master、Slave建立长连接，且定时向Master、Slave发送心跳。Consumer既可以从Master订阅消息，也可以从Slave订阅消息，订阅规则由Broker配置决定。
二、消息生命周期介绍
对于任意一个消息中间件来说，消息都需要经过消息生产->消息存储->消息消费三个过程。其中消息生产包括了Producer端的消息构造和消息发送，消息存储包括了Broker端的消息接收和消息落地，消息消费包括了Consumer端的消息接收和消息处理。不同消息中间件之所以功能不同，性能差异较大，其主要原因就是消息生命周期中各个阶段的处理方式不同。在此简要介绍一下RocketMQ在各个阶段的处理方式。
l 消息生产
消息的生产者Producer在发送消息时，会从Name Server上获取消息的目的地（Topic）在各个Broker上的状态，如果发现同一个Broker下的Topic有多个Queue（队列），则会根据RoundBin算法依次向每个Queue发送消息，此外，如果发现多个Broker上均有相同Topic，也会依照轮询的方式依次向这些Broker发送消息。
l 消息存储
RocketMQ的消息存储是由consume queue和commit log配合完成的。
consume queue是消息的逻辑队列，相当于字典的目录，用于指定消息在物理文件commit log中的位置。每一个queue都有一个对应的consume queue文件。consume queue中存放的是一串20字节定长的二进制数据，顺序写顺序读。
Commit Log是消息存放的物理文件，每台Broker上的Commit Log被本机所有的queue共享，不做任何区分。CommitLog中消息存储单元长度不固定，文件顺序写，随机读。
简而言之，Broker端在收到一条消息后，如果是消息需要落盘，则会在Commit Log中写入整条消息，并在consume queue中写入该消息的索引信息。消息被消费时，则根据consume queue中的信息去Commit Log中获取消息。RocketMQ在消息被消费后，并不会去Commit Log中删除消息，而是会保存3天（可配置）而后批量删除。
RocketMQ支持同步刷盘及异步刷盘两种模式，同步刷盘指的是Producer将消息发送至Broker后，等待消息刷入Commit Log和consume queue后才算消息发送成功，而异步刷盘则是将消息发送至Broker后，Broker将消息放入内存则告知Producer消息发送成功，而后由Broker自行将内存中的消息批量刷入磁盘。
l 消息消费
RocketMQ消息订阅有两种模式，一种是Push模式，即Broker主动向消费端推送；另外一种是Pull模式，即消费端在需要时，主动到Broker拉取。但在具体实现时，Push和Pull模式都是采用消费端主动拉取的方式。
Consumer端每隔一段时间主动向broker发送拉消息请求，broker在收到Pull请求后，如果有消息就立即返回数据，Consumer端收到返回的消息后，再回调消费者设置的Listener方法。如果broker在收到Pull请求时，消息队列里没有数据，broker端会阻塞请求直到有数据传递或超时才返回。
与Kafka类似，Kafka中Consumer数量不能大于Partition数量，而在RocketMQ中Consumer的数量也不能大于队列（Queue）的数量，如果Consumer超过队列数量，那么多余的Consumer将不能消费消息。可以简单理解为queue与consumer的关系是多对一的关系。
分析
我们基于公司网络，搭建了RocketMQ的环境进行测试。由于RocketMQ分为同步刷盘和异步刷盘两种模式。不同的模式对性能的影响是巨大的，故我们考虑分别对同步刷盘和异步刷盘两种模式进行测试。本次测试设置2万条4K字节的消息为一组，测试10组（20万条消息），然后取平均值。搭建的服务器为SuseLinux 11 SP4，4C8G。
案例一：1生产者发送2W条4K字节消息，异步刷盘
TPS: 1204.964454
案例二：1生产者发送2W条4K字节消息，同步刷盘
TPS: 181.9604418
可以看到，同步刷盘和异步刷盘，对性能的影响几乎是10倍计。
此外，在测试中发现，单个生产者的线程数量对消息的生产速度也有很大的影响。
同样的，也可以得到异步刷盘模式下TPS与线程数量的关系，可以看到，在线程数达到16个以后，再增加线程数，对TPS的提升也不大，可以判断此时其他因素影响了TPS的提升。
而对于消息的消费来说，由于RocketMQ会将消息在内存中保存一份，因此消息的消费并不受是否持久化影响。如果是及时消费，那么消息的消费速度是极快的。
案例三：1消费者消费2W条4K字节消息
TPS: 17825.31194
从性能方面来看，消息的生产速度低于消息的消费速度，这可以基本保证不会出现消息堆积的场景。且如果出现了消息堆积，RocketMQ由于其消息的存储架构，也不会像其他MQ一样出现消息堵塞的问题。
而从RocketMQ的原理及部署架构来看，其主要适用的场景为分布式系统下海量消息的消峰填谷，由于其部署架构包含了NameServer和Broker两种形式，因此对于较小的分布式系统来说，搭建和运维并不方便。
建议
相比业界比较成熟的MQ来说，RocketMQ由于是阿里部分开源的产品，其成熟度及社区活跃度不如Kafka，ActiveMQ，RabbitMQ等业界主流消息中间件。但是由于RocketMQ采用Java实现（Kafka使用scala语言），其主要功能的源码可以进行二次开发进行改造。因此若公司需要掌握一门开源中间件的技术，对RocketMQ进行深入研究是有价值的。
综合来看，RocketMQ有优点也有缺点，建议：
1、对于小规模的分布式系统之间需要用到消息中间件的场景，可以仍然采用IBM MQ或ActiveMQ等部署运维较为简单的开源消息中间件来实现。
2、对于大型的分布式系统，可以考虑使用RocketMQ进行数据交互，但由于RocketMQ目前的开源版本不支持主备自动切换，因此在高可用方面需要进行深入的研究，必要时需要进行二次开发。
3、RocketMQ就性能来说，强于ActiveMQ，就可读性及消息交互功能来说，强于Kafka，实际业务可根据具体需要进行选型。
4、后续可继续深入研究RocketMQ，并总结出各关键技术（如消息的存储，集群设计，主备复制等）和设计思路，丰富技术储备。