rabbitMq、rocketMq、kafaka适用场景对比
架构方面：
可靠性：
Kafaka是正常的mq架构，包括provider broker consumer。kafaka有消息确认机制ack
rabbitMq 中的broker由exchange、binder queue三部分组成，其中exchange和binding组成了消息的路由键；客户端Producer通过连接channel和server进行通信，Consumer从queue获取消息进行消费，rabbit有消息确认机制
RocketMQ支持异步/同步刷盘;异步/同步Replication；
Kafka使用异步刷盘方式，异步Replication。
结论：RocketMQ所支持的同步方式提升了数据的可靠性。
吞吐量方面：
Kafaka采用zero-copy方式，即数据存储和获取是本地磁盘顺序批量操作，具有O（1）复杂度，数据处理效率很高
RabbitMq在吞吐量方面不如kafaka，RabbitMq支持对消息可靠的传递，支持事务，不支持批量的操作。
Kafka单机写入 TPS 号称在百万条/秒；
RocketMQ 大约在10万条/秒。
结论：追求性能的话，Kafka单机性能更高。
可用性方面
Kafaka的broker采用主备模式，所以可用性很高
RabbitMq支持miror queue，主queue失效，minor queue生效
集群负载方面
Kafaka使用zookeeper实现负载均衡，zookeeper管理集群中的broker sonsumer，通过zookeeper的协调机制，producer会记录topic对应的broker，对broker进行轮询或者随机访问broker，实现负载均衡
RabbitMq需要单独自定义负载均衡
消息准确性方面
kafaka支持事务，对消息的重复、丢失、错误没有严格要求，可以通过配置参数实现；
rabbitMq采用AMQP协议，AMQP协议更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景
rabbitMq,rocketMq对比
rabbitmq整体更稳定，延迟更小
rabbitMq社区更活跃
rabbitmq管理界面更好
rabbitmq吞吐量为万级别，少一个量级
（1） 适用场景
Kafka适合日志处理；
RocketMQ适合业务处理。
结论：平手，根据具体业务定夺。
（2） 性能
Kafka单机写入 TPS 号称在百万条/秒；
RocketMQ 大约在10万条/秒。
结论：追求性能的话，Kafka单机性能更高。
（3） 可靠性
RocketMQ支持异步/同步刷盘;异步/同步Replication；
Kafka使用异步刷盘方式，异步Replication。
结论：RocketMQ所支持的同步方式提升了数据的可靠性。
（4） 实时性
均支持pull长轮询，RocketMQ消息实时性更好
结论：RocketMQ 胜出。
（5） 支持的队列数
Kafka单机超过64个队列/分区，消息发送性能降低严重；
RocketMQ 单机支持最高5万个队列，性能稳定
结论：长远来看，RocketMQ 胜出，这也是适合业务处理的原因之一
（6） 消息顺序性
Kafka 某些配置下，支持消息顺序，但是一台Broker宕机后，就会产生消息乱序；
RocketMQ支持严格的消息顺序，在顺序消息场景下，一台Broker宕机后，
发送消息会失败，但是不会乱序；
结论：RocketMQ 胜出
（7）消费失败重试机制
Kafka消费失败支持重试，KafkaProducer通过设定参数retries
RocketMQ消费失败支持定时重试，每次重试间隔时间顺延。
（8）定时/延时消息
Kafka不支持定时消息；可以使用DelayQueue实现。
RocketMQ支持定时消息
（9）分布式事务消息
Kafka不支持分布式事务消息；
阿里云ONS支持分布式定时消息，未来开源版本的RocketMQ也有计划支持分布式事务消息
（10）消息查询机制
Kafka不支持消息查询
RocketMQ支持根据Message Id查询消息，也支持根据消息内容查询消息
（11）消息回溯
Kafka理论上可以按照Offset来回溯消息
RocketMQ支持按照时间来回溯消息，精度毫秒，例如从一天之前的某时某分某秒开始重新消费消息
3. 为什么阿里会自研RocketMQ？
（1）Kafka的业务应用场景主要定位于日志传输；对于复杂业务支持不够
（2）阿里很多业务场景对数据可靠性、数据实时性、消息队列的个数等方面的要求很高。
kafka针对海量数据，但是对数据的正确度要求不是十分严格。而阿里巴巴中用于交易相关的事情较多，对数据的正确性要求极高，Kafka不合适
（3）当业务成长到一定规模，采用开源方案的技术成本会变高.
开源方案无法满足业务的需要；旧版本、自开发代码与新版本的兼容都可能是问题；运维角度，Kafka使用 scala 编写，而阿里是java系。Kafka 的后续维护是个问题。
（4）阿里在团队、成本、资源投入等方面约束性条件几乎没有.
综上，阿里选择自己开发RocketMQ更多是业务的驱动，当业务更多的需要以下功能的支持时，kafka 不能满足或者 ActiveMQ 等其他消息中间件不能满足，财大气粗能力又强业务还复杂，所以就自己开发了。
4. 其他
另外认为kafka是用于日志传输，所以不适合系统的业务事件是个更大的误区，Kafka本身在最早实现时的确是为了传输日志，但后来经过多年发展，其适用范围早不限于日志，并且很多采取Kafka的公司并非用它来处理日志，kafka背后的 Confluence公司提供了很多基于kafka来简化系统实现的例子。