什么时候使用 RabbitMQ 而不是 Kafka？
When to use RabbitMQ over Kafka?
有人要求我评估 RabbitMQ 而不是 Kafka，但发现很难找到消息队列比 Kafka 更合适的情况。有谁知道消息队列在吞吐量、持久性、延迟或易用性方面更适合的用例？
RabbitMQ 是一个可靠的 general-purpose 消息代理，它支持多种协议，例如 AMQP、MQTT、STOMP 等。它可以处理高吞吐量。 RabbitMQ 的一个常见用例是处理后台作业或 long-running 任务，例如 file scanning、图像缩放或 PDF 转换。 RabbitMQ 还用于微服务之间，它用作应用程序之间的通信方式，避免了传递消息的瓶颈。
Kafka 是针对high-throughput 摄取数据流 和重放优化的消息总线。当您需要移动大量数据、处理 real-time 中的数据或分析一段时间内的数据时，请使用 Kafka。换句话说，需要收集、存储和处理数据的地方。例如，当您想要在网上商店中跟踪用户 activity 并生成要购买的建议商品时。另一个例子是用于跟踪、摄取、日志记录或安全的数据分析。
Kafka 可以被视为 持久消息代理，应用程序可以在其中处理和 re-process 磁盘上的流数据。 Kafka 有一个非常简单的路由方法。如果您需要以复杂的方式将消息路由到您的消费者，RabbitMQ 有更好的选择。如果您需要支持可能离线的批量消费者或需要低延迟消息的消费者，请使用 Kafka。
为了理解如何从Kafka中读取数据，我们首先需要了解它的消费者和消费者群体。分区允许您通过将数据拆分到多个节点来并行化主题。分区中的每条记录都由其唯一的偏移量分配和标识。此偏移量指向分区中的记录。在最新版本的 Kafka 中，Kafka 为分区中的每条记录维护一个数字偏移量。 Kafka 中的消费者可以定期自动提交偏移量，也可以选择手动控制此提交位置。 RabbitMQ 将保留有关 consumed/acknowledged/unacknowledged 消息的所有状态。我发现 Kafka 比 RabbitMQ 的情况更难理解，在 RabbitMQ 中，消息一旦被确认就会从队列中简单地删除。
RabbitMQ 的队列在空时最快，而 Kafka 保留大量数据且开销很小 - Kafka 专为保存和分发大量消息而设计。 （如果你计划在 RabbitMQ 中排很长的队，你可以看看 lazy queues。）
Kafka 是从头开始构建的，考虑了水平扩展（通过添加更多机器进行扩展），而 RabbitMQ 主要设计用于垂直扩展（通过添加更多功能进行扩展）。
RabbitMQ 有一个 built-in user-friendly 界面，可以让您从网络浏览器监控和处理您的 RabbitMQ 服务器。除其他外，队列、连接、通道、交换、用户和用户权限都可以处理 - 创建、删除和在浏览器中列出，您可以手动监控消息速率和 send/receive 消息。 Kafka 有许多 open-source tools, and also some commercial ones，提供管理和监控功能。我会说 easier/gets 更好地理解 RabbitMQ。
一般来说，如果您想要一个 simple/traditional pub-sub 消息代理，显而易见的选择是 RabbitMQ，因为它的扩展性很可能超过您需要的扩展性。如果我的要求足够简单，可以通过 channels/queues 处理系统通信，并且不需要保留和流式传输，我会选择 RabbitMQ。
主要有两种情况我会选择RabbitMQ；对于 long-running 任务，当我需要 运行 可靠的后台作业时。以及应用程序内部和应用程序之间的通信和集成，即作为微服务之间的中间人；系统只需要通知系统的另一部分开始处理任务，例如网上商店的订单处理（下订单、更新订单状态、发送订单、付款等）。
一般来说，如果您想要一个用于存储、读取 (re-reading) 和分析流数据的框架，请使用 Apache Kafka。 它是以下系统的理想选择审计或那些需要永久存储消息。这些也可以分为两个主要用例，用于分析数据（跟踪、摄取、日志记录、安全等）或 real-time 处理。
更多阅读、用例和一些比较数据可以在这里找到：https://www.cloudamqp.com/blog/2019-12-12-when-to-use-rabbitmq-or-apache-kafka.html
同时推荐行业论文：“Kafka 与 RabbitMQ：两个行业参考 publish/subscribe 实现的比较研究”：http://dl.acm.org/citation.cfm?id=3093908
我在一家同时提供 Apache Kafka 和 RabbitMQ 作为服务的公司工作。
我每周都会听到这个问题...虽然 RabbitMQ（如 IBM MQ 或 JMS 或其他一般消息传递解决方案）用于传统消息传递，但 Apache Kafka 用作流媒体平台（消息传递 + 分布式存储 + 处理数据）。两者都是为不同的用例构建的。
您可以将 Kafka 用于 "traditional messaging"，但不能将 MQ 用于特定于 Kafka 的场景。
文章“Apache Kafka vs. Enterprise Service Bus (ESB)——朋友、敌人还是朋友？ (https://www.confluent.io/blog/apache-kafka-vs-enterprise-service-bus-esb-friends-enemies-or-frenemies/)”讨论了为什么 Kafka 没有竞争力但作为集成和消息传递解决方案（包括 RabbitMQ）的补充以及如何集成两者。
我能想到的唯一好处是Transactional特性，其余的都可以使用Kafka来完成
以分布式容错方式很难同时扩展两者，但我认为使用 RabbitMQ 进行大规模扩展要困难得多。了解 Shovel、Federation、Mirrored Msg Queues、ACK、Mem 问题、容错等并非易事。并不是说您不会在 Kafka 上遇到 Zookeeper 等特定问题，但需要管理的活动部件较少。也就是说，您可以使用 RMQ 进行多语言交换，而 Kafka 则不能。如果要流式传输，请使用 Kafka。如果您想要简单的物联网或类似的大容量数据包传输，请使用 Kafka。这是关于聪明的消费者。如果您希望 msg 具有更高的灵活性和更高的可靠性，但成本更高且可能有些复杂，请使用 RMQ。
RabbitMQ 是一种传统的通用消息代理。它使 Web 服务器能够快速响应请求并将消息传递到多个服务。发布者能够发布消息并将它们提供给队列，以便消费者可以检索它们。通信可以是异步的也可以是同步的。
另一方面，Apache Kafka 不只是 消息代理。它最初是由 LinkedIn 设计和实现的，目的是用作消息队列。从2011年开始，Kafka开源并迅速演化为分布式流媒体平台，用于实时数据管道和流媒体应用的实现。
It is horizontally scalable, fault-tolerant, wicked fast, and runs in
production in thousands of companies.
现代组织拥有各种促进系统或服务之间通信的数据管道。当合理数量的服务需要实时相互通信时，事情会变得有点复杂。
架构变得复杂，因为需要各种集成才能实现这些服务的相互通信。更准确地说，对于包含 m 个源服务和 n 个目标服务的架构，需要编写 n x m 个不同的集成。此外，每个集成都有不同的规范，这意味着可能需要不同的协议（HTTP、TCP、JDBC 等）或不同的数据表示（二进制、Apache Avro、JSON 等） .)，让事情变得更具挑战性。此外，源服务可能会解决可能影响延迟的连接增加的负载。
Apache Kafka 通过解耦数据管道导致更简单和可管理的架构。 Kafka 充当高吞吐量分布式系统，其中源服务推送数据流，使它们可供目标服务实时提取。
此外，现在有许多用于管理 Kafka 集群的开源和企业级用户界面可用。更多细节参考我的文章Overview of UI monitoring tools for Apache Kafka clusters and Why Apache Kafka?
选择 RabbitMQ 还是 Kafka 取决于项目的要求。一般来说，如果您想要一个 simple/traditional 发布-订阅消息代理，那么请选择 RabbitMQ。如果您想构建一个事件驱动的架构，您的组织将在该架构上实时处理事件，那么请选择 Apache Kafka，因为它为这种架构类型（例如 Kafka Streams 或 ksqlDB）提供了更多功能。
5 Kafka 和 RabbitMQ 的主要区别，正在使用的客户：
选择哪个消息系统或者我们应该更改现有的消息系统？
以上问题没有答案。当您必须决定使用哪个消息系统或应该更改现有系统时，一种可能的审查方法是“Evaluate scope and cost”
你们忘记的一个关键区别是 RabbitMQ 是基于推送的消息系统，而 Kafka 是基于拉的消息系统。这在消息系统必须满足具有不同处理能力的不同类型的消费者的场景中很重要。使用基于拉的系统，消费者可以根据他们的能力进行消费，而推送系统将推送消息而不管消费者的状态，从而使消费者处于高风险中。
我将根据我对两者的经验提供一个 objective 答案，我也会跳过它们背后的理论，假设您已经知道 and/or 其他答案已经提供了足够的内容。
RabbitMQ：如果我的要求足够简单，可以通过 channels/queues 处理系统通信，我会选择这个，保留和流不是必需的。例如当制造系统构建资产时，它会通知协议系统配置合同等。
Kafka：主要是Event sourcing需求，当你可能需要处理流（有时是无限的），大量的数据一次适当平衡，replay offsets以确保给定的状态等等。请记住，此体系结构也带来了更多的复杂性，因为它确实包含 topics/partitions/brokers/tombstone 消息等概念，作为第一个 class 重要性。
我知道这有点晚了，也许你已经间接地说过了，但是再说一遍，Kafka 根本不是一个队列，它是一个日志（正如上面有人所说，基于轮询）。
为简单起见，当您更喜欢 RabbitMQ（或任何队列技术）而不是 Kafka 时，最明显的用例是以下一个：
您有多个消费者从队列中消费，只要队列中有新消息和可用消费者，您就希望处理该消息。
如果您仔细观察 Kafka 的工作原理，您会发现它不知道如何执行此操作，因为分区缩放，您将有一个专用于分区的消费者，您将遇到饥饿问题。使用简单的队列技术可以轻松避免的问题。
您可以考虑使用一个线程来从同一分区分派不同的消息，但同样，Kafka 没有任何选择性确认机制。
您最多只能像那些人一样尝试将 Kafka 转换为队列：
https://github.com/softwaremill/kmq
雅尼克
在以下情况下使用 RabbitMQ：
- 您不必处理大数据，您更喜欢方便的内置 UI 进行监控
- 无需自动复制队列
- 消息没有多个订阅者——因为与作为日志的 Kafka 不同，RabbitMQ 是一个队列，一旦消费并收到确认，消息就会被删除
- 如果您有使用通配符和正则表达式的要求
- 如果定义消息优先级很重要
简而言之：
RabbitMQ 适用于简单的用例，数据流量低，具有优先级队列和灵活的路由选项。
海量数据高吞吐使用Kafka
Apache Kafka 是支持数据管道的流行选择。 Apache kafka 添加了 kafka 流以支持流行的 etl 用例。 KSQL 使得在管道内转换数据变得简单，准备好消息干净利落地进入另一个系统。
KSQL 是 Apache Kafka 的流式处理 SQL 引擎。它为 Kafka 上的流处理提供了一个易于使用但功能强大的交互式 SQL 接口，无需使用 Java 或 Python 等编程语言编写代码。 KSQL 是可扩展的、有弹性的、容错的和实时的。它支持广泛的流操作，包括数据过滤、转换、聚合、连接、窗口化和会话化。
https://docs.confluent.io/current/ksql/docs/index.html
Rabbitmq 不是 etl 系统的流行选择，而是那些需要吞吐量较低的简单消息传递系统的系统。
我意识到这是一个老问题，但在处理数据编辑时，RabbitMQ 可能是更好选择的一种情况。
使用 RabbitMQ，默认情况下一旦消息被使用，它就会被删除。使用 Kafka，默认情况下，消息会保留一周。通常将其设置为更长的时间，甚至从不删除它们。
虽然这两种产品都可以配置为保留（或不保留）消息，但如果担心 CCPA 或 GDPR 合规性，我会选择 RabbitMQ。
简短的回答是 "message acknowledgements"。 RabbitMQ 可以配置为需要消息确认。如果接收方失败，则消息返回到队列中，另一个接收方可以重试。虽然您可以使用自己的代码在 Kafka 中完成此操作，但它可以开箱即用地与 RabbitMQ 一起使用。
根据我的经验，如果您的应用程序需要查询信息流，Kafka 和 KSql 是您的最佳选择。如果你想要一个队列系统，你最好使用 RabbitMQ。
投票最多的答案涵盖了大部分内容，但我想强调用例的观点。 kafka能做到rabbit mq能做到的吗，答案是肯定的但是rabbit mq能做到kafka能做到的一切吗，答案是否定的
rabbit mq做不到的让kafka与众不同的地方，就是分布式消息处理。有了这个现在回读投票最多的答案，它会更有意义。
为了详细说明，请举一个用例，您需要创建一个具有超高吞吐量的消息传递系统，例如 facebook 中的“喜欢”，并且您为此选择了 rabbit mq。您创建了一个交换和队列以及一个消费者，所有发布者（在本例中为 FB 用户）都可以在其中发布 'likes' 消息。由于您的吞吐量很高，您将在消费者中创建多个线程来并行处理消息，但您仍然受到消费者 运行 所在机器的硬件容量的限制。假设一个消费者不足以处理所有消息 - 你会怎么做？
- 你能再添加一位消费者到队列中吗？不，你不能那样做。
- 您能否创建一个新队列并将该队列绑定到发布 'likes' 消息的交换，答案是不能，因为您将处理两次消息。
这就是kafka解决的核心问题。它允许您创建分布式分区（rabbit mq 中的队列）和分布式消费者，它们可以相互通信。这样可以确保主题中的消息由分布在各个节点（机器）中的消费者处理。
Kafka 代理确保消息在该主题的所有分区之间实现负载平衡。消费者组确保所有消费者相互交谈并且消息不会被处理两次。
但在现实生活中你不会遇到这个问题，除非你的吞吐量非常高，因为即使只有一个消费者，rabbit mq 也可以非常快速地处理数据。
如果您有复杂的路由需求并且想要一个内置的 GUI 来监控代理，那么 RabbitMQ 可能最适合您的应用程序。否则，如果您正在寻找一个消息代理来处理高吞吐量并提供对流历史的访问，Kafka 可能是更好的选择。
从技术上讲，与 Rabbit MQ 提供的功能集相比，Kafka 提供了一个巨大的超集功能。
如果问题是
Rabbit MQ在技术上比Kafka好吗？
那么答案就是
没有.
但是，如果问题是
从业务角度看Rabbit MQ比Kafka好吗？
那么，答案是
可能'Yes'，在某些业务场景下
Rabbit MQ可以比Kafka更好，从业务的角度来说，原因如下：
依赖于 Rabbit MQ 的遗留应用程序的维护
实施 Kafka 所需的员工培训成本和陡峭的学习曲线
Kafka 的基础架构成本高于 Rabbit MQ。
与 Rabbit MQ 实施相比，Kafka 实施中的故障排除困难。
Rabbit MQ 开发人员可以轻松维护和支持使用 Rabbit MQ 的应用程序。
Kafka 则不同。
仅具有 Kafka 开发经验不足以维护和支持使用 Kafka 的应用程序。
支持人员还需要其他技能，如动物园管理员、网络、磁盘存储。
有人要求我评估 RabbitMQ 而不是 Kafka，但发现很难找到消息队列比 Kafka 更合适的情况。有谁知道消息队列在吞吐量、持久性、延迟或易用性方面更适合的用例？
RabbitMQ 是一个可靠的 general-purpose 消息代理，它支持多种协议，例如 AMQP、MQTT、STOMP 等。它可以处理高吞吐量。 RabbitMQ 的一个常见用例是处理后台作业或 long-running 任务，例如 file scanning、图像缩放或 PDF 转换。 RabbitMQ 还用于微服务之间，它用作应用程序之间的通信方式，避免了传递消息的瓶颈。
Kafka 是针对high-throughput 摄取数据流 和重放优化的消息总线。当您需要移动大量数据、处理 real-time 中的数据或分析一段时间内的数据时，请使用 Kafka。换句话说，需要收集、存储和处理数据的地方。例如，当您想要在网上商店中跟踪用户 activity 并生成要购买的建议商品时。另一个例子是用于跟踪、摄取、日志记录或安全的数据分析。
Kafka 可以被视为 持久消息代理，应用程序可以在其中处理和 re-process 磁盘上的流数据。 Kafka 有一个非常简单的路由方法。如果您需要以复杂的方式将消息路由到您的消费者，RabbitMQ 有更好的选择。如果您需要支持可能离线的批量消费者或需要低延迟消息的消费者，请使用 Kafka。
为了理解如何从Kafka中读取数据，我们首先需要了解它的消费者和消费者群体。分区允许您通过将数据拆分到多个节点来并行化主题。分区中的每条记录都由其唯一的偏移量分配和标识。此偏移量指向分区中的记录。在最新版本的 Kafka 中，Kafka 为分区中的每条记录维护一个数字偏移量。 Kafka 中的消费者可以定期自动提交偏移量，也可以选择手动控制此提交位置。 RabbitMQ 将保留有关 consumed/acknowledged/unacknowledged 消息的所有状态。我发现 Kafka 比 RabbitMQ 的情况更难理解，在 RabbitMQ 中，消息一旦被确认就会从队列中简单地删除。
RabbitMQ 的队列在空时最快，而 Kafka 保留大量数据且开销很小 - Kafka 专为保存和分发大量消息而设计。 （如果你计划在 RabbitMQ 中排很长的队，你可以看看 lazy queues。）
Kafka 是从头开始构建的，考虑了水平扩展（通过添加更多机器进行扩展），而 RabbitMQ 主要设计用于垂直扩展（通过添加更多功能进行扩展）。
RabbitMQ 有一个 built-in user-friendly 界面，可以让您从网络浏览器监控和处理您的 RabbitMQ 服务器。除其他外，队列、连接、通道、交换、用户和用户权限都可以处理 - 创建、删除和在浏览器中列出，您可以手动监控消息速率和 send/receive 消息。 Kafka 有许多 open-source tools, and also some commercial ones，提供管理和监控功能。我会说 easier/gets 更好地理解 RabbitMQ。
一般来说，如果您想要一个 simple/traditional pub-sub 消息代理，显而易见的选择是 RabbitMQ，因为它的扩展性很可能超过您需要的扩展性。如果我的要求足够简单，可以通过 channels/queues 处理系统通信，并且不需要保留和流式传输，我会选择 RabbitMQ。
主要有两种情况我会选择RabbitMQ；对于 long-running 任务，当我需要 运行 可靠的后台作业时。以及应用程序内部和应用程序之间的通信和集成，即作为微服务之间的中间人；系统只需要通知系统的另一部分开始处理任务，例如网上商店的订单处理（下订单、更新订单状态、发送订单、付款等）。
一般来说，如果您想要一个用于存储、读取 (re-reading) 和分析流数据的框架，请使用 Apache Kafka。 它是以下系统的理想选择审计或那些需要永久存储消息。这些也可以分为两个主要用例，用于分析数据（跟踪、摄取、日志记录、安全等）或 real-time 处理。
更多阅读、用例和一些比较数据可以在这里找到：https://www.cloudamqp.com/blog/2019-12-12-when-to-use-rabbitmq-or-apache-kafka.html
同时推荐行业论文：“Kafka 与 RabbitMQ：两个行业参考 publish/subscribe 实现的比较研究”：http://dl.acm.org/citation.cfm?id=3093908
我在一家同时提供 Apache Kafka 和 RabbitMQ 作为服务的公司工作。
我每周都会听到这个问题...虽然 RabbitMQ（如 IBM MQ 或 JMS 或其他一般消息传递解决方案）用于传统消息传递，但 Apache Kafka 用作流媒体平台（消息传递 + 分布式存储 + 处理数据）。两者都是为不同的用例构建的。
您可以将 Kafka 用于 "traditional messaging"，但不能将 MQ 用于特定于 Kafka 的场景。
文章“Apache Kafka vs. Enterprise Service Bus (ESB)——朋友、敌人还是朋友？ (https://www.confluent.io/blog/apache-kafka-vs-enterprise-service-bus-esb-friends-enemies-or-frenemies/)”讨论了为什么 Kafka 没有竞争力但作为集成和消息传递解决方案（包括 RabbitMQ）的补充以及如何集成两者。
我能想到的唯一好处是Transactional特性，其余的都可以使用Kafka来完成
以分布式容错方式很难同时扩展两者，但我认为使用 RabbitMQ 进行大规模扩展要困难得多。了解 Shovel、Federation、Mirrored Msg Queues、ACK、Mem 问题、容错等并非易事。并不是说您不会在 Kafka 上遇到 Zookeeper 等特定问题，但需要管理的活动部件较少。也就是说，您可以使用 RMQ 进行多语言交换，而 Kafka 则不能。如果要流式传输，请使用 Kafka。如果您想要简单的物联网或类似的大容量数据包传输，请使用 Kafka。这是关于聪明的消费者。如果您希望 msg 具有更高的灵活性和更高的可靠性，但成本更高且可能有些复杂，请使用 RMQ。
RabbitMQ 是一种传统的通用消息代理。它使 Web 服务器能够快速响应请求并将消息传递到多个服务。发布者能够发布消息并将它们提供给队列，以便消费者可以检索它们。通信可以是异步的也可以是同步的。
另一方面，Apache Kafka 不只是 消息代理。它最初是由 LinkedIn 设计和实现的，目的是用作消息队列。从2011年开始，Kafka开源并迅速演化为分布式流媒体平台，用于实时数据管道和流媒体应用的实现。
It is horizontally scalable, fault-tolerant, wicked fast, and runs in production in thousands of companies.
现代组织拥有各种促进系统或服务之间通信的数据管道。当合理数量的服务需要实时相互通信时，事情会变得有点复杂。
架构变得复杂，因为需要各种集成才能实现这些服务的相互通信。更准确地说，对于包含 m 个源服务和 n 个目标服务的架构，需要编写 n x m 个不同的集成。此外，每个集成都有不同的规范，这意味着可能需要不同的协议（HTTP、TCP、JDBC 等）或不同的数据表示（二进制、Apache Avro、JSON 等） .)，让事情变得更具挑战性。此外，源服务可能会解决可能影响延迟的连接增加的负载。
Apache Kafka 通过解耦数据管道导致更简单和可管理的架构。 Kafka 充当高吞吐量分布式系统，其中源服务推送数据流，使它们可供目标服务实时提取。
此外，现在有许多用于管理 Kafka 集群的开源和企业级用户界面可用。更多细节参考我的文章Overview of UI monitoring tools for Apache Kafka clusters and Why Apache Kafka?
选择 RabbitMQ 还是 Kafka 取决于项目的要求。一般来说，如果您想要一个 simple/traditional 发布-订阅消息代理，那么请选择 RabbitMQ。如果您想构建一个事件驱动的架构，您的组织将在该架构上实时处理事件，那么请选择 Apache Kafka，因为它为这种架构类型（例如 Kafka Streams 或 ksqlDB）提供了更多功能。
5 Kafka 和 RabbitMQ 的主要区别，正在使用的客户：
选择哪个消息系统或者我们应该更改现有的消息系统？
以上问题没有答案。当您必须决定使用哪个消息系统或应该更改现有系统时，一种可能的审查方法是“Evaluate scope and cost”
你们忘记的一个关键区别是 RabbitMQ 是基于推送的消息系统，而 Kafka 是基于拉的消息系统。这在消息系统必须满足具有不同处理能力的不同类型的消费者的场景中很重要。使用基于拉的系统，消费者可以根据他们的能力进行消费，而推送系统将推送消息而不管消费者的状态，从而使消费者处于高风险中。
我将根据我对两者的经验提供一个 objective 答案，我也会跳过它们背后的理论，假设您已经知道 and/or 其他答案已经提供了足够的内容。
RabbitMQ：如果我的要求足够简单，可以通过 channels/queues 处理系统通信，我会选择这个，保留和流不是必需的。例如当制造系统构建资产时，它会通知协议系统配置合同等。
Kafka：主要是Event sourcing需求，当你可能需要处理流（有时是无限的），大量的数据一次适当平衡，replay offsets以确保给定的状态等等。请记住，此体系结构也带来了更多的复杂性，因为它确实包含 topics/partitions/brokers/tombstone 消息等概念，作为第一个 class 重要性。
我知道这有点晚了，也许你已经间接地说过了，但是再说一遍，Kafka 根本不是一个队列，它是一个日志（正如上面有人所说，基于轮询）。
为简单起见，当您更喜欢 RabbitMQ（或任何队列技术）而不是 Kafka 时，最明显的用例是以下一个：
您有多个消费者从队列中消费，只要队列中有新消息和可用消费者，您就希望处理该消息。 如果您仔细观察 Kafka 的工作原理，您会发现它不知道如何执行此操作，因为分区缩放，您将有一个专用于分区的消费者，您将遇到饥饿问题。使用简单的队列技术可以轻松避免的问题。 您可以考虑使用一个线程来从同一分区分派不同的消息，但同样，Kafka 没有任何选择性确认机制。
您最多只能像那些人一样尝试将 Kafka 转换为队列： https://github.com/softwaremill/kmq
雅尼克
在以下情况下使用 RabbitMQ：
- 您不必处理大数据，您更喜欢方便的内置 UI 进行监控
- 无需自动复制队列
- 消息没有多个订阅者——因为与作为日志的 Kafka 不同，RabbitMQ 是一个队列，一旦消费并收到确认，消息就会被删除
- 如果您有使用通配符和正则表达式的要求
- 如果定义消息优先级很重要
简而言之： RabbitMQ 适用于简单的用例，数据流量低，具有优先级队列和灵活的路由选项。 海量数据高吞吐使用Kafka
Apache Kafka 是支持数据管道的流行选择。 Apache kafka 添加了 kafka 流以支持流行的 etl 用例。 KSQL 使得在管道内转换数据变得简单，准备好消息干净利落地进入另一个系统。 KSQL 是 Apache Kafka 的流式处理 SQL 引擎。它为 Kafka 上的流处理提供了一个易于使用但功能强大的交互式 SQL 接口，无需使用 Java 或 Python 等编程语言编写代码。 KSQL 是可扩展的、有弹性的、容错的和实时的。它支持广泛的流操作，包括数据过滤、转换、聚合、连接、窗口化和会话化。
https://docs.confluent.io/current/ksql/docs/index.html
Rabbitmq 不是 etl 系统的流行选择，而是那些需要吞吐量较低的简单消息传递系统的系统。
我意识到这是一个老问题，但在处理数据编辑时，RabbitMQ 可能是更好选择的一种情况。
使用 RabbitMQ，默认情况下一旦消息被使用，它就会被删除。使用 Kafka，默认情况下，消息会保留一周。通常将其设置为更长的时间，甚至从不删除它们。
虽然这两种产品都可以配置为保留（或不保留）消息，但如果担心 CCPA 或 GDPR 合规性，我会选择 RabbitMQ。
简短的回答是 "message acknowledgements"。 RabbitMQ 可以配置为需要消息确认。如果接收方失败，则消息返回到队列中，另一个接收方可以重试。虽然您可以使用自己的代码在 Kafka 中完成此操作，但它可以开箱即用地与 RabbitMQ 一起使用。
根据我的经验，如果您的应用程序需要查询信息流，Kafka 和 KSql 是您的最佳选择。如果你想要一个队列系统，你最好使用 RabbitMQ。
投票最多的答案涵盖了大部分内容，但我想强调用例的观点。 kafka能做到rabbit mq能做到的吗，答案是肯定的但是rabbit mq能做到kafka能做到的一切吗，答案是否定的
rabbit mq做不到的让kafka与众不同的地方，就是分布式消息处理。有了这个现在回读投票最多的答案，它会更有意义。
为了详细说明，请举一个用例，您需要创建一个具有超高吞吐量的消息传递系统，例如 facebook 中的“喜欢”，并且您为此选择了 rabbit mq。您创建了一个交换和队列以及一个消费者，所有发布者（在本例中为 FB 用户）都可以在其中发布 'likes' 消息。由于您的吞吐量很高，您将在消费者中创建多个线程来并行处理消息，但您仍然受到消费者 运行 所在机器的硬件容量的限制。假设一个消费者不足以处理所有消息 - 你会怎么做？
- 你能再添加一位消费者到队列中吗？不，你不能那样做。
- 您能否创建一个新队列并将该队列绑定到发布 'likes' 消息的交换，答案是不能，因为您将处理两次消息。
这就是kafka解决的核心问题。它允许您创建分布式分区（rabbit mq 中的队列）和分布式消费者，它们可以相互通信。这样可以确保主题中的消息由分布在各个节点（机器）中的消费者处理。
Kafka 代理确保消息在该主题的所有分区之间实现负载平衡。消费者组确保所有消费者相互交谈并且消息不会被处理两次。
但在现实生活中你不会遇到这个问题，除非你的吞吐量非常高，因为即使只有一个消费者，rabbit mq 也可以非常快速地处理数据。
如果您有复杂的路由需求并且想要一个内置的 GUI 来监控代理，那么 RabbitMQ 可能最适合您的应用程序。否则，如果您正在寻找一个消息代理来处理高吞吐量并提供对流历史的访问，Kafka 可能是更好的选择。
从技术上讲，与 Rabbit MQ 提供的功能集相比，Kafka 提供了一个巨大的超集功能。
如果问题是
Rabbit MQ在技术上比Kafka好吗？
那么答案就是
没有.
但是，如果问题是
从业务角度看Rabbit MQ比Kafka好吗？
那么，答案是
可能'Yes'，在某些业务场景下
Rabbit MQ可以比Kafka更好，从业务的角度来说，原因如下：
依赖于 Rabbit MQ 的遗留应用程序的维护
实施 Kafka 所需的员工培训成本和陡峭的学习曲线
Kafka 的基础架构成本高于 Rabbit MQ。
与 Rabbit MQ 实施相比，Kafka 实施中的故障排除困难。
Rabbit MQ 开发人员可以轻松维护和支持使用 Rabbit MQ 的应用程序。
Kafka 则不同。 仅具有 Kafka 开发经验不足以维护和支持使用 Kafka 的应用程序。 支持人员还需要其他技能，如动物园管理员、网络、磁盘存储。