卡夫卡河与卡夫卡河

你的问题很笼统,所以我将从我的角度给出一个笼统的回答。

首先,我有两个使用场景:

现在我们只关注上面描述的第一个场景。让我们看看如果我决定停止使用卡夫卡流,我会失去什么:

• 我的一些流处理器阶段需要一个持久(分布式)状态存储,kafka streams为我提供了它。这是akka streams没有提供的。
• 通过扩展,kafka streams会在流处理器的新实例启动或一个实例被杀死时自动平衡负载。这可以在同一个JVM内工作,也可以在其他节点上工作:向上扩展和向外扩展。这不是由akka streams提供的。

与Kafka流相比,Akka流的最大优点是可以实现非常复杂的处理图,这些处理图可以通过扇入/扇出和反馈循环进行循环。如果我没有错的话,卡夫卡流只允许非循环图。在Kafka流上实现循环处理图将非常复杂

发现本文很好地总结了分布式设计关注的问题 Kafka Streams 提供(补充 Akka Streams

https://www.beyondthelines.net/computing/kafka-streams/

分区 :Kafka将主题拆分为多个分区,每个分区在不同的代理之间复制。分区允许分散负载,复制使应用程序具有容错性(如果代理停止,数据仍然可用)。这有利于数据分区,但我们还需要以类似的方式分布进程。Kafka Streams使用依赖于Kafka组管理的处理器拓扑。这与卡夫卡消费者用于在代理之间均匀分配负载的组管理相同(这项工作主要由代理管理)。

容错性 :数据复制确保数据容错。组管理内置了容错功能,因为它可以在剩余的活动代理实例中重新分配工作负载。

国家管理

:当启动应用程序的新版本时,我们可以从一开始重新处理日志以计算新状态,然后将流量重定向到新实例并关闭旧应用程序。

时间管理 :流数据永远不完整,总是会无序到达,因此必须区分事件时间和处理时间,并正确处理。

“使用此更改日志主题Kafka Stream可以维护应用程序状态的表视图。”

对于使用“大数据”的数据科学应用程序,由数据挖掘、机器学习模型和业务逻辑组合而成的“应用程序状态”很可能无法很好地管理 .

此外,我认为使用 “纯功能事件源运行时” https://github.com/notxcain/aecor

换句话说,业务逻辑不会与 Kafka API。

Akka Streams是Akka Actors模型中以数据流为中心的抽象。

然而,就Kafka流而言,它们是用于处理无限数据的客户端库。它们用于从卡夫卡主题中读取数据,然后进行处理,并将结果写入新主题。

我使用了这两种方法,我很清楚它们的优缺点。

如果您只专注于卡夫卡,并且对流处理没有太多经验,那么卡夫卡流是帮助理解流概念的现成解决方案。在我看来,它的阿喀琉斯之踵是它的数据存储,RockDB用KTable或内部状态存储来帮助有状态场景。

如果您使用Kafka Streams库,RockDB将透明地安装在后台,这对初学者来说很好,但对有经验的开发人员来说很麻烦。RockDB是一个像Cassandra一样的键/值数据库,它有Cassandra最大的优点,但也有缺点,其中一个主要缺点是你只能用主键查询事物,这对于大多数现实生活场景来说是巨大的限制。有一些方法可以实现您自己的数据存储,但它们没有很好的文档记录,可能是一个巨大的挑战。此外,RockDB在加载单个值时确实很棒,但如果您对数据集进行迭代,在数据集大小达到100000后,性能会显著下降。

不幸的是,虽然RockDB嵌入在Kafka流中如此之深,但实现一个 CQRS

如上所述,当卡夫卡消费者一个接一个地提供记录时,它没有背压的概念,在一个场景中,你必须扩展,这可能是一个很好的瓶颈。

那么,与卡夫卡流相比,阿卡流有哪些优点和缺点呢。首先,Akka不是那么开箱即用的框架,你必须更好地理解概念,它不是单一的 persistence Akka Projection )因此,您不必仅通过主键查询数据。Akka开发人员考虑了大量的扩展和反压力,向 Kafka code base 以提高性能。

因此,如果您只使用Kafka,并且不熟悉流处理,您可以使用Kafka流,但要做好准备,在某个时候,您可以碰壁并切换到Akka流。

你想看看工作细节/例子,我有两个博客,你可以看看, blog1 blog2