【转载】Understanding When to use RabbitMQ or Apache Kafka

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

RabbitMQ： Erlang

Apache Kafka：Scala

 

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

来自谷歌翻译

了解什么时候使用RabbitMQ或Apache Kafka

2017年4月26日 彼得·汉弗莱

人类如何作出决定？在平常生活中，情绪每每是拉动触发复杂或压倒性决定的开路因素。可是对于作出长期后果的复杂决策的专家来讲，这并非纯粹的冲动。高绩效者一般只有在专家，潜意识的头脑吸取了做出决定所需的全部事实以后，才使用“本能”，“直觉”或其余情绪的断路器。

今天，有数十种消息技术，无数的ESB，以及将近100个iPaaS供应商。固然，这致使了如何根据您的需求选择正确的消息传递技术的问题 - 特别是对于那些已经投入了特定选择的消息。咱们切换批发？只需使用正确的工具来完成正确的工做？咱们是否正确地将业务须要框架在手边？鉴于此，对我来讲什么是正确的工具？更糟的是，详尽的市场分析可能永远不会结束，但鉴于整合代码的平均寿命，尽职调查是相当重要的。

这篇文章努力给潜意识，专家的头脑甚至交给治疗考虑，从今天最现代，最受欢迎的选择开始：RabbitMQ和Apache Kafka。每一个都有它本身的原创故事，设计意图，使用案例，照亮，集成能力和开发人员的经验。起源揭示了任何一款软件的整体设计意图，而且是一个很好的起点。

起源
RabbitMQ是一个“传统的”消息代理，它实现了各类消息传递协议。它是第一个得到合理级别的功能，客户端库，开发工具和质量文档的开源消息代理商之一。RabbitMQ最初是为了实现AMQP而开发的，AMQP是一种开放的，具备强大路由功能的消息传递协议。虽然Java具备像JMS这样的消息传递标准，可是对于须要分布式消息传递的非Java应用程序来讲是没有帮助的，这些应用程序严重限制了任何集成场景，微服务或单块。随着AMQP的出现，跨语言的灵活性对于开源消息代理来讲变得真实。

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

建筑和设计

RabbitMQ被设计为一个通用的消息代理，采用点到点，请求/回复和pub-sub通讯风格模式的几种变化。它使用一个聪明的经纪人/愚蠢的消费者模式，专一于向消费者提供一致的消息传递，消费者的消费速度与经纪人跟踪消费者状态的速度大体相同。它是成熟的，配置正确，性能良好，获得很好的支持（客户端库Java，.NET，node.js，Ruby，PHP和更多的语言），而且有几十个插件能够扩展到更多的用例和集成场景。

 

图15 - 简化的总体RabbitMQ架构。资料来源：http：//kth.diva-portal.org/smash/get/diva2:813137/FULLTEXT01.pdf

RabbitMQ中的通讯能够根据须要同步或异步。发布者将消息发送给交换机，消费者从队列中检索消息。经过交换将生产者从队列中解耦出来，能够保证生产者不须要硬编码路由决策。RabbitMQ还提供了许多分布式部署方案（并要求全部节点可以解析主机名）。它能够设置为多节点集群来联合集群，而且不依赖于外部服务（但某些集群插件可使用AWS API，DNS，Consul等）。

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

 

图11 - 全球Apache Kafka架构（1个主题，1个分区，复制因子4）。资料来源：http：//kth.diva-portal.org/smash/get/diva2:813137/FULLTEXT01.pdf

每条消息由一个键，一个值和一个时间戳组成。与RabbitMQ几乎相反，Kafka雇用了一个愚蠢的经纪人，并使用聪明的消费者来阅读它的缓冲区。卡夫卡并不试图追踪每一个消费者阅读哪些消息，只保留未读消息; 相反，Kafka将全部消息保留必定的时间，消费者负责跟踪他们在每一个日志（消费者状态）中的位置。所以，经过合适的开发人员建立消费者代码，Kafka能够支持大量的消费者，并以不多的开销保留大量的数据。如上图所示，Kafka确实须要运行外部服务 - 在这种状况下，Apache Zookeeper一般被认为是不可理解的，安装和运行的。

