RabbitMQ 由于持久化场景下的吞吐量只有2.6万，不能满足我们业务吞吐量的需求，云音乐在 2017 年将消息队列从 RabbitMQ 迁移到 Kafka 也是这个原因，因此不再考虑范围之内。由于云音乐整体业务的 QPS 较高，因此，ActiveMQ 也不在考虑范围。
这里主要对比 RocketMQ 与 Kafka：
Kafka 更偏向大数据，日志处理，缺少死信，消费失败自动重试，事务消息，定时消息，消息过滤，广播消息等特性，另外 Kafka 没有同步刷盘。云音乐的业务更偏向于多 Topic，死信可溯源，消费失败可收敛自动重试，高可用，自动 Failover 等特性。对于商城和社交业务来说，事物，顺序 Topic 使用会比较多。Kafka 和RocketMQ 对比 ：
http://jm.taobao.org/2016/03/24/rmq-vs-kafka
经过 RabbitMQ，Kafka 和 RocketMQ（ ActiveMQ 性能较差，暂不考虑）的调研和分析后，我们发现 RocketMQ 比较适合云音乐的通用业务，但是开源 RocketMQ 也有一些缺陷，只有我们解决了这些缺陷才能在业务中大规模使用。
开源 RocketMQ 的基本架构如下：（基本介绍参考）
开源 RocketMQ 主要问题有：
Broker 仅提供了 Master 到 Slave 的复制，没有 Failover 切换的能力。
事务消息不开源（我们开始研发时不开源）。
消息发送消费无追踪（我们开始研发时不开源）。
告警与监控体系没有。
开源控制台不完善。
云音乐业务对消息队列的要求
