什么时候该用RabbitMQ ，什么时候该用 Apache Kafka

人类如何做出决策? 在日常生活中，情感总是短路因素，导致在复杂或压倒性的决定上扣动扳机。但对于做有长期影响，复杂决策，的表意识，不可能是纯粹的冲动。高性能的人通常使用断路器，“本能,” “直觉,” 或其他的情绪，只有一次他们的表意识，潜意识吸收了作出决定所需的所有事实。

今天有很多的消息传递技术, 数不清的 ESBs, 和近100 iPaaS供应商在市场上。 自然，这导致了有关如何为您的需要-特别是那些已经投资在一个特定的选择，选择正确的消息传递技术的问题 。我们批发选择吗? 用正确的工具做正确的工作?我们有没有正确地布置手头的工作以满足业务需求? 鉴于此，对我来说，合适的工具是什么? 更糟糕的是，详尽的市场分析可能永远无法完成，但由于集成代码的平均寿命，尽职调查是至关重要的。

这篇文章致力于给予潜意识，表意识 一些公平的考虑，从今天最现代，最受欢迎的选择： RabbitMQ和Apache Kafka。 每个都有自己的起源故事, 设计意图，使用案例，被应用, 整合能力，和开发人员的经验。对于任何的软件，起源揭示总体设计意图，都是一个很好的起点。

起源

RabbitMQ 是一个 “传统的” 消息代理，实现多种消息传递协议。 是第一个开源消息代理，达到合理的功能水平， 客户端库，开发工具，和质量文档。 RabbitMQ 最初开发来实现AMQP，具有强大路由功能的消息传递的开放式路由协议。尽管Java有消息传递标准像JMS，但对需要传递消息的分布式非java应用没有帮助，这严重限制了很多集成方案，微服务或单组件。随着AMQP的到来，跨语言的灵活性，成为真正的开源消息代理。

Apache Kafka是用Scala开发的，起初应用于 LinkedIn ，作为一种简化Hadoop 从 Apache Flume提取消息的方案。 从复数数据源消费和生产的数据，为每个源和目标配对编写独立的数据管道。Kafka 帮助 LinkedIn 标准化数据管道并允许将数据从每个系统中取出一次并存入每个系统一次，使管道 (和操作) 更简单。Kafka是如今Apache Software软件基金会的通用配置。特别地，很好的与Apache Zookeeper集成，形成了Kafka分布式分区的支柱。 许多人认为 Zookeeper的需求并不是那么高，它赋予了Kafka用户集群的益处。

体系结构和设计

RabbitMQ i被设计为通用消息代理，采用点对点的几种变化， 请求/答复，和发布-订阅通信风格模式。它使用智能代理/哑消费者模型，专注于消息传递消费者的一致性，作为代理跟踪消费者的状态，保证以大致相同的速度消费。配置正确时表现良好，成熟，被支持的很好 (客户端库包括 Java, .NET, node.js, Ruby, PHP和很多其他语言)，有几十个插件可用，将其扩展到更多用例和集成场景。

简化的整体 RabbitMQ 体系结构(source).

RabbitMQ的通信，根据需要可以是同步或异步。推送者发送消息到交换区，消费者从队列检索消息。 通过发送消息到交换区的形式，将生产者解耦，确保生产者不承担硬编码路由压力。 RabbitMQ 还提供了一些分布式部署方案 (要求所有节点可以解析主机名)。它可以设置为多节点集群为集群联盟，并且不依赖外部服务 (但一些集群形成插件可以使用AWS APIs, DNS, Consul，等)。

Apache Kafka 是专为高容量发布-订阅消息流设计的，意味着经久耐用， 快速，而且可扩展的。在其本质上， Kafka 提供持久的消息存储，在某些方面类似于数据库，在服务器集群中运行，存储流记录的类别称为主题。

 全局 Apache Kafka 体系结构(1 主题, 1 分区, 4 复制因子). (source)

每条消息包含一个键，一个值和一个时间戳。 同RabbitMQ几乎相反， Kafka使用了笨代理， 并使用智能消费者读取其缓冲区。 Kafka不尝试跟踪那些被消费者消费的消息，只保留未读消息;相反, Kafka保留所有消息的一组时间，消费者负责跟踪他们在每个日志的位置 (消费状态)。 因此，用正确的开发者人才 创建消费者代码， Kafka 可以支持大量的消费者并且保留大量数据以很少的开销。如上图所示，Kafka确实需要外部服务运行 – 在这种情况下，Apache Zookeeper, 通常被认为是必要，理解，设置，和操作的。

需求和用例

许多开发人员开始探索消息传递，当他们意识到他们必须把很多东西连接在一起，和其他集成模式，如共享数据库是不可行的或太危险的时候。

Apache Kafka 将其描述为分布式流媒体平台，但更为人知的是一个持久的存储库，有着很好的Hadoop/Spark 支持。文档做得很好，讨论流行的用例，比如网站活动跟踪，指标，日志聚合，流处理，事件溯源和提交日志。这些用例之一，它描述了消息，可能产生一些混乱。 所以让我们打开一点，看的更清晰，关于哪种消息方案更适合Kafka，比如：

• 从A到B的流没有复杂的路由， 有最大吞吐量(100k/sec+)，按分区顺序交付至少一次。
• 当你的应用程序需要访问流历史，按分区顺序交付至少一次。Kafka是持久的消息存储和客户可以得到一个 “replay” 事件流的需求，相对于更传统的消息代理，一旦一个消息被交付，就会从队列中移除。
• 当你有聪明的消费者，能可靠地跟踪他们的日志偏移。
• 如果您的应用程序需要 “无限的” 队列。

