了解何时使用RabbitMQ或Apache Kafka

原文: https://content.pivotal.io/rabbitmq/understanding-when-to-use-rabbitmq-or-apache-kafka
（由于本人翻译能力有限，请勿较真...）

背景

RabbitMQ是一个“传统的”消息代理，它实现了多种消息协议。最初是为了实现AMQP而开发的，AMQP是一种开放的，具有强大路由功能的消息协议。虽然Java具有像JMS这样的消息标准，但对于需要分布式消息的非Java应用程序来说，这是非常有限的。对于集成场景，例如微服务或单一的集成都是非常有限。随着AMQP的出现，跨语言及灵活性在AMQP消息代理中变得可行。

Apache Kafka是在Scala开发的，最初是在LinkedIn上连接不同的内部系统。当时LinkedIn正在转向更分散的体系结构，需要重新构建像数据集成和实时流处理这样的功能，摆脱以前针对这些问题的单一方法。Kafka今天在Apache软件基金会的产品生态系统中得到了很好的应用，特别在事件驱动架构中尤其有用。

架构和设计

RabbitMQ被设计为一个通用的消息代理，采用点到点，请求/回复和pub-sub通信模式。它使用一个聪明的消息代理/愚蠢(dumb)的消费者模式，专注于向消费者传递一致的消息，消息代理保持消费者与消费者状态基本一致的速度进行消费。RabbitMQ是成熟的、配置容易、性能良好，同时得到很好的支持（客户端库Java，.NET，node.js，Ruby，PHP等多种语言），并且有几十个插件可以扩展更多的场景。

image.png

参考
*Figure 1 - Simplified overall RabbitMQ architecture. Source: http://kth.diva-portal.org/smash/get/diva2:813137/FULLTEXT01.pdf *

RabbitMQ可以根据需要进行同步或异步通信。生产者将消息发送给交换机(Exchange)，消费者从队列中获得消息。通过消息交换将生产者从队列中解耦出来，可以保证生产者不需要硬编码路由。RabbitMQ还提供了许多分布式部署方案。它可以设置为多节点集群来联合集群，并且不依赖于外部服务（但某些集群插件需要使用AWS API，DNS，Consul等）。

Apache Kafka设计用于高容量的发布 - 订阅消息和数据流，提供消息持久化，快速和可扩展功能。就其本质而言，Kafka提供了一个持久的消息存储库，类似于在服务器群集中运行的日志，它将记录流存储在称为主题(Topic)的类别中。

image.png

参考
*Figure 2 - Global Apache Kafka architecture (with 1 topic, 1 partition, replication factor 4). Source: http://kth.diva-portal.org/smash/get/diva2:813137/FULLTEXT01.pdf *

每条消息由一个键，一个值和一个时间戳组成。与RabbitMQ几乎相反，Kafka使用一个愚蠢(dumb)的消息代理，并使用聪明的消费者来阅读消息缓冲区。Apache Kafka并不尝试追踪每个消费者阅读了哪些消息，只保留未读消息; 相反，Kafka将所有消息保留一定的时间，消费者负责跟踪他们在每个日志（消费者状态）中的位置。因此，通过开发人员编写消费者代码，Kafka可以支持大量的消费者，并以很少的开销保留大量的数据。但Kafka需要运行外部服务 如上图所示。 - Apache Zookeeper通常是必须安装和运行。

需求和用例

Apache Kafka除了本身作为消息代理外，Kafka添加了Kafka Streams, 可以替代Apache Spark，Apache Flink，Apache Beam / Google Cloud Data Flow和Spring Cloud Data Flow等流式平台。
例如网站活动跟踪、指标、日志聚合、流处理、事件源和提交日志等用例方面做得很好。简单来说例如：

• 从A流到B，没有复杂的路由，最大吞吐量（100k / sec +），按分区顺序传递至少一次。
• 当您的应用程序需要访问流历史记录时，按分区顺序传递至少一次。Kafka可以根据需要“重放”事件流，而不是传统的消息代理，一旦消息被传递，它就会从队列中移除。
• 流处理
• 事件源

RabbitMQ是一个通用的消息传递解决方案，通常应用于服务器快速响应请求。将消息分发给多个消费者进行消费或在高负载（20k + /秒）之间做出平衡。当您的需求超出吞吐量时，RabbitMQ提供了很多功能：可靠的交付，路由，联合，HA，安全，管理工具和其他功能。最适合RabbitMQ的一些场景，比如：

• 您的应用程序需要使用现有协议或的任何协议的组合，如AMQP 0-9-1，STOMP，MQTT，AMQP 1.0。
• 您需要在每条消息的基础上进行更细粒度的一致性控制/保证（死信队列等）。但是，Kafka最近增加了对交易类的很好的支持。
• 您的应用程序需要点对点，请求/回复以及发布/订阅消息
• 复杂的路由到消费者，整合多个服务/应用的路由逻辑

RabbitMQ也可以有效地解决上面几个Kafka使用案例，但是需要在附加软件的帮助。当应用程序需要访问流历史记录时，RabbitMQ通常与Apache Cassandra一起使用，或者与需要“无限”队列的应用程序的LevelDB插件一起使用，但RabbitMQ本身并不具备这些功能。

开发者经验

略

安全与运维

略

性能

Kafka的在性能上非常耀眼：100k /秒的表现往往是人们选择Kafka的关键。

当然，每秒钟的消息速率很难说明和量化，因为它们依赖于你的环境和硬件，工作负载的性质，使用哪种传输保证（例如，持久代价高昂，镜像更是如此）等等。

每秒20K的消息很容易通过一个单一的RabbitMQ队列来实现。再快就很难了，因为队列由一个简单的Erlang轻量级线程支持，该线程在本地操作系统线程池中进行协作调度 - 因此，单个队列永远不会比CPU周期能够做的事情更多，所以这成为瓶颈的所在。

增加每秒消息通信可以通过消息路由（例如，可以同时运行不同的队列）来打破多个队列中的流量，利用RabbitMq环境中的并行性。当RabbitMQ 每秒钟达到100万条消息时，这个用例基本上完全是这样做的 - 但是在30个RabbitMQ节点上使用了大量的资源。大多数RabbitMQ用户都可以在3到7个RabbitMQ节点获得优异的性能。