什么时候用RabbitMQ 什么时候用Apache Kafka？

先从他们的初心开始说起

RabbitMQ的横空出世是为了实现AMQP协议，这是一个具有强大路由能力的消息服务协议；说到这里就不得不提AMQP协议的初心，举个例子java也有标准的消息服务协议JMS，虽然能服务于java应用，但是对于非Java应用或者分布式的、多语言集成化、微服务化方案就爱莫能助了；而AMQP正是为了实现跨语言消息代理服务。

而Kafka诞生的使命在于解决Linkedin公司推进分布式的架构时产生的各个系统之间数据集成和实时流处理的问题，kafka非常高效，并且能很好的与Zookeeper无缝集成来扩展集群功能，随后kafka加入了Apache软件基金会并且在解决事件驱动的架构中大放光芒。

从架构和设计理念来说

RabbitMQ

1. 被设计为一个通用的消息代理服务，支持点对点、请求-答复、发布-订阅等模式
2. 专注于消息的一致性、可靠性和稳定性；
3. 对Java, .NET, node.js, Ruby, PHP等众多语言都有着非常好的支持，并且有丰富的插件来提供功能扩展，没有做不到只有想不到；
4. 支持同步或异步消息通信；支持分布式部署和多节点集群部署，能提供2万/秒的消息分发能力，性能上不敌kafka。

Apachekafka

1. 是为高容量的发布-订阅消息和流而设计的，
2. kafka只支持java客户端（可通过扩展来实现对其他语言的支持），
3. 分分钟就100k/sec性能是人们选择 Apache Kafka的关键驱动力，
4. 除了我们所熟知的消息代理功能，还增加了流处理功能，它对自己最新的定位是Apache Spark, Apache Flink, Apache Beam/Google Cloud Data Flow 和 Spring Cloud Data Flow的替代品之一；
5. kafka不会记录每个消费者的消息消费情况，而是可以在一段时间内保留所有消息，由消费者记录自己的消费指针，因此kafka可以在极低的代价下提供非常大的队列容量和消费者数量支持，

kafka适合的场景：

适用场景1：无复杂路由情况下的高吞吐量消息服务（10万条/每秒）
适用场景2：需要消息“重放”功能的情况
适用场景3：要求大容量队列的场景

RabbitMQ适合的场景：

适用场景1：需要高可靠性、一致性的消息服务
适用场景2：与现有协议兼容：AMQP 0-9-1, STOMP, MQTT, AMQP 1.0
适用场景3：需要实现复杂路由的场景

参考： https://content.pivotal.io/blog/understanding-when-to-use-rabbitmq-or-apache-kafka