我正在研究一个实时处理用例的解决方案。当前的实现涉及两个不同的kafka流应用程序和一个中间kafka主题。我正在使用SpringCloudStreamKafka流绑定器和dsl。

input-topics --> [PRE-PROCESSOR] --> middle-topic --> [PROCESSOR] --> output-topic

尽管代码很简单，但是为第一个应用程序生成的拓扑结构相当复杂，因为它使用外键ktable ktable join。第二个应用程序也很重要，处理不同的用例和逻辑删除生成。每个拓扑有约20个处理节点和约3/4个物化状态存储。
这个解决方案功能齐全，但在我看来执行得不太好：主要关注的是延迟。应用程序还没有任何重要的计算导致处理速度减慢。按照这里的建议修补不同的配置（主要是 linger.ms 对于kafka流（producers）来说，它改善了这种情况，但即使在非常低的负载（10条消息/秒）下，我们观察到的端到端值约为400ms，批处理中第一个结果的峰值为800/1200ms。在更高的负载（20-30条消息/秒）下，解决方案只是努力赶上高cpu处理和代理负载（因此存在吞吐量问题）。
这是kafka流应用程序的预期结果还是我遗漏了什么？我知道dsl生成的中间主题和内部重新分区主题会导致生产者-主题-消费者链和有害影响，但我预期毫秒处理延迟库的低负载范围为50-100ms。
谢谢您