需求和用例
许多开发人员在乎识到必须将许多东西链接在一块儿时才会开始探索消息，而其余集成模式（如共享数据库）则不可行或太危险。

Apache Kafka包括经纪人自己，这其实是最知名的和最受欢迎的部分，并已经设计和突出地销售到流处理场景。除此以外，Apache Kafka最近还添加了Kafka Streams，它能够替代Apache Spark，Apache Flink，Apache Beam / Google Cloud Data Flow等流媒体平台。该文档在讨论网站活动跟踪，指标，日志聚合，流处理，事件采购和提交日志等经常使用用例方面作得很好。其中描述的用例之一是消息传递，这可能会产生一些混淆。所以，让咱们解开这一点，并清楚地说明哪些消息传递场景最适合于Kafka，例如：

从A流到B，没有复杂的路由，最大吞吐量（100k / sec +），按分区顺序传递至少一次。
当您的应用程序须要访问流历史记录时，按分区顺序传递至少一次。Kafka是一个持久的消息存储库，客户端能够根据须要“重放”事件流，而不是传统的消息代理，一旦消息被传递，它就会从队列中移除。
卡夫卡的持久存储，一个是流处理
事件采购
RabbitMQ是一个通用的消息传递解决方案，一般用于容许Web服务器快速响应请求，而不是在用户等待结果时被迫执行资源繁重的过程。将消息分发给多个收件人进行消费或在高负载（20k + /秒）之间平衡工做人员之间的负载也是很好的。当您的需求超出吞吐量时，RabbitMQ提供了不少功能：可靠的交付，路由，联合，HA，安全，管理工具和其余功能。让咱们来看看最适合RabbitMQ的一些场景，好比：

您的应用程序须要使用现有协议的任何组合，如AMQP 0-9-1，STOMP，MQTT，AMQP 1.0。
您须要在每条消息的基础上进行更细粒度的一致性控制/保证（死信队列等）。可是，Kafka最近为事务添加了更好的支持。
您的应用程序须要点对点，请求/回复以及发布/订阅消息
复杂的路由到消费者，整合多个服务/应用与非平凡的路由逻辑
RabbitMQ还能够有效地解决上面几个Kafka强大的使用案例，可是在附加软件的帮助下。当应用程序须要访问流历史记录时，RabbitMQ常常与Apache Cassandra一块儿使用，或者与须要“无限”队列的应用程序的LevelDB插件一块儿使用，但RabbitMQ自己并不具有这些功能。

要深刻了解Kafka和RabbitMQ的微服务特定用例，请转到Pivotal博客，阅读Fred Melo的这篇短文。

开发者体验
RabbitMQ 经过社区插件正式支持Java，Spring，.NET，PHP，Python，Ruby，JavaScript，Go，Elixir，Objective-C，Swift等许多其余客户端和开发工具。RabbitMQ客户端库已经成熟而且有据可查。

Apache Kafka已经在这个领域取得了长足的进步，虽然它只是一个Java客户端，可是还有一个社区开源客户端，生态系统项目和一个适配器SDK 的增加目录，容许你创建你本身的系统集成。许多配置是经过.properties文件或编程方式完成的。

这两个选项的受欢迎程度对许多其余确保RabbitMQ和Kafka在他们的技术上运行良好的软件提供商有很大的影响。

开发人员的经验...刷新咱们在Spring Kafka，Spring Cloud Stream等中提供的支持是不对的。

