RabbitMq与Kafka的比较

原文地址：http://www.quora.com/Which-one-is-better-for-durable-messaging-with-good-query-features-RabbitMQ-or-Kafka。

Kafka和RabbitMq同样是通用意图消息代理，他们都是以分布式部署为目的。可是他们对消息语义模型的定义的假设是很是不一样的。我对"AMQP 更成熟"这个论点是持怀疑态度的。让咱们用事实说话来看看用什么解决方案来解决你的问题。

a) 如下场景你比较适合使用Kafka。你有大量的事件(10万以上/秒)、你须要以分区的，顺序的，至少传递成功一次到混杂了在线和打包消费的消费者、你但愿能重读消息、你能接受目前是有限的节点级别高可用或则说你并不介意经过论坛/IRC工具获得还在幼儿阶段的软件的支持。

b) 如下场景你比较适合使用RabbitMQ。你有较少的事件（2万以上/秒）而且须要经过复杂的路由逻辑去找到消费者、你但愿消息传递是可靠的、你并不关心消息传递的顺序、你须要如今就支持集群-节点级别的高可用或则说你须要7*24小时的付费支持（固然也能够经过论坛/IRC工具）。

他们并不支持复杂的“过滤/查询”能力。若是你须要，能够考虑在他们的上层使用Storm来进行过滤、计算、查询。或则使用相似Cassandra做为你的查询缓存。Kafka虽然他已是生产版本，可是他并不成熟。

细节(警告-仅仅是个人意见，由于我并无很深刻的使用Kafka，而我对RabbitMQ更有经验一些）。

首先Rabbit和Kafka的比较。他们都是很是棒的解决方案，RabbitMQ相对更成熟一点，但二者的设计了理念有很是大的不一样。

从功能上讲，我认为RabbitMQ是以代理为中心。它专一于生产者与消费者之间的传递保证,而且认为消息的瞬时性优于持久性。

另外一方面 Kafka是以生产者为中心，经过分区管道将事件数据转为带有游标的持久化信息代理。支持打包消费的离线消费者或则但愿消息低延迟的在线消费者。

RabbitMQ让代理本身维护消费状态（经过消息确认机制）-它使用Erlang的Mnusia 在代理集群进行传递状态维护。

Kafka没有消息确认机制，它目前是假设消费者跟踪了什么已经被消费。

Kafka的代理和消费者在集群的模式下经过Zookeeper来可靠的维持他们的状态。

RabbitMQ假设消费者老是在线的，而且不知道任何消息的“等待”(不管持续与否)（也就是说没有游标）。在RabbitMQ pre-2.0（2010）版本若是消费者过于缓慢将会挂掉。不过如今他支持在线和打包消费的消费者-不过一般来说显然持续的大量消息放在代理中并不符合AMQP的主要设计思想。

Kafka一开始就基于打包消费的在线消费者而且支持生产数据进行打包的。它设计用来分布保持大量数据卷。

RabbitMQ按照AMQP0.9.1的exchange标准提供丰富的路由能力。支持绑定和队列化模型。

Kafka只有很是简单的路由功能-在AMQP来讲它仅仅使用话题进行交流。

两种解决方案都是运行在分布式集群中。可是RabbitMQ的思想是集群透明的，也就是说它是一个动态的代理。

Kafka则是集群明确的，强制要求生产者知道它的话题的消息是分区到几个节点中，这种思想的好处是提供一个分区内的有序递交。这比RabbitMQ暴露出来的基本上是无序递交来得更好（AMQP 0.9.1模型认为“单生产通道、单交流、单队列、单消费者通道”是有序递交的必要条件）

另外一方面来讲，Kafka假设生产者为他们的时间表生成大量的事件流-没有任何地方能够对生产者进行节流。由于若是数据太庞大，消费者就会变慢。Kafka经过在事件洪水和指望用本身的方法去消费的消费者（有些是在线的，有些是平时离线，仅仅一个小时甚至一天一次进行打包消费）之间提供"减震器"。

Kafka能递交“至少一次”每一个分区（为了维持有序传递），就像RabbitMQ,不过是用了一个很是不一样的方式。

从性能上来说，若是你须要有序的持久化消息传递，目前Kafka看起来没有任何的竞争对手。《Kafka目前来讲在综合基准的性能条款上远远超过RabbitMQ.》这篇文章中使用双节点集群，每一个节点使用6-disk RAID 10的状况下能够达到每秒发布50w条消息和每秒消费2.2w条消息。

http://research.microsoft.com/en...

固然它是LinkedIn的员工写的，他并不须要时RabbitMQ的输入专家，因此见仁见智吧。

最后提醒一下：Kafka是早期Apache的孵化项目，它并不必定像RabbitMQ那样难学。

总而言之对于AMQP,坦白来说这个标准就是在乱来。

官方消息1.0提出的规范正在经过OASIS的标准流程。可是在使用来讲，它是一个拆分的标准，0.9.1收到厂商所支持而1.0受到工做组的支持。一组通用，普适，产品质量并被主流产品（Redhat的Qpid,RabbitMQ..)所实现的AMQP1.0在2016年之前不会出现，若是它还会出现的话。

做为一个没有内部消息的外部观察者来讲，它是这个样子的：

工做组在一个规范上用了5年的时间，迎来了一个高潮，一个普适的版本发布（0.9.1)。而后一堆更强大的工做组成员在2011年重订了标准，婉转的将标准的重心从消息模型转移到了传输协议（有点像TCP++)，并声称它是1.0。所以，咱们就看到了一个奇怪的事情，“成熟的”AMQP标准是非标准版的0.9.1,而“非成熟的”AMQP标准是标准版的1.0.

这并非说1.0不是一个好的技术，他基本上来讲是一个好的技术，可是1.0比起AMQP在其的发布生涯中试图作到的标准来讲低级了不少。而且据我所知，除了它本身的原型和一个GA实现(IIT SwiftMQ)之外并无被普遍的支持。RabbitMQ人有一个原型是在1.0之上加了0.9.1的模型层，可是并无被提交一个GA时间表。

因此，个人意见是，AMQP丢弃了不少他们的亮点,而且通过了这么多年有充分的证据代表它在各个巨星中是能够互相操做的。政治拖延了官方标准而且将对它的质疑获得了普遍的支持。

在积极一面，你能够争论说AMQP已经成功的实现了它的目标。到2007年左右，打破了只有TIBCO能提供高性能，低延迟消息的局面。如今有许多的选项。我敢打赌，你选择使用代理而不是期望在几年内出现完好陷的交互（若是有的话)