我目前正在与Akka Stream Kafka合作，与Kafka互动，我想知道与KafkaStream有什么不同。
我知道基于Akka的方法实现了反应规范并处理背压，而kafka流似乎缺乏这些功能。
使用卡夫卡流比使用阿卡流卡夫卡流有什么优势？
你的问题很一般，所以我会从我的角度给出一个一般的答案。
首先，我有两个使用场景：
- 我从kafka读取数据、处理数据并将一些输出写回kafka的情况，对于这些情况，我只使用kafka流
- 数据源或接收器不是kafka的情况，对于那些我使用akka流的情况
这已经让我能够回答关于背压的部分：对于上面的第一种情况，卡夫卡流中存在背压机制。
现在我们只关注上面描述的第一个场景。让我们看看如果我决定停止使用Kafka流，我会失去什么：
- 我的一些流处理器阶段需要一个持久(分布式)状态存储，kafka流为我提供了它。这是akka流没有提供的
- 按比例缩放，一旦流处理器的新实例启动，或者一旦一个实例被杀死，kafkastreams就会自动平衡负载。这在同一JVM中以及在其他节点上都可以工作：向上扩展和向外扩展。这不是由阿卡河提供的
这些是对我来说最重要的区别，我希望这对你有意义！
Akka Stream相对于Kafka Streams的最大优势是可以实现非常复杂的处理图，这些处理图可以通过扇入/扇出和反馈循环进行循环。Kafka流只允许在我没有错的情况下使用非循环图。在Kafka流之上实现循环处理图将非常复杂
发现这篇文章是为了很好地总结Kafka Streams提供的分布式设计关注点(补充Akka Streams)。
https://www.beyondthelines.net/computing/kafka-streams/
消息排序：Kafka维护一种只追加的日志，在其中存储所有消息。每个消息都有一个序列id，也称为其偏移量。偏移量用于指示消息在日志中的位置。Kafka流使用这些消息偏移量来维持排序。
分区：Kafka将主题划分为多个分区，每个分区在不同的代理之间复制。分区允许分散负载，复制使应用程序具有容错性(如果代理关闭，数据仍然可用)。这对数据分区很好，但我们也需要以类似的方式分配进程。Kafka Streams使用依赖于Kafka组管理的处理器拓扑结构。这与Kafka消费者用于在经纪人之间均匀分配负载的组管理相同(这项工作主要由经纪人管理)。
容错：数据复制确保数据容错。组管理具有内置的容错功能，因为它在剩余的活动broker实例之间重新分配工作负载。
状态管理：Kafka流提供了一个由Kafka更改日志主题备份的本地存储，该主题使用日志压缩(只保留给定密钥的最新值)。Kafka日志压缩
重新处理：当启动新版本的应用程序时，我们可以从一开始就重新处理日志以计算新状态，然后将流量重定向到新实例并关闭旧应用程序。
时间管理："流数据永远不完整，总是可能无序到达"，因此必须区分事件时间和处理时间，并正确处理。
作者还说"使用这个更改日志主题，Kafka Stream能够维护应用程序状态的"表视图">
我认为这主要适用于企业应用程序；应用状态"；是小的
对于使用"；"大数据"；，"；应用状态"；通过数据挖掘、机器学习模型和业务逻辑的组合来协调所有这些可能不会用Kafka Streams很好地管理。
此外，我认为使用"；纯功能事件源运行时">喜欢https://github.com/notxcain/aecor将有助于使突变明确化，并通过对状态突变和IO"的原则性管理将应用逻辑与用于管理状态的持久形式的技术分离；效果"；(功能编程)。
换句话说，业务逻辑不会与Kafkaapi纠缠在一起。
Akka Streams作为Akka Actors模型的以数据流为中心的抽象出现。这些是为JVM构建的高性能库，专门为通用微服务设计。
而就Kafka Streams而言，它们是用于处理无边界数据的客户端库。它们用于读取卡夫卡主题中的数据，然后对其进行处理，并将结果写入新的主题。
我同时使用了这两种方法，我对它们的优势和劣势有了很好的了解。
如果你只专注于Kafka，并且没有太多流处理经验，那么Kafka Streams是一个很好的开箱即用的解决方案，可以帮助你理解流概念。在我看来，它的致命弱点是它的数据存储，RockDB来帮助KTable或内部State Stores的有状态场景。
如果您使用Kafka Streams库，RockDB会透明地在后台安装自己，这对初学者来说很好，但对经验丰富的开发人员来说很麻烦。RockDB是一个像Cassandra一样的密钥/值数据库，它既有Cassandra的优点，也有缺点，其中一个主要问题是你只能用主键查询东西，这对于大多数现实生活场景来说都是巨大的限制。有一些方法可以实现您自己的数据存储，但它们没有很好的文档记录，可能是一个巨大的挑战。此外，RockDB加载单个值确实很好，但如果你对事物进行迭代，在数据集大小为100000之后，性能会显著下降。
不幸的是，尽管RockDB深深地嵌入了Kafka Streams中，但用它实现CQRS解决方案也不是那么容易
如上所述，它没有背压的概念，而Kafka Consumer一个接一个地给Records，在这种情况下，你必须扩大规模，这可能是一个很好的瓶颈。对于Kafka Streams不需要背压机制的说法，要非常小心，因为这篇Netflix博客指出，它确实会造成不愉快的影响。
">第二天早上，收到了关于高内存消耗和GC延迟的警报，以至于服务对HTTP请求没有响应。对JVM内存转储的调查揭示了一个内部Kafka消息并发队列，其大小已不可控制地增长到130多万个元素。这种异常队列增长的原因是由于Spring KafkaListener缺乏本机背压支持"；
那么，与卡夫卡流相比，阿卡流的优势和劣势是什么呢。首先，Akka不是那么开箱即用的框架，你必须更好地理解概念，它没有单一的持久性选项，你可以选择任何你想要的。它直接支持CQRS模式(Akka Projection)，因此您不必仅通过主键查询数据。Akka开发人员考虑了大量的扩展和背压，将大量代码提交给Kafka代码库以提高性能。
因此，如果你只使用Kafka，并且是流处理的新手，你可以使用KafkaStreams，但要做好准备，在某个时候你可以碰壁并切换到AkkaStream。
你想看看工作细节/例如，我有两个关于它的博客，你可以查看这些，博客1博客2