Question

在我们的应用程序中，我们寻求从输入主题中获取JSON消息，将它们组合到给定的窗口中，然后将其写到目标主题中。 mergeJsonNodes是负责简单地合并两个JSON对象的函数。

KStream<String, JsonNode> transformed = datastreamSource
  .groupByKey(Serialized.with(Serdes.String(), JSON_SERDE))
  .windowedBy(SessionWindows.with(60 * 1000))
  .reduce((a, b) -> mergeJsonNodes(a, b))
  .toStream((windowedKey, node) -> windowedKey.key());

我们已成功将其部署在我们的多个非生产环境中。但是，当我们进入生产阶段时，输入主题（datastreamSource）的数量要大得多，因此遇到了我们想要了解的瓶颈。

我们看到的是我们的流应用程序在源主题上进展缓慢，并且每分钟一次致力于目标主题。但是，它从输入主题中提取的速度太慢，无法跟上我们致力于该主题的生产量。我们正在从一个运行良好的非窗口非分组流应用程序中迁移过来。

Kafka流应用程序主机上的资源似乎没有受到限制；并非应用程序缺少内存或磁盘。

我们的问题是，还有哪些其他因素，尤其是配置设置，我们可以进行修改以允许流应用一次将更多消息从输入主题中提取出来。我们的应用似乎在继续从源代码顶部继续阅读的能力上受到了某种限制我知道了。

最初从the docs跳出来的两个人：
* buffered.records.per.partition
* cache.max.bytes.buffering

是否有人对可以提供任何指针的高吞吐量窗口流应用程序有经验？谢谢！

Answer 1

我在窗口聚合中并不特别了解，但是在Kafka流中进行聚合时，您需要进行2种配置，以找出在刷新到状态存储并将结果聚合记录发送到下游处理器之前，聚合处理器节点将如何缓存消息： cache.max.bytes.buffering，commit.interval.ms。

您具有可以在kafka流中调整的使用者配置：poll.ms。

您也可以扩展应用程序，输入主题有多少个分区？它将导致处理输入主题的任务数量增加，从而影响应用程序的可伸缩性。

更多的分区意味着更多的任务意味着更多的使用者意味着更多的实例或实例上的更多线程（请检查num.streams.thread）。

希望有帮助。

在窗口Kafka Streams应用程序中缓冲

1 个答案: