消息队列和事件流是事件驱动架构的关键组件，但它们之间究竟有什么异同？在什么情况下应该选择哪一个？
Tun Shwe 是 Quix 的数据副总裁，负责数据战略和开发人员关系。 他专注于帮助公司利用流处理的前沿来设想和执行战略数据愿景。 在他面前。 实施事件驱动架构 （EDA） 是一项具有挑战性的任务。 其中之一是为工作选择合适的工具。 许多事件驱动的工具乍一看似乎很相似，您可能希望它们在相同的目的下也能同样出色地工作。 但事实往往并非如此，选择适合您需求的最佳解决方案可能很棘手。
以消息传递技术为例。 选择消息起初似乎很简单。 但是，“消息传递”是一个总称，通常用于描述不同类型的组件，例如事件总线、发布-订阅消息传递服务、消息队列系统和事件流平台。
虽然所有这些组件的功能和用例都存在一些重叠，但也存在许多显着差异。 在采用其中一种消息传递技术（或混合使用它们）之前，了解这些差异至关重要。
我将重点介绍消息队列和事件流，重点介绍它们的差异、共性以及对各种用例的适用性。 作为后续阅读，我建议阅读“事件驱动的事件流堆栈指南”，该指南涵盖了 EDA 的所有组件，并引导您完成参考用例和决策树，以了解每个组件适用的场景。 在讨论消息队列和事件流之前，让我们先澄清一下“消息”和“事件”的含义。 消息是一个通用术语，用于描述从一个组件发送到另一个组件的数据包。 有不同类型的消息，包括：
命令消息。它携带来自接收器的指令来执行特定操作。
查询消息。从组件请求信息。
回复消息。服务器或接收方回复请求查询消息。
事务性消息。在消息是事务的一部分并且必须以可靠的（通常是原子）方式进行处理的系统中使用。
下面是一个基本示例，演示了指示银行系统启动资金转账的命令消息：
同时，事件是系统内的重大事件或状态更改。 单击UI中的按钮，运动传感器记录移动或成功处理付款 - 这些都是事件的示例。 当事件在系统组件之间“传播”时，它以消息的形式进行，因此事件是一种消息。下面是一个事件消息示例，该消息记录了上述命令消息已处理完毕，并且资金已成功在账户之间转移。
由于事件被打包到消息中，因此在讨论事件驱动的体系结构时，您经常会听到术语“消息”和“事件”可以互换使用。 但是，值得注意的是，虽然事件是消息，但并非所有消息都是事件。现在，让我们继续讨论消息队列和事件流。 消息队列通过为即将由使用者处理的消息提供临时存储来运行。 生产者将消息发送到消息，消息将其存储在队列中。 使用者从队列中检索消息，通常采用先进先出 （FIFO） 顺序。 一旦从队列中使用（并确认），该消息将被删除。 此设置将组件解耦，确保使用者可靠且有序地处理消息。
消息队列概述。
与消息队列类似，事件流围绕生产者、使用者、消息和消息展开。 但是，与消息队列相比，存在一些显著差异：
事件流涉及事件消息的连续流。 （通常，使用消息队列不会涉及如此高的数据量和速率）。
*事件消息通常存储在主题（或频道）中。 与对等队列不同，在对等队列中，单个收件人使用每条消息，主题使用允许多个使用者读取同一消息的发布-订阅模型。
消息可以按顺序存储更长的时间。 （食用后不会立即丢弃）。
消息队列的主要目的是可靠地将消息从 A 点传递到 B 点，而事件流则遵循不同的范式。 事件流确实做同样的事情，但除了分发之外，它通常在事件数据传递到目标之前进行实时转换（因此高级过程是>数据转换> b）。 数据转换通常涉及使用 Kafka Streams 或 Apache Flink 等流处理技术。
事件流概述。
用于实现事件流的技术与用于消息队列的技术之间存在许多差异。 为了突出这些差异，我将比较 Apache Kafka（一个事件流平台）和 RabbitMQ（它为消息队列提供消息**），我选择了 Kafka 和 RabbitMQ，特别是因为它们是流行的、广泛使用的解决方案，提供丰富的功能，并在生产中进行了广泛的实战测试。 它们被许多人认为是标准。 
上表只是对 Kafka 的事件流处理能力和 RabbitMQ 的消息队列进行了简要对比，并总结了它们之间的基本区别。 但是，如果您想更深入地了解这两种技术的比较（包括架构、开发人员体验和生态系统等其他标准），请查看这篇 Kafka 与 RabbitMQ 博客文章。 消息队列和事件流都可用于需要在系统不同部分之间进行解耦、异步通信的方案。 例如，在微服务体系结构中，两者都可以在组件之间提供低延迟的消息传递。 但是，除了消息传递之外，事件流和消息队列也有其自身的优势，适用于不同的用例。
消息队列技术通常用于：
用不同语言编写的组件之间以及“使用”不同协议之间的通信。 RabbitMQ 和 ActiveMQ 等消息队列解决方案通过支持多种协议和编程语言来实现这一点。
需要复杂消息路由的用例（例如，交易平台根据订单的类型和大小将买卖订单路由到不同的处理队列）。
在工作节点之间分配任务，其中每个任务仅由单个使用者处理一次。
与经常断开连接的消费者打交道。 在这些情况下，消息队列系统是一个不错的选择，因为它能够对消息进行排序、临时持久性和重新发送消息。
全球数以千计的公司已将消息队列技术整合到其技术堆栈中。 例如，您可以查看 RabbitMQ 峰会**，了解各种形式和规模的组织如何在生产中使用 RabbitMQ 消息队列。 **有很多讨论供您浏览（只需单击“过去的活动”下拉菜单，然后选择您选择的峰会版本即可查看所有相关讨论）。 现在，让我们继续讨论事件流处理，它非常适合：
收集、保存和传输大量事件流，例如点击流数据、市场以及来自 IoT 设备和传感器的高频读数。
持续处理和分析数据，以提供可操作的见解并支持实时决策（例如，在金融交易发生时对其进行分析，以尽快识别和减轻欺诈）。
事件溯源。 在这种情况下，像 Kafka 这样的技术是理想的，因为它的不可变和仅追加的日志结构确保了可靠、有序和可重放的事件记录。 这允许存储和查询历史状态更改的完整序列。
日志聚合用例。 事件流处理解决方案是一个合适的选择，因为它们通常提供良好的性能、强大的持久性保证和低延迟。 此外，事件流处理技术通常与许多其他系统集成（或提供直接集成方式），从而可以轻松地从不同组件引入日志数据。
有无数公司正在利用事件流处理。 例如，包括Uber，PayPal和Netflix在内的一些大型组织已经分享了他们使用Kafka的方式和原因以及他们获得的好处。 他们的经历值得一读。 但是，不仅仅是大型企业依赖于事件流处理。 查看我的上一篇文章，了解中小型公司如何利用 Kafka 的事件流处理功能。 请注意，某些事件驱动的体系结构同时使用事件流处理和消息队列。 例如，在电子商务平台的情况下，您可以使用事件流处理来实时收集和分析用户的点击流数据，以便为他们提供相关的横幅、优惠折扣和产品推荐。 同时，消息队列解决方案可用于对订单进行排队以进行付款和处理。
对于许多消息传递用例，消息队列是一个不错的选择。 如果您处于事件驱动之旅的早期阶段，消息队列技术通常比事件流处理解决方案更易于部署和管理，因此非常引人注目。 但是，尽管增加了复杂性，但组织有时会从消息队列迁移到事件流。 主要原因是什么？可扩展性、可靠性和性能。
这正是 Doordash、AppDirect 和全球支付提供商所发生的事情。 它们最初都使用消息队列技术，特别是 RabbitMQ 和 ActiveMQ。 然而，面对不断增长的数据量，这些消息队列系统遇到了严重的可扩展性、可靠性和性能问题。 这三家公司最终都不得不重新评估他们的技术堆栈，并用 Kafka 的事件流处理功能取代 RabbitMQ ActiveMQ。 通过迁移到 Kafka，这三个组织显著提高了系统正常运行时间、可扩展性、可用性和性能（更低的延迟和更高的吞吐量）。 我很好奇未来是否会有更多企业继续从消息队列转向事件流。 另一个可能的趋势是，公司将从一开始就采用事件流平台，特别是考虑到 Kafka 的队列调度的引入。 换句话说，Kafka 最终可能会成为一种同样适用于事件流用例和传统消息队列场景的技术（目前将 Kafka 用作传统消息队列具有挑战性 - 有关详细信息，请参阅本文中的详细信息）。 如果您正在处理中小型工作负载，并且希望在组件之间可靠灵活地路由消息，并且您的系统主要关注当前状态，则消息队列技术是一个不错的选择。
另一方面，如果您希望以可扩展且可靠的方式处理大容量、高频的事件流，并且需要复杂的处理才能在数据到达时获得实时见解，并且您的系统不仅关注当前状态，还关注状态变化的历史记录，那么事件流处理是正确的选择。
正如我们所看到的，有时公司开始只使用消息队列，然后迁移到事件流技术。 这种迁移非常困难且耗时。 因此，如果您正处于事件驱动之旅的早期阶段，并且正在考虑事件流式处理或消息队列是否适合您，请问问自己：两者能否平等地满足当前需求？如果答案是肯定的，那么我建议你选择事件流式处理。 它是未来更强大、更可靠的基础。
确实，事件流工具通常比消息队列更难学习和管理。 但不要因此而气馁。 Confluent Cloud 和 Redpanda 等托管平台大大简化了处理事件流的工作。 此外，它们还可以与 Quix 等无服务器流处理解决方案无缝协作，使您能够轻松构建、部署和监控从实时数据中提取价值的事件流应用程序。 查看这些交互式模板，了解通过将 Confluent Cloud Kafka Redpanda 作为流式处理和 Quix 作为流式处理引擎，您可以创建哪些事件驱动型应用程序。