RabbitMq与Kafka的比较

megnlingling

　　原文地址：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能提供高性能，低延迟消息的局面。现在有许多的选项。我敢打赌，你选择使用代理而不是指望在几年内出现无缺陷的交互（如果有的话)