I.下载解压并且启动
cd C:\DingSai\Tools\RocketMQ\alibaba-rocketmq\bin
start/b mqnamesrv.exe &C:\DingSai\Tools\RocketMQ\alibaba-rocketmq\bin\mp_log.log
II.mq启动broker&
cd C:\DingSai\Tools\RocketMQ\alibaba-rocketmq\bin
start/b mqbroker.exe -n &127.0.0.1:9876&&C:\DingSai\Tools\RocketMQ\alibaba-rocketmq\bin\mq_log_mqbroker.log
可以通过jps查看一下是不是有了RocketMQ的进程，如下方的6484&
C:\Users\houchangren&jps -v &
II.mq关闭&
&查看端口号占用
& & &netstat -aon|findstr &9876&
taskkill -f -t -im mqnamesrv.exe
package com.yirendai.datacenter.
import com.alibaba.rocketmq.client.exception.MQClientE
import com.alibaba.rocketmq.client.producer.DefaultMQP
import com.alibaba.rocketmq.client.producer.SendR
import com.mon.message.M
import java.util.concurrent.TimeU
* Created by user on .
public class MiaoShaMQProducerTest {
public static void main(String[] args) throws MQClientException,
InterruptedException{
* 一个应用创建一个Producer，由应用来维护此对象，可以设置为全局对象或者单例&br&
* 注意：ProducerGroupName需要由应用来保证唯一&br&
* ProducerGroup这个概念发送普通的消息时，作用不大，但是发送分布式事务消息时，比较关键，
* 因为服务器会回查这个Group下的任意一个Producer
final DefaultMQProducer producer = new DefaultMQProducer(&ProducerGroupName&);
producer.setNamesrvAddr(&127.0.0.1:9876&);
producer.setInstanceName(&Producer&);
* Producer对象在使用之前必须要调用start初始化，初始化一次即可&br&
* 注意：切记不可以在每次发送消息时，都调用start方法
producer.start();
* 下面这段代码表明一个Producer对象可以发送多个topic，多个tag的消息。
* 注意：send方法是同步调用，只要不抛异常就标识成功。但是发送成功也可会有多种状态，&br&
* 例如消息写入Master成功，但是Slave不成功，这种情况消息属于成功，但是对于个别应用如果对消息可靠性要求极高，&br&
* 需要对这种情况做处理。另外，消息可能会存在发送失败的情况，失败重试由应用来处理。
for (int i = 0; i & 10; i++){
Message msg = new Message(&TopicTest1&,// topic
&TagA&,// tag
&OrderID001&,// key
(&Hello MetaQA&+i).getBytes());// body
SendResult sendResult = producer.send(msg);
System.out.println(sendResult);
Message msg = new Message(&TopicTest2&,// topic
&TagB&,// tag
&OrderID0034&,// key
(&Hello MetaQB&+i).getBytes());// body
SendResult sendResult = producer.send(msg);
System.out.println(sendResult);
Message msg = new Message(&TopicTest3&,// topic
&TagC&,// tag
&OrderID061&,// key
(&Hello MetaQC&+i).getBytes());// body
SendResult sendResult = producer.send(msg);
System.out.println(sendResult);
}catch(Exception e) {
e.printStackTrace();
TimeUnit.MILLISECONDS.sleep(1000);
* 应用退出时，要调用shutdown来清理资源，关闭网络连接，从MetaQ服务器上注销自己
* 注意：我们建议应用在JBOSS、Tomcat等容器的退出钩子里调用shutdown方法
producer.shutdown();
Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() {
public void run() {
producer.shutdown();
System.exit(0);
package com.yirendai.datacenter.
import com.alibaba.rocketmq.client.consumer.DefaultMQPushC
import com.alibaba.rocketmq.client.consumer.listener.ConsumeConcurrentlyC
import com.alibaba.rocketmq.client.consumer.listener.ConsumeConcurrentlyS
import com.alibaba.rocketmq.client.consumer.listener.MessageListenerC
import com.alibaba.rocketmq.client.exception.MQClientE
import com.mon.message.MessageE
import java.util.L
* Created by user on .
public class MiaoShaMQConsumerTest {
* 当前例子是PushConsumer用法，使用方式给用户感觉是消息从RocketMQ服务器推到了应用客户端。&br&
* 但是实际PushConsumer内部是使用长轮询Pull方式从MetaQ服务器拉消息，然后再回调用户Listener方法&br&
public static void main(String[] args) throws InterruptedException,
MQClientException {
* 一个应用创建一个Consumer，由应用来维护此对象，可以设置为全局对象或者单例&br&
* 注意：ConsumerGroupName需要由应用来保证唯一
DefaultMQPushConsumer consumer = new DefaultMQPushConsumer(
&ConsumerGroupName&);
consumer.setNamesrvAddr(&127.0.0.1:9876&);
consumer.setInstanceName(&Consumber&);
* 订阅指定topic下tags分别等于TagA或TagC或TagD
consumer.subscribe(&TopicTest1&,&TagA || TagC || TagD&);
* 订阅指定topic下所有消息&br&
* 注意：一个consumer对象可以订阅多个topic
consumer.subscribe(&TopicTest2&,&*&);
consumer.subscribe(&TopicTest3&,&*&);
consumer.registerMessageListener(new MessageListenerConcurrently() {
public ConsumeConcurrentlyStatus consumeMessage(
List&MessageExt& msgs, ConsumeConcurrentlyContext context) {
System.out.println(Thread.currentThread().getName()
+& Receive New Messages: & + msgs.size());
MessageExt msg = msgs.get(0);
if(msg.getTopic().equals(&TopicTest1&)) {
//执行TopicTest1的消费逻辑
if(msg.getTags() != null && msg.getTags().equals(&TagA&)) {
//执行TagA的消费
System.out.println(&TopicTest1:TagA&+new String(msg.getBody()));
}else if (msg.getTags() != null
&&msg.getTags().equals(&TagC&)) {
//执行TagC的消费
System.out.println(&TopicTest1:TagC&+new String(msg.getBody()));
}else if (msg.getTags() != null
&&msg.getTags().equals(&TagD&)) {
//执行TagD的消费
System.out.println(&TopicTest1:TagD&+new String(msg.getBody()));
}else if (msg.getTopic().equals(&TopicTest2&)) {
System.out.println(&TopicTest2:&+new String(msg.getBody()));
}else if (msg.getTopic().equals(&TopicTest3&)) {
System.out.println(&丁赛新增TopicTest3:&+new String(msg.getBody()));
return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
* Consumer对象在使用之前必须要调用start初始化，初始化一次即可&br&
consumer.start();
System.out.println(&ConsumerStarted.&);
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：198393次
积分：3379
积分：3379
排名：第10212名
原创：146篇
转载：16篇
评论：22条
(1)(1)(17)(14)(14)(8)(1)(2)(1)(1)(1)(1)(2)(4)(8)(26)(22)(9)(4)(8)(12)(1)(1)(1)(1)(1)(1)Kafka vs RocketMQ ——消息及时性对比
在前几期的消息中间件对比中，我们为Kafka和RocketMQ设定了几个性能场景（单机系统可靠性、多Topic对性能稳定性的影响以及Topic数量对单机性能的影响），这些场景大都是以服务端的吞吐能力为对比焦点。这一期，我们将从客户端的角度出发，为大家带来Kafka和RocketMQ消息及时性
在前几期的消息中间件对比中，我们为Kafka和RocketMQ设定了几个性能场景（单机系统可靠性、多Topic对性能稳定性的影响以及Topic数量对单机性能的影响），这些场景大都是以服务端的吞吐能力为对比焦点。这一期，我们将从客户端的角度出发，为大家带来Kafka和RocketMQ消息及时性的对比。
何谓消息及时性?
消息及时性是指对于一条消息来说，从消息发送到消息中间件这一时刻起，到最终到达消费端所消耗的总时间。
是不是有点抽象？我们来看个物流公司配送的例子，便于理解：
卖家把货物投递给物流公司就不再关心这笔交易了，但买家此时却更希望早点收到货品，这时就到了物流公司之间比拼运送能力的时候了，如果用飞机，买家就幸福了，而轮船呢，就只能默默等待了。这个过程里买家所等待的时间，就是一次物流的整体耗时，因此我说：整体耗时越短，及时性就越好，反之，及时性就是越差
通过上面的解释明白此次试验的目的了吧，就是对于同样数量的消息，Kafka和RocketMQ哪一个会用更短的时间处理完，以减少业务等待的时间
在消息同步收发的情况下，Kafka和RocketMQ各自发送并处理200万条128字节大小的消息，测算消息中间件从消息生产者发送第一条消息到消费者处理完最后一条消息所消耗的时间，对不同并发数下的Kafka和RocketMQ的消息及时性进行对比。
测试过程中，Kafka和RocketMQ均使用相同的测试环境和客户端逻辑,接收端每接收2条消息，产生1ms的时间延迟来模拟消费端的处理耗时，消息队列数均设置为8，分别记录Kafka和RocketMQ在不同的发端并发数下，从生产者发送第一条消息到消费者接收到第200W条消息的耗时.
测试数据如下：
我们可以看到，当发送端的并发数小的时候，Kafka和RocketMQ的接收端速度都能与之持平，Kafka表现稍好，随着发送端并发数的增加，消息处理量增大，Kafka对于发送端消息的存储能力强于RocketMQ，但是把消息投递给消费端的能力非常弱，导致消息处理的时间几乎是RocketMQ的两倍，此时RocketMQ的消息及时性远胜Kafka。
在测试过程中，Kafka就好像是一个仓库无穷大的物流公司，货物入仓库很快，但是配送多用轮船和汽车，送货速度很慢，比如（某达速运，某通速运）。RocketMQ则像是一个仓库容量有界限的物流公司，货物入库的速度是一定的，但是配送多用飞机和汽车，送货很快（比如某丰速运）
如果公司的业务量非常小，一天中几乎不存在高峰的时段，那么Kafka或RocketMQ都可以。而当消息的处理数量上升后，Kafka累积消息的能力强于RocketMQ，但是把消息投递给消费的能力大幅下降，导致消耗过多的时间（Kafka要133秒，RocketMQ要65秒）。在消息及时性这个场景，RocketMQ完胜Kafka
服务端为单机部署，机器配置如下：
RocketMQ在这场消息及时性测试中表现优异，原因一点不奇怪，RocketMQ的索引机制起到了关键作用。消息类的对比测试也并未结束，我们会陆续加入新的评测场景，敬请期待！
本文为云栖社区原创内容，未经允许不得转载，如需转载请发送邮件至yqeditor@list.；如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件至：yqgroup@ 进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容。
用云栖社区APP，舒服~
【云栖快讯】浅析混合云和跨地域网络构建实践，分享高性能负载均衡设计，9月21日阿里云专家和你说说网络那些事儿，足不出户看直播，赶紧预约吧！&&
kafka的消费端怎么模拟的？kafka也是批量消费的，是不是有比两个2个消息就停1ms更好的模拟策略？把消费者放到kafka/RocketMQ集群外试试看。
测试中消费策略是模拟了实际订阅者处理耗时的。把消费者放到kafka/RocketMQ集群外这个不知道怎么理解？
嗯，我可能没有说清楚。我的怀疑点是订阅者会影响测试结果，如 1. 订阅者和kafka在同一台机器，可能会抢CPU资源；2,kafka的订阅者如果一次能读取尽量多的数据，可能也对影响处理速度。
首先，客户端和服务端并非部署在一台机器。其次，同样的消费处理逻辑，Kafka的客户端处理慢。当消息处理慢导致服务端消息堆积到磁盘的时候，因为RocketMQ多一层索引结构，消息的捞取投递速度也肯定比Kafka更优的。
kafka的消费者配置对消息投递影响很大；个人见解：业务场景模拟保持一致，但是针对性的配置优化，才能真正的一较高低！
请问你接收端用了多少并发接收
消息消费用的推模式还是拉模式
感觉这个测试数据并未反应真实情况，kafka的消费是顺序读，rmq是随机读，kafka消费应该更快，楼主说RocketMQ的索引机制起到了关键作用，这个恰恰是RocketMQ应该消费得更慢的原因
消息队列（Message Queue，简称MQ）是阿里云商用的专业消息中间件，是企业级互联网架构的核心产品，基于...
阿里云消息服务（Message Service，原MQS）是阿里云商用的消息中间件服务。与传统的消息中间件不同，...
基于大数据的移动云服务。帮助App快速集成移动推送的功能，在实现高效、精确、实时的移动推送的同时，极大地降低了开...
为您提供简单高效、处理能力可弹性伸缩的计算服务，帮助您快速构建更稳定、安全的应用，提升运维效率，降低 IT 成本...
Loading...http://rocketmq.apache.org/
这些年开源氛围越来越好，各大IT公司都纷纷将一些自研代码开源出来。2012年，阿里巴巴开源其自研的第三代分布式消息中间件——RocketMQ。经过几年的技术打磨，阿里称基于RocketMQ技术，目前双十一当天消息容量可达到万亿级。
2016年11月，阿里将RocketMQ捐献给Apache软件基金会，正式成为孵化项目。阿里称会将其打造成顶级项目。这是阿里迈出的一大步，因为加入到开源软件基金会需要经过评审方的考核与观察。坦率而言，业界还对国人的代码开源参与度仍保持着刻板印象；而Apache基金会中的342个项目中，暂时还只有Kylin、CarbonData、Eagle 和 RocketMQ 共计四个中国技术人主导的项目。
日，RocketMQ正式发布4.0版本，专家称新版本适用于电商领域，金融领域，大数据领域，兼有物联网领域的编程模型。
RocketMQ项目，究竟用怎样的技术内涵？缘何赢得了基金会的初步认可？入驻基金会可以给技术圈哪些启示？InfoQ带着这样的疑问对两位项目联合创始人进行了专访，内容整理如下。
受访者简介
王小瑞，花名誓嘉，阿里巴巴中间件消息团队负责人，具有丰富的高可用，高可靠分布式系统构建经验，主导了阿里巴巴多次双十一消息引擎的改进优化项目，拥有多项分布式领域的专利。Apache RocketMQ联合创始人。联系方式: vintagewang@apache.org
冯嘉，花名鼬神，阿里巴巴中间件架构师，具有丰富的分布式软件架构、高并发网站设计、性能调优经验，拥有多项分布式领域的专利。开源爱好者，专注分布式、大数据领域，关注Hbase/Hadoop/Spark/Flink等大数据技术栈。目前负责阿里消息中间件生态输出、云上商业化，Apache RocketMQ联合创始人。联系方式: vongosling@apache.org
RocketMQ的由来
谈起RocketMQ的亮点，那不得不先提一下阿里巴巴消息引擎的演进史。阿里中间件消息引擎发展到今日，前前后后经历了三代演进。
第一代，推模式，数据存储采用关系型数据库。在这种模式下，消息具有很低的延迟特性，并且很容易支持分布式事务。尤其在阿里淘宝这种高频交易场景中，具有非常广泛地应用。典型代表包括Notify、Napoli。
第二代，拉模式，自研的专有消息存储。在日志处理方面能够媲美Kafka的吞吐性能，但考虑到淘宝的应用场景，尤其是其交易链路的高可靠需求，消息引擎并没有一味的追求吞吐，而是将稳定可靠放在首位。因为采用了长连接拉模式，在消息的实时方面丝毫不逊推模式。典型代表MetaQ。
第三代，以拉模式为主，兼有推模式的高性能、低延迟消息引擎RocketMQ，在二代功能特性的基础上，为电商金融领域添加了可靠重试、基于文件存储的分布式事务等特性，并做了大量优化。从2012年开始，经历了历次双11核心交易链路检验。目前已经捐赠给Apache基金会。时至今日，RocketMQ很好的服务了阿里集团大大小小上千个应用，在双11当天，更有不可思议的万亿级消息流转，为集团大中台的稳定发挥了举足轻重的作用。
不难看出，RocketMQ其实是伴随着阿里巴巴整个生态的成长，逐渐衍生出来的高性能、低延迟能够同时满足电商领域和金融领域的极尽苛刻场景的消息中间件。
RocketMQ的技术概览
&&在我们看来，它最大的创新点在于能够通过精巧的横向、纵向扩展，不断满足与日俱增的海量消息在高吞吐、高可靠、低延迟方面的要求。
目前RocketMQ主要由NameServer、Broker、Producer以及Consumer四部分构成，如下图所示。
所有的集群都具有水平扩展能力，无单点障碍。
NameServer以轻量级的方式提供服务发现和路由功能，每个NameServer存有全量的路由信息，提供对等的读写服务，支持快速扩缩容。
Broker负责消息存储，以Topic为纬度支持轻量级的队列，单机可以支撑上万队列规模，支持消息推拉模型，具备多副本容错机制（2副本或3副本）、强大的削峰填谷以及上亿级消息堆积能力，同时可严格保证消息的有序性。除此之外，Broker还提供了同城异地容灾能力，丰富的Metrics统计以及告警机制。这些都是传统消息系统无法比拟的。
Producer由用户进行分布式部署，消息由Producer通过多种负载均衡模式发送到Broker集群，发送低延时，支持快速失败。
Consumer也由用户部署，支持PUSH和PULL两种消费模式，支持集群消费和广播消息，提供实时的消息订阅机制，满足大多数消费场景。&&&&
经历双11洗礼的英雄
在备战2016年双十一时，团队重点做了两件事情，优化慢请求与统一存储引擎。
优化慢请求：这里主要是解决在海量高并发场景下降低慢请求对整个集群带来的抖动，毛刺问题。这是一个极具挑战的技术活，团队同学经过长达1个多月的跟进调优，从双十一的复盘情况来看，99.996%的延迟落在了10ms以内，而99.6%的延迟在1ms以内。优化主要集中在RocketMQ存储层算法优化、JVM与操作系统调优。更多的细节大家可以参考我们之前写的电子书章节《万亿级数据洪峰下的分布式消息引擎》[1]。
再来看看统一存储引擎：主要解决的消息引擎的高可用，成本问题。在多代消息引擎共存的前提下，我们对Notify的存储模块进行了全面移植与替换。
这样下来，阿里巴巴内部的消息中间件就全面拥抱了RocketMQ的低延迟存储引擎。基于上述积极的技术准备，在16年双十一期间，阿里集团大约有1.2万亿级的消息流转总量，几乎是15年双十一大促的2倍。峰值期间，消息生产的吞吐在2000 w/s左右，消息消费的吞吐也近乎1500 w/s的量级。整个大促下来，用我们内部的话来说，如丝般顺滑。
RocketMQ VS 其他几个消息中间件
请从技术构思、实践表现和适用场景三个大方向对RocketMQ、RabbitMQ、Kafka、ActiveMQ和ZeroMQ进行对比？除了技术上的较量，可否对这些中间件背后的社区运营、商业案例应用，进行对比呢？&&&&&&&&
1、是不是CS架构？
如果需要做同类产品之间的横向对比，我们优先拿下ZeroMQ，ZeroMQ正如其名0MQ，它更像是一个嵌入式的网络类库，一个专注于transports层的通讯组件，而不是传统意义上的CS架构的MQ。
2、实现的哪种规范 / 协议？
接下来我们来看看RabbitMQ、ActiveMQ、Kafka和RocketMQ之间的一些对比，从设计思路上来看，RabbitMQ是AMQP规范的参考实现，AMQP是一个线路层协议，面面俱到，很系统，也稍显复杂。目前RabbitMQ已经成为OpenStack Iaas平台首选的消息服务，其背后的支持力度不言而喻。
ActiveMQ最初主要的开发者在LogicBlaze，现在主要开发红帽，是JMS规范的参考实现，也是Apache旗下的老牌消息服务引擎。JMS虽说是一个API级别的协议，但其内部还是定义了一些实现约束，不过缺少多语言支撑。ActiveMQ的生态堪称丰富多彩，在该Apache顶级项目下，拥有不少子项目，包括由HornetMQ演变而来的Artemis，基于Scala号称下一代AMQ的Apollo等。
3、适用何类场景？
而Kafka最初被设计用来做日志处理，是一个不折不扣的大数据通道，追求高吞吐，存在丢消息的可能。其背后的研发团队也围绕着Kafka进行了商业包装，目前在一些中小型公司被广泛使用，国内也有不少忠实的拥捧着。
RocketMQ天生为金融互联网领域而生，追求高可靠、高可用、高并发、低延迟，是一个阿里巴巴由内而外成功孕育的典范，除了阿里集团上千个应用外，根据我们不完全统计，国内至少有上百家单位、科研教育机构在使用。关于这几个MQ产品更详细的特性对比，可以参考我们官网上的说明[2]。
三项技术发力点
（一）消息的顺序
不可否认，顺序消息是RocketMQ功能特性上的一个卖点。目前我们做到了全局保序。需要重点说一下，这里的全局是有前提，针对某个唯一标识（能够被Hash成唯一标识），比方说大卖家账号，某类产品的订单等。其技术实现原理也相对比较简单，保证对通道的单一实例操作，如单进程、单线程写，单进程、线程读，像ActiveMQ的Exclusive Consumer也是类似的实现。
不难看出，这种实现方式实际是在吞吐上做出了一定牺牲。另外也带来了另外一个问题 - 热点。如双十一当天，如果使用简单的散列策略，像短期内就交易过亿的天猫商家的消息会发送到一个通道里面，造成单通道，甚至单机的热点问题在最新的RocketMQ版本里，我们将会改进目前的实现，借此改善因为顺序导致的单通道热点问题，这个特性预计今年中旬会发布。
（二）消息的去重
消息领域有一个对消息投递的QoS定义，分为：最多一次（At most once），至少一次（At least once），仅一次（ Exactly once）。
几乎所有的MQ产品都声称自己做到了At least once。既然是至少一次，那避免不了消息重复，尤其是在分布式网络环境下，而这个缺憾归根结底也可以看做是TCP协议的一部分，如失败重传。业务上往往对消息重复又很敏感，RocketMQ目前的版本是不支持去重的，我们通常建议用户通过外置全局存储自己做判重处理。在下一代的特性规划里，我们会内置解决方案。先说下业界通用做法，像Artemis，IronMQ等，通过在服务端全局存储判重。这是一个IO敏感的操作，为服务端带来一定的负载。而RocketMQ则希望通过采取二次判重策略，有效降低服务端IO。
（三）分布式的挑战
首先明确分布式系统这个概念：分布式系统是由一系列分散自治组件通过互联网并行并发协作，从而组成的一个coherent软件系统。它具备资源共享，并行并发，可靠容错，透明开放等特性。像CAP，BASE，Paxos，事务等一起构成了分布式基础理论。
这里我们再来重温下CAP理论：CAP分别代表一致性（Consistency），可用性（Availability），分区容忍性（Partition tolerance）。一致性，Eric Brewer（CAP理论提出者）用一个服务要么被执行，要么不被执行来定义(原文：A service that is consistent operates fully or not at all)。请注意，这里的一致性是有别于数据库ACID属性中的C，数据库层面的C指的是数据的操作不能破坏数据之间的完整性约束，如外键约束。在分布式环境中，可以把C简单理解为多节点看到的是数据单一或者同一副本。可用性，意味着服务是可用的（原文：the
service is available (to operate fully or not as above)）。可用性又可以细分为写可用和读可用。在分布式环境中，往往指的是系统在确定时间内可返回读写操作结果，也即读写均可用。分区容忍性，除了整个网络故障外（如光纤被掘断），其它故障（如丢包、乱序、抖动、甚至是网络分区节点 crash ）都不能导致整个系统无法正确响应（原文：No set of failures less than total network failure is allowed to cause
the system to respond incorrectly）。
CAP理论可以看做是探索适合不同应用的一致性与可用性平衡问题。
没有分区的情况：可以同时满足C与A，以及完整的ACID事务支持。可以选择牺牲一定的C，获得更好的性能与扩展性。
分区的情况：选择A（集中关注分区的恢复），需要有分区开始前、进行中、恢复后的处理策略，应用合适的补偿处理机制。像RocketMQ这样的分布式消息引擎，更多的追求AP。再强的系统也一定有容量底线，足够的容量是可用性的有效前提。通常情况下，会通过降级、限流、熔断机制来保障洪峰下的可用性。具体的技术细节可以参看电子书章节[1]
另外，考虑到在金融高频交易典型场景，我们也为RocketMQ设计了CP机制，在满足分布式系统的分区容错性的前提下，牺牲系统可用性来保证数据的一致性。而技术实现上，则基于Zab一致性协议，利用分布式锁和通知机制，以此来保障多副本数据的一致性。
开源捐赠和社区运营
目前国内外有很多公司会把一些通用问题的解决方案，尤其是那些久经考验、愈久弥坚的产品开源出来，以期望在品牌宣传、人才引进方面有所建树。把RocketMQ开源出来，甚至捐赠给Apache，内部也是经过了深思熟虑，层层审批与讨论，期望能够在生态化、规范化、国际化、商业化方面深耕细作。
开源捐赠的想法实际上始于2014年。当时，我们甄选了几位Apache社区权威人士，遗憾的是反复沟通不断修改草案之后突然间失去了联系。2015年，我们有幸结识了Kylin Principal Architect蒋旭和VP Luke以及RedHat Principal Software Engineer姜宁，请教了一些Apache禁忌事项，重新活跃起来了捐赠进程。接下来，最重要的是征集champion候选人，很开心的是ActiveMQ VP Bruce爽快地接收了我们的邀请，经过前前后后接近100封邮件来往，我们终于正式开启了Apache之旅。捐赠投票是在双十一当天，我们准备充分很好地回答了评委会的犀利问题。不过，面对“中国开发者不喜欢邮件沟通”突然刁难，还要感谢社区华人的防御性声明回应。经过很多磨难，投票结果总算出来了：还不算坏10票赞同，带binding（IPMC成员的有效投票）的+1，无反对票，正式进入孵化期。孵化成功后有望成为国内首个互联网中间件在Apache上的顶级项目，成为全球继ActiveMQ，Kafka之后，分布式消息引擎家族中的重要成员。
接下来，我们想强调下知识产权这个对大多数工程师来说陌生的领域，尤其是专利权、著作权、商标权。在国外，每年因为这些问题导致的侵权官司不在少数。而我们在开源之初，对这块的选择、保护也是极其谨慎，包括开源许可协议的选择、授权方面，代码署名权等，这些都是很好的智力保护，也是我们产品的核心竞争力之一。尊重知识，尊重产权，才能构建一个和谐积极向上的开源氛围，打造真正的自主知识产权品牌产品。&&&&&
在Alibaba，我们基于开源引擎的RocketMQ，为云上用户提供了商业化版本的。两个产品都是由阿里中间件消息团队出品。商业版Aliware MQ 在支持 TCP 、HTTP 和MQTT 协议接入，功能方面增强了运维管控方面，生态集成的能力（包括可视化的消息轨迹、资源报表统计以及监控报警、Kafka集成等）。它在公有云上本身具备多机房部署同城高可用容灾特性，目的是满足企业级要求。&&&&&
关于社区的运营，我们采取了和Apache顶级项目基本相似的策略。首先，必须立足于高质量产品本身，从版本规划开始，我们建立了里程碑讨论，Features设计，编码自测，结对Review，集成测试，Release讨论，Release公告等等一系列规范且高效的软件研发流程。其次，在社区运营层面，则有一系列与社区互动的活动，如线下meetup、workshop、ApacheCon、不定期的编程马拉松等，吸纳新的Contributor和Committer进来。
新一代RocketMQ，蓄势待发
最近，团队也在着手构建下一代RocketMQ，期望构建一套厂商无关的集线路层、API层于一体的规范，这也是第四代消息引擎最大的亮点。目前，我们联系了Twitter、Yahoo等公司相关技术负责人，共同起草完善这一规范，而RocketMQ将会是第一批率先成为参考实现的产品。我们非常期望国内的MQ厂商亦或是分布式爱好者能够参与进来，积极在国际开源社区代表国人发声呐喊。
另外，本周，团队刚刚发布了第四代引擎的第一个版本，该版本也是进入Apache社区后的首次发版。按照我们的规划，将在今年4月左右完成整个引擎的升级重组，非常欢迎大家的使用、反馈以及参与。
最后，更多信息可以移步、、以及。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：26271次
排名：千里之外
原创：73篇
(6)(2)(24)(17)(4)(1)(1)(28)