安全和操做
二者都是RabbitMQ的优点。RabbitMQ管理插件提供了一个HTTP API，一个基于浏览器的用于管理和监控的UI，以及面向运营商的CLI工具。像CollectD，Datadog或New Relic等外部工具是长期监测数据存储所必需的。RabbitMQ还提供用于监视，审计和应用程序故障排除的API和工具。除了支持TLS以外，RabbitMQ还提供由内置数据存储，LDAP或基于HTTPS外部提供程序支持的RBAC，并支持使用x509证书而不是用户名/密码对进行身份验证。额外的认证方法能够至关简单地用插件开发。

这些领域对Apache Kafka构成挑战。在安全性方面，最近的Kafka 0.9版本增长了TLS，JAAS基于角色的访问控制和kerberos / plain / scram auth，使用CLI管理安全策略。这对早期版本进行了重大改进，您只能锁定网络级别的访问权限，这对于共享或多租户不起做用。

Kafka使用由shell脚本，属性文件和专门格式化的JSON文件组成的管理CLI。Kafka经纪商，生产商和消费者经过Yammer / JMX发布指标，但不保留任何历史记录，这实际上意味着使用第三方监控系统。使用这些工具，操做能够管理分区和主题，检查消费者偏移位置，并使用Apache Zookeeper为Kafka提供的HA和FT功能。虽然不少人对Zookeeper的要求持怀疑态度，但却为Kafka用户提供了集群优点。

例如，一个3节点Kafka集群系统即便在2次故障后也能正常工做。可是，若是你想在Zookeeper中支持尽量多的故障，你须要额外的5个Zookeeper节点，由于Zookeeper是一个基于法定人数的系统，只能容忍N / 2 + 1故障。这显然不该该与Kafka节点共处 - 因此为了站起来一个3节点的Kafka系统，你须要8台服务器。在推导任何Kafka系统的可用性时，运营商必须考虑到ZK集群的属性，不管是在资源消耗和设计方面。

性能
卡夫卡的设计在这里闪耀：100k /秒的表现每每是人们选择阿帕奇卡夫卡的关键驱动力。

固然，每秒钟消息的速率很难说明和量化，由于它们依赖于包括你的环境和硬件在内的不少东西，工做负载的性质，使用哪一种传输保证（例如，持久代价高昂，镜像更是如此）等等。

每秒20K条消息很容易经过一个单一的兔子队列来推进，确实比这更难，并不须要太多的保证。队列由一个简单的Erlang轻量级线程支持，该线程在本地操做系统线程池中进行协做调度 - 所以，单个队列永远不会作比CPU周期可以工做更多的工做，这成为天然的瓶颈或瓶颈在。

每秒增长消息一般是经过巧妙的路由（例如，能够同时运行不一样的队列）来打破多个队列中的流量这样的事情来正确地利用在一个环境中可用的并行性。当RabbitMQ 每秒钟达到100万条消息时，基本上彻底是为了作到这一点 - 可是使用了大量的资源，大约有30个RabbitMQ节点。大多数RabbitMQ用户均可以享受到由三到七个RabbitMQ节点组成的集群的卓越性能。

打电话
吸取一些在市场上其余一些顶级选项的研究。若是你想更深刻的选择最受欢迎的选择，那么Nicolas Nannoni的硕士论文启发了这篇文章，它在4.4节（第39页）中提供了一个并排比较表，这个表在两年后还算合理 - 值得阅读。

在研究的同时，尽量频繁地与利益相关方和企业进行交流。了解业务用例是为您的状况作出正确选择的惟一最重要的因素。那么，若是你是流行的心理学迷，你最好的选择就是睡上一觉，让它渗透，让你的本能接管。你有这个

关于做者
彼得·汉弗莱
Pieter Humphrey是负责Pivotal Software，Inc. Java开发人员营销的产品营销经理。Pieter来自BEA / Oracle，长期以来一直是开发人员工具，Java EE，SOA，EAI，应用程序服务器和其余Java中间件的发展者，销售工程师自1998年以来。在Twitter上找到我在https://www.twitter.com/pieterhumphrey。

更多内容经过Pieter Humphrey