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