Kafka Streams, 我还会再使用它吗？

大家好，欢迎来到IT知识分享网。

Deepti Mittal 4分钟阅读

Kafka Stream流, 黑匣子

Kafka Streams是一个用于构建应用程序和微服务的客户端库，其中的输入和输出数据都存储在Apache Kafka集群中。它将在客户端编写和部署标准的Java和Scala应用程序的简单性与Kafka的服务器端集群技术的优势相结合。

我们在一个数据量很大的项目中使用了kafka流。后来我们发现Kafka流对于我们的用例来说不是一个好的选择。

用例细节

收集发布在多个Kafka主题中的记录数量，当时间表启动/收到特定的触发器时，对这些记录运行算法，并发布在另一个Kafka主题中，供下游系统使用。

这听起来像是一个简单的用例，在我们开始用实际数据运行之前，没有人能够想到这将导致任何问题。我们的记录大小约为5KB。为了运行算法，我们需要在某些层面上聚合它们，这导致了5GB或更大的单一kafka记录。

所以我们开始挖掘Kafka流是否能够支持这种使用情况。这篇博客是关于我们对Kafka流的实际经验，在哪些地方可以使用，哪些地方需要避免。

很适合Kafka流

• 快速原型设计。如果你有想要快速建立原型的想法，Kafka流可能是不错的选择。它提供了很多高水平的API，可以帮助快速测试算法和概念。使用kafka流提供的过滤、聚合和转换API可以使开发变得非常快。
• 小型处理或数据验证。在这种情况下，我们从一个主题中获取数据，并在将其提供给下游系统之前进行小规模的处理和验证，Kafka流可能是很合适的。请记住，处理必须是非常小的，否则你会开始得到像producerFenced和TransactionCommitOperation失败的异常。
• 弹性和容错。Kafka流使用本地状态存储和变化日志主题，数据在聚合过程中被保存，可以在故障情况下使用，整个处理过程不需要重新开始。整个交易和错误处理的概念都由库来处理，开箱即用。

关于Kafka流的问题

• 需要有小型交易。如果你需要在传入的数据上运行复杂的算法，并且需要花费超过几毫秒的时间，那么Kafka流可能不是很合适，因为它会导致超时。人们总是可以争辩说你可以增加超时，但是Kafka在消费者、经纪人、生产者和流层面都有多种超时，而且其中很多都是相关的。让整个组合正确并不是一件容易的事。你永远不可能100%确定这些超时会在所有的数据和生产场景中发挥作用。
• 大的有效载荷。这是我们远离Kafka流的主要原因。为了执行其中的一个算法，我们需要在更高的层面上汇总所有的记录，这就导致了一个大小为5GB的记录进入到变化日志主题中。Kafka流无法将这个巨大的信息保存到主题中，导致了多次失败和巨大的性能下降。Kafka流的建议是记录大小不超过10MB。
• 批量处理。这是一个流媒体解决方案，应该作为流媒体使用，如果你试图执行需要收集多条记录的操作，你可能会遇到像我上面提到的问题。这也可能导致更大的交易，因此你会得到很多错误。
• 可调试性。在Kafka中，大量的producerFenced异常、提交事务失败的异常没有很好的描述，在Kafka流中分析和调试它们变得更加困难，因为你将使用高DSL函数构建拓扑结构，它成为分析错误的黑盒子。使用Spring Kafka实现的那部分解决方案对我们来说很容易分析和解决，但Kafka流的问题却很难解决，尽管我们花了好几天时间也不知道RCA。
• 隐藏的流主题。在查看流代码时，你永远无法发现有多少流主题被创建，除非你使用一些外部工具来可视化流的拓扑结构。当我们开始使用AKHQ查看主题和消费者组时，我们意识到流创建了许多重新分区和变化日志主题。所有容易使用的DSL功能都是有成本的，因为这些额外的主题会在很大程度上增加kafka集群的数据空间，而且在向changelog主题写入和读取数据时也会涉及大量的网络I/O。
• 流配置。Kafka对经纪人、消费者和生产者有太多的配置。很多配置是相互关联的，这可能会在很大程度上影响性能。当使用Kafka流时，它提供了另一套配置，进一步增加了复杂性。
• 不平衡的负载分配:在Kafka中实现并行的一个方法是增加分区和消费者。在简单的Kafka解决方案中，这种计算是非常容易的，但在Kafka流中，由于子结构和流主题的参与，你可能无法找出所需的消费者的确切数量，这导致在运行多个消费者的机器上的不平等的负载分布。这个问题可以在观察消费者的分区分配时得到解决，但是第一次发现这个问题并不容易。

所有这些问题迫使我们放弃了Kafka流，我们决定使用外部数据存储来实现容错和弹性。

我们必须在我们的解决方案中实现事务和错误处理，但这是值得的，因为作为回报，我们得到了解决方案的可调试性，这对于在生产中运行的系统是最重要的。