logo标签列表

流处理和消息处理的区别

streamqueuerabbitmqapache-kafkamessaging
120
流处理和传统消息处理的基本区别是什么？人们说kafka是流处理的好选择，但实际上kafka与ActivMQ、RabbitMQ等消息框架类似。
为什么一般不说ActiveMQ也适用于流处理呢？
是消费者消费消息的速度决定是否是流处理吗？
1
Kafka绝对不是“类似于ActivMQ、RabbitMQ等消息框架”的东西，正如这篇文章所描述的那样：https://azure.microsoft.com/en-us/blog/events-data-points-and-messages-choosing-the-right-azure-messaging-service-for-your-data/。 - Udi Dahan
7个回答
147
在传统的消息处理中，你对消息应用简单的计算 -- 在大多数情况下是针对每个消息的单独处理。
在流处理中，你对多个输入流和多条记录(即消息)同时进行复杂的操作（如聚合和联接）。
此外，传统的消息传递系统无法“回溯” -- 即它们会在将消息传递给所有已订阅的消费者后自动删除消息。相比之下，Kafka 保留了消息，因为它使用拉取模型（即消费者从 Kafka 拉取数据）在可配置的时间段内保存消息。这使得消费者可以“倒带”并多次消费消息--或者如果您添加一个新的消费者，它可以读取完整的历史记录。这使得流处理成为可能，因为它允许更复杂的应用程序。此外，流处理不一定是关于实时处理--它是关于处理无限输入流（相对于应用于有限输入的批处理）。
而且 Kafka 提供 Kafka Connect 和 Streams API -- 所以它是一个流处理平台，而不仅仅是一个消息/发布-订阅系统（即使它在其核心中使用这个）。
14

如果你喜欢纠结细节： 消息传递是两个或多个进程或组件之间的通信，而流式传输是按照事件发送日志的过程。消息携带原始数据，而事件包含有关订单等发生和活动的信息。 因此，Kafka同时执行消息传递和流式传输。 Kafka中的主题可以是原始消息，也可以是通常保留数小时或数天的事件日志。事件可以进一步聚合成更复杂的事件。

4

虽然Rabbit支持流处理，但它实际上并不是为此而建立的（请参见Rabbit的网站）。 Rabbit是消息代理，Kafka是事件流平台。

Kafka可以处理大量面向Rabbit的“消息”。 Kafka是一种日志，而Rabbit是一个队列，这意味着如果被消耗了，Rabbit的消息就不再存在了（如果你需要的话）。

然而，Rabbit可以指定消息优先级，而Kafka则不能。

这取决于您的需求。

3
基本上，Kafka 是一种类似于 ActiveMQ 或 RabbitMQ 的消息框架。目前有一些工作正在将 Kafka 向流式处理方向发展。

https://www.confluent.io/blog/introducing-kafka-streams-stream-processing-made-simple/

当涉及流处理时，为什么要提到Kafka？
流处理框架的数据输入方式不同。在批处理中，您有一些存储在文件系统中的文件，并且希望持续处理并存储到某个数据库中。而在像Spark、Storm等流处理框架中，将从一些传感器设备、API源获取连续输入，并使用Kafka来提供流引擎的数据源。
3

抱歉回答比较长，但我认为简短的回答无法公正地回答问题。

考虑队列系统，例如MQ，用于：

  • 确保精确一次投递，并参与到两阶段提交事务中
  • 异步请求/响应通信：通信的语义是让一个组件要求第二个命令对其数据执行某些操作。这是一种具有响应延迟的命令模式。
  • 注意消息在队列中一直保留，直到被消费者得到。

考虑流系统，例如Kafka，作为发布/订阅和持久性系统，用于：

  • 发布事件作为应用程序中发生的不可变事实
  • 连续获取数据流的可见性
  • 为了重放性，保留已消耗的数据以供将来的消费者使用
  • 水平扩展消息消费

什么是事件和消息

IT系统中有很长的消息传递历史。您可以在消息系统和消息的上下文中轻松看到事件驱动的解决方案和事件。但是，值得考虑的有不同的特征：

消息：消息传输有效载荷，并保留消息直到被消费。消息的消费者通常直接定向和相关到关心消息是否已经被交付和处理的生产者。

事件：事件作为可重放流历史记录而存在。事件消费者不绑定于生产者。事件是发生过的事情的记录，因此无法更改。（您不能改变历史）

enter image description here

现在比较消息传递和事件流

消息用于支持：

  • 短暂数据：数据仅存储到消费者处理消息或其过期为止。
  • 请求/响应：大多数时候。
  • 目标可靠投递：针对将处理请求或接收响应的实体进行定位。具有事务支持的可靠性。
  • 时间耦合:生产者和消费者：消费者可以订阅队列，但是消息可能在一定时间后或所有订阅者获取消息后被删除。耦合仍然松散在数据模型级别和接口定义级别。

事件用于支持：

  • 流历史记录：消费者对历史事件感兴趣，而不仅仅是最近的事件。
  • 可扩展的消费：随着消费者数量的增加，单个事件可以被多个消费者消耗，影响有限。
  • 不可变数据
  • 松散耦合/解耦的生产者和消费者：由于消费者可能随时到达，因此具有强时间解耦。在消息定义级别上存在一些耦合，但模式管理最佳实践和模式注册表能够减少阻力。

希望这个答案能够帮助您！

3

消息处理涉及操作和/或使用单个消息。流处理则包括对单个消息进行操作和/或使用，以及对进入系统的消息集合进行操作。例如，假设有付款工具的交易正在进行 - 流处理可用于连续计算每小时平均支出。在这种情况下 - 可以向流中强加滑动窗口，选择在一小时内接收的消息并计算金额的平均值。然后可以将这些数字用作欺诈检测系统的输入。

1

最近，我看到了一份非常好的文件，介绍了“流处理”和“消息处理”的用法。

https://developer.ibm.com/articles/difference-between-events-and-messages/

在异步处理中考虑：

消息传递：
当存在“请求处理”即客户端请求服务器进行处理时，请考虑使用此方法。

事件流：
当“访问企业数据”即企业内的组件可以发出描述其当前状态的数据时，请考虑使用此方法。这些数据通常不包含针对其他系统完成操作的直接指令。相反，组件允许其他系统了解其数据和状态。

为了促进此评估，请考虑以下关键选择标准以选择适合您解决方案的正确技术：

  • 事件历史记录 - Kafka
  • 细粒度订阅 - MQ
  • 可扩展消费 - Kafka
  • 事务行为 - MQ
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接