2
传统消息代理和流数据
根据Kafka网站： “ Kakfa用于构建实时数据管道和流应用程序。 ” 在广泛的互联网上搜索，我发现以下“ 流数据 ”是什么？ 流数据是通过网络从源连续地流到目的地的数据。和 流数据本质上不是原子的，这意味着流的数据流的任何部分都是有意义的和可处理的，与文件的字节相反，除非您拥有全部字节，否则它什么都没有。和 流数据可以随时启动/停止；和 消费者可以随意附加和分离数据流，并只处理他们想要的部分数据 现在，如果我上面所说的任何内容不正确，不完整或完全错误，请先纠正我！假设我或多或少都在轨道上，那么... 现在，我了解了什么是“流数据”，然后，我了解了Kafka和Kinesis在将自己称为具有流数据的应用程序的处理/中介中间件时的含义。但这激起了我的兴趣：可以/应该像传统的消息代理一样，将Kafka或Kinesis之类的“流中间件”用于非流数据吗？反之亦然：是否可以/应该使用RabbitMQ，ActiveMQ，Apollo等传统MQ来传输数据？ 让我们以一个示例为例，其中应用程序将发送其后端常量的需要处理的JSON消息，并且处理过程相当复杂（验证，数据转换，过滤，聚合等）： 情况1：消息是电影的每一帧；每个视频帧包含一个JSON消息，其中包含帧数据和一些支持的元数据 情况2：消息是时间序列数据，可能是某人的心跳随时间变化的函数。因此，发送了＃1表示我在t = 1时的心跳，消息＃2包含了我在t = 2时的心跳，依此类推。 情况3：数据是完全不同的，并且按时间或作为任何“数据流”的一部分不相关。可能随着数百名用户导航应用程序的单击按钮并采取措施而引发的审核/安全事件 根据Kafka / Kinesis的结算方式以及我对“流数据”的理解，它们似乎是案例1（连续的视频数据）和案例2（连续的时间序列数据）的明显候选者。但是，我看不出任何原因，如RabbitMQ之类的传统消息代理也无法有效地处理这两种输入。 在案例3中，仅向我们提供了一个已发生的事件，我们需要处理对该事件的反应。所以对我来说，这意味着需要像RabbitMQ这样的传统经纪人。但是，也没有理由不能让Kafka或Kinesis也不能处理事件数据。 因此，基本上，我正在寻求建立一个表述：我有具有Y特征的X数据。我应该使用像Kafka / Kinesis这样的流处理器来处理它。或者，相反，它可以帮助我确定：我拥有具有Z特征的W数据。我应该使用传统的消息代理来处理它。 因此，我想问：关于数据的哪些因素（或其他因素）有助于指导流处理器或消息代理之间的决策，因为两者都可以处理流数据，并且两者都可以处理（非流）消息数据？