kafka与rabbitMQ的区别-kafaka提交者的回答 翻译

工作中被安排负责MQ相关的模块，所以了解一下做一个选择。

我的要求：1.持久化2.高并发

文章引文原版来源

https://www.quora.com/What-are-the-differences-between-Apache-Kafka-and-RabbitMQ

kafka和rabbitMQ的区别  kafka提交者的一个回答，翻译

kafka是一个通用的message broker，就像RabbItMQ一样，具有类似的分布式部署目标，但对消息模型语义的假设却非常不同。我会对“AMQP更成熟”的论点表示怀疑，并看看两种解决方案是如何解决你的问题的。

TL,博士,
a）如果你有一堆事件的 Firehose （2万+/秒   每个生产者产生  ）你需要在“至少一次”的顺序中，通过在线和批量的消费者来交付，但是最重要的是你可以让你的消费者管理你的“光标”在kafka主题上的状态。
kafka的主要超级力量是，它不像一个队列系统，更像一个循环缓冲区，它可以像你的磁盘上的磁盘那样缩放，这样你就可以重新读取消息。
b)使用RabbitMQ如果你有消息(20k+/秒)，需要以复杂的方式对消费者进行路由

RabbitMQ的主要超能力是，它是一个可伸缩的高性能队列系统，具有定义良好的一致性规则，以及创建有趣的交换表的能力。
既不提供“过滤器/处理”功能,如果你需要,考虑使用数据流或流处理框架——有很多:Apach bean( 这是在 Google Dataflow、Flink、Spark或Apex上的抽象), Storm,NiFi,   direct use of  Apex,Flink, or Spark  or  Spring Cloud Data Flow上的其中一个解决方案添加计算、过滤、查询在你的数据流。 你也可能想要使用像Apache Cassandra或Geode或Ignite 的东西，作为你的可查询流缓存。

在它的创作中，kafka习惯上并没有提供事务性的语义，只到它的 0.11版本更改。

Pivotal最近发表了一篇相当公平的文章，在使用RabbitMQ或卡夫卡的时候，我提供了一些信息。Pivotal是RabbitMQ的所有者， 但同时也热衷于使用合适的工具来完成这项工作，并鼓励开源创新，从而成为卡夫卡的粉丝。

细节:
首先，在RabbitMQ与kafka之间。它们都是优秀的解决方案，RabbitMQ更加成熟，但两者的设计理念都非常不同。从根本上说，我认为RabbitMQ是以 broker为中心，专注于生产者和消费者之间的递送保证， 暂时的优选在持久化之上。kfaka是以 producer为中心的，它基于将事件数据的 firehose划分为具有游标的持久消息代理，支持可能挂掉的批处理消费者，或者是在线消费者，他们希望在低延迟的情况下发送消息。

RabbitMQ使用代理本身来维持所消耗的状态(通过消息确认)——它使用Erlang的记忆来维持代理集群的交付状态。kfaka没有消息确认，它假设消费者对消费的记录已经被消费了。kfaka经纪人使用zookpeer来可靠地维持他们在一个集群中的状态。

RabbitMQ假定消费者大多是在线的，任何“等待”(持续或不)的消息都是不透明的(即不存在光标)。 Kafka 的基础是在线和批量消费者， 它还提供了生产者消息批处理——它是为保存和分发大量的消息而设计的。

RabbitMQ提供了丰富的路由功能，包括AMQP 0.9.1的交换、绑定和队列模型。kafka有一种非常简单的路由方式——在AMQP

•  说法

中，它只使用主题交换。
这两种解决方案都是作为分布式集群运行的，但是RabbitMQ的理念是让集群变得透明，就好像它是一个虚拟代理一样。kafka通过强制生产者知道它是在多个节点之间划分一个主题的消息，从而明确划分了分区。这样做的好处是在分区内保存有序的交付。

RabbitMQ确保队列消息存储在已发布的订单中，即使是在请求或通道关闭的情况下。您可以使用一致的哈希交换或分片插件，为kafka建立一个类似的拓扑和订单交付。或者更有趣的拓扑。(这段我翻译的很晕，希望大神指点  原文：

RabbitMQ ensures queued messages are stored in published order even in the face of requeues or channel closure. One can setup a similar topology & order delivery to Kafka using the consistent hash exchange or sharding plugin., or even more interesting topologies.

)

换句话说，kafka假定生产商在他们自己的时间表上产生大量的事件——没有空间限制生产者，因为消费者的速度太慢，因为数据太大了。kafka的整个工作就是在大量的事件和那些想要以自己的方式消费的人之间提供“减震器”(力士:我觉得就是一个缓冲区)——有些是在线的，有些是离线的——只在一小时甚至每天的基础上消费。

在性能方面，两者都是出色的表现，但在架构上有很大差异。RabbitMQ已经演示了超过100万个消息/秒的设置，kafka已经演示了数百万个消息/秒的设置。主要的架构差异是，RabbitMQ主要在内存中处理其消息，因此在这些基准(30多个节点)中使用了一个大的集群，而kafka骄傲地利用了顺序磁盘输入/输出的能力，并且需要更少的硬件(这个基准使用了3x-6核心/32 GB RAM节点)。

这篇较老的论文指出，卡夫卡每秒处理50万条消息，在2个节点的集群上每秒处理22,000条消息，其中有6个磁盘RAID 10。
https://www.microsoft.com/en-us/research/people/srikanth/?from=http%3A%2F%2Fresearch.microsoft.com%2Fen-us%2Fum%2Fpeople%2Fsrikanth%2Fnetdb11%2Fnetdb11papers%2Fnetdb11-final12.pdf
现在，关于AMQP的一个词。坦白地说，标准似乎是一团糟，但已经稳定下来了。根据OASIS的官方标准，有一个1.0规范。在实践中，它是一个派生的标准，0.9.1被广泛地部署在生产环境中，而1.0版本的用户数量更少。

AMQP已经失去了一些光环和动力，但它已经成功地帮助打破了TIBCO在2007年左右的高性能、低延迟的消息传递。现在有很多选择。