假设我有两个 Kafka 主题，A和B。我正在尝试开发一个系统，从A中提取记录，对每个记录应用转换，然后将转换后的记录发布到B。在这种情况下，转换涉及通过 HTTP 调用 REST 端点。
作为 Kafka 的新手，我很高兴看到 Kafka Streams 项目已经解决了这类问题（consume-transform-publish）。不幸的是，我发现 Kafka 流中的转换是阻塞操作。本能地，我尝试以非阻塞、异步的方式调用 HTTP 端点。
这是否意味着 Kafka Streams 在这种情况下无法工作？这是否意味着我必须恢复以阻塞方式调用 REST 端点？这甚至是 Kafka Streams 可以接受的模式吗？基于流的数据处理对我来说还是比较新的，所以我并不完全熟悉它的并发模型。
更新：在进一步研究之后，我不确定这是正确的答案......
我是 Kafka 和 Kafka Streams（以下简称“Kafka”）的新手，但遇到并考虑过类似的问题，以下是我的观点：
卡夫卡有两个显着特点：
许多非常好的属性都从这些特性中消失了。例如，我认为基于流的“事务”是最酷的之一。
但是，这些属性是否真的是你想要的意义上的“特性”，当然，取决于应用程序。如果您不希望基于主题分区的具有并行性的强排序处理，那么您可能不希望将 Kafka 用于该应用程序。
所以，关于：
这是否意味着 Kafka Streams 在这种情况下无法工作？
它会起作用，但增加的并行性是通过增加分区来实现的。
这是否意味着我必须恢复以阻塞方式调用 REST 端点？
是的，我认为确实如此——但我不确定为什么会是“回归”。就个人而言，这就是我喜欢 Kafka 的地方：阻塞代码更简单。如果我想要更多的并行性，我可以运行更多的线程。毕竟没有共享状态。