阿里为什么选择RocketMQ
原文http://rocketmq.apache.org/docs/motivation/
阿里巴巴最开始使用ActiveMQ，
随着使用越来越多的队列和虚拟主题，ActiveMQ IO模块遇到了瓶颈。我们尽力通过节流，断路器或降级来解决此问题，但效果不佳。
因此，我们那时开始关注流行的消息传递解决方案Kafka。
不幸的是，Kafka不能满足我们的要求，特别是在低延迟和高可靠性方面
Kfaka分区设计
生产者写作的并行性受分区数量的限制。
消费者消费并行性的程度也受到消费的分区数量的限制。假设分区的数量为20，则并发使用使用者的最大数量为20。
每个主题均包含固定数量的分区。分区号确定单个代理可能具有的最大主题数，而不会显着影响性能
动机
在早期阶段，我们基于ActiveMQ 5.x（低于5.3）构建了分布式消息传递中间件。我们的跨国公司甚至在贸易过程中，也将其用于异步通信，搜索，社交网络活动流，数据管道。随着我们的贸易业务吞吐量的增加，来自消息传递集群的压力也变得迫在眉睫。
在本页面
为什么选择RocketMQ？
根据我们的研究，随着使用越来越多的队列和虚拟主题，ActiveMQ IO模块遇到了瓶颈。我们尽力通过节流，断路器或降级来解决此问题，但效果不佳。因此，我们那时开始关注流行的消息传递解决方案Kafka。不幸的是，Kafka不能满足我们的要求，特别是在低延迟和高可靠性方面，请参阅此处以了解详细信息。
在这种情况下，我们决定发明一个新的消息传递引擎来处理更广泛的用例集，从传统的发布/订阅方案到大批量实时零损失容忍交易系统。我们认为此解决方案可能是有益的，因此我们希望向社区开放它。如今，已有100多家公司在其业务中使用RocketMQ的开源版本。
下表展示了RocketMQ，ActiveMQ和Kafka（根据awesome-java， Apache最流行的消息传递解决方案）之间的比较：
RocketMQ与Kafka
请注意，本文档由RocketMQ团队编写。尽管理想情况是对技术和功能进行无私的比较，但是作者的专业知识和偏见显然偏爱RocketMQ。
| 讯息产品 | 客户端SDK | 协议和规范 | 订购消息 | 预定讯息 | 批处理邮件 | 广播消息 | 讯息筛选器 | 服务器触发的重新交付 | 讯息储存 | 消息追溯 | 邮件优先级 | 高可用性和故障转移 | 讯息追踪 | 组态 | 管理和操作工具 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 卡夫卡 | Java，Scala等 | 拉模型，支持TCP | 确保分区内消息的顺序 | 不支持 | 受支持，带有异步生成器 | 不支持 | 受支持的您可以使用Kafka Streams过滤消息 | 不支持 | 高性能文件存储 | 支持的偏移量指示 | 不支持 | 受支持，需要ZooKeeper服务器 | 不支持 | Kafka使用键值对格式进行配置。这些值可以从文件或以编程方式提供。 | 支持，使用终端命令公开核心指标 |
| 火箭MQ | Java，C ++，Go | 拉模型，支持TCP，JMS，OpenMessaging | 确保对消息进行严格排序，并可以正常扩展 | 支持的 | 支持，具有同步模式，可避免消息丢失 | 支持的 | 支持的基于SQL92的属性过滤器表达式 | 支持的 | 高性能和低延迟文件存储 | 支持的时间戳和偏移量两个表示 | 不支持 | 受支持的主从模式，无需其他套件 | 支持的 | 开箱即用，用户只需要注意一些配置 | 受支持的富Web和终端命令可显示核心指标 |