RabbitMQ是一个通用消息传递解决方案，通常用于， 当用户等待结果时，允许web服务器快速响应请求，而不是被迫执行重资源程序。也有利于分发消息到多个消费者进行消费， 或在高负荷条件下平衡worker之间的荷载 (20k+/sec)。当你的需求超越吞吐量， RabbitMQ有很多提供： 特性，可靠消息传递， 路由，联合会， HA， 安全, 管理工具和其他特性。让我们看看一些最适合RabbitMQ的场景，比如：

• 您的应用程序需要，与现有协议组合，比如AMQP 0-9-1, STOMP, MQTT, AMQP 1.0.
• 你需要成熟，容易理解的一致性保证，为您的信息传递。
• 你的应用需要多种类型的点对点协议，请求/应答，和发布/订阅 消息.
• 复杂的消费者路由，整合多个服务/应用程序，使用难以掌握的路由逻辑。
• 当与你现有的 IT 基础设施整合很重要， RabbitMQ 更好。

RabbitMQ 也可以有效地解决几个上面的Kafka强有力的用例，但要借助额外的软件。RabbitMQ经常与Apache Cassandra配合使用，当应用程序需要访问流历史时，或与LevelDB插件，对于应用程序需要 “无限” 队列， 但都不是RabbitMQ自带的。

开发经验

RabbitMQ正式支持Java, Spring, .NET, PHP, Python, Ruby, JavaScript, Go, Elixir, Objective-C, Swift – 与许多其他 客户和开发工具，通过社区插件。RabbitMQ 客户端库是成熟且良好文档的。

Apache Kafka 在这一领域已经取得了长足进步，虽然他主要是Java客户端，有越来越多的社区目录 开放源码客户端， 生态系统项目，以及作为适配器 SDK 允许您建立自己的系统集成。大部分的配置已经设定好了，通过.properties 文件或编程方式。

这两个选项的流行，在许多其他软件供应商，有很强的影响力，确保RabbitMQ 和Kafka正常工作，通过他们的技术。

安全和操作

安全和操作都是RabbitMQ的强项。 RabbitMQ管理插件提供了HTTP API，一个基于浏览器的 UI 用于管理和监控，加上CLI工具给予操作员。 外部工具，如果长期监测数据存储，比如CollectD, Datadog或者New Relic也是需要的。 RabbitMQ还提供了API和监控工具，审核和应用故障排除。除了支持TLS，RabbitMQ附带RBAC支持通过内置数据存储， LDAP或外部基于HTTPS的供应商，并支持身份验证使用x509证书，代替用户名/密码对。额外的身份验证方法 可以使用插件相当直接地扩展。

这些领域对Apache Kafka.构成了挑战。在安全方面，最近的Kafka 0.9版本附加了TLS,，JAAS基于角色的访问控制，Kerberos/plain/scram认证，使用CLI管理安全策略。 这使得早期版本大幅改善，当时您只能在网络级别锁定访问权限，对于共享或多用户，这不起作用。

Kafka使用管理CLI由shell脚本、 属性文件组成，特别是格式化JSON文件。 Kafka 经纪人，生产者，和消费者排放指标 通过Yammer / JMX，但不维护任何历史，这实际意味着使用第三方监测系统。使用这些工具，操作能够管理分区和主题，检查消费者偏移位置，与使用Apache Zookeeper为Kafka提供的HA和FT功能。例如，一个3节点Kafka 集群 即使两个节点失败也能提供功能。然而，如果你想支持Zookeeper最大数目的失败，你需要额外的5个Zookeeper节点 ，Zookeeper是基于法定人数的系统，只能容忍 N/2+1的失败。这明显的不应该共存与Kafka节点 – 因此，要建立的3节点卡夫卡系统，您需要大约八台服务器。 运营商当推理任何卡夫卡系统的可用性时，考虑到ZK集群属性，无论是资源消耗还是设计。

性能

Kafka照以下设计：100k/sec性能往往是人们选择 Apache Kafka的关键驱动力。它的实现很大依赖开发者能够写出聪明的消费者代码。

当然，每秒消息速率是很难状态和量化，因为他们依赖很多，包括你的环境和硬件，工作负载的性质，使用哪种交货保证 (e.g. 持久性是昂贵的，镜像更是如此), etc.

20K/sec是很容易使用一个Rabbit队列实现的， 事实上跟多一些也不是很难，只要没有太多要求的担保。队列的支持，通过一个， 在本地操作系统线程池上进行协作调度的，轻量级的Erlang线程 – 因此，它自然成为了单队列的关键点或瓶颈，永远不会做比CPU周期内能得到的更多的工作。

增加信息秒速率通常归结为妥善利用可用的并行性环境，通过诸如通过聪明的路由打破交通跨多个队列 (从而可以同时运行不同的队列)。当RabbitMQ实现一百万每秒的消息传递， 它通常会明智的慢下来 – 但通过使用大量的资源，周围 30 RabbitMQ节点。 大多数RabbitMQ使用者享受由三到七个RabbitMQ节点提供的高性能。

Making the Call

市场上的其他高级选项的一些研究。如果你想深入与最流行的选择，查看 Nicolas Nannoni硕士论文 ，它独具特色的一面，比较表在4.4节 (page 39) 两年后仍然相当准确 – 值得一读。

在研究时，尽可能形成涉众和业务的循环。理解商业用例是为你的情况做出正确的选择的最大的单因素 。 然后， 如果你是流行技术粉，你最好的办法就是睡在上面， 让它渗透，让你的本能接管。 你就明白了。

本文作者：佚名

来源：51CTO