我正在研究Kafka 9作为一个爱好项目，并完成了几个"Hello World"类型的例子。
我必须考虑基于请求响应消息的现实世界 Kafka 应用程序，更具体地说，如何将 Kafka 请求消息链接到其响应消息。
我正在考虑使用生成的 UUID 作为请求消息密钥，并将此请求 UUID 用作关联的响应消息密钥。与 WebSphere MQ 具有消息关联 ID 的机制类型大致相同。
我的结束 2 结束过程将是。
1）. Kafka客户端随机生成一个 UUID，并发送一条 Kafka 请求消息。2）. 服务器将使用此请求消息提取并存储请求 UUID 值3）. 使用消息负载完成业务流程。4）. 使用响应消息进行响应，该响应消息使用请求消息中存储的 UUID 值作为响应消息键。5）. Kafka 客户端轮询响应主题，直到它超时或检索到具有原始请求 UUID 值的消息。
我担心的是 Kafka 消费者轮询将从响应主题中删除其他客户端消息，并增加使其他客户端失败的偏移量。
我是否正在尝试将 Kafka 应用于从未设计过的用例中？
是否可以在 Kafka 中实现请求/响应消息传递？
尽管 Kafka 提供了方便的方法来持久化给定使用者组的已提交偏移量，但您不需要使用该行为，并且可以根据需要编写自己的行为。 即便如此，以您描述的方式使用 Kafka 对于用例来说还是有点尴尬的，因为每个客户端都需要重复搜索主题以获得特定的响应。 这充其量是低效的。
您可以将问题分为两部分，继续使用 Kafka 向服务器传递请求和从服务器发送响应。 您唯一需要添加的部分是客户端与之通信的某种 API 层，它封装了来自客户端的特定于 Kafka 的逻辑。 该层需要一个本地数据库（关系或NoSQL），该数据库可以通过uuid存储响应，从而使API能够非常快速轻松地回答响应是否可用于特定的uuid。
更容易！您只能在 zookeeper 上写下 UUID X 应该在分区 Y 上应答，并让发送该 UUID 的生产者使用分区 Y...这有意义吗？
我认为您需要一个定义良好的服务分片键来调用请求。您的请求应包含此分片键和发布响应的主题的名称。此外，您应该创建某种状态机，当有关您的任务的消息出现时，您将过渡到某种状态......这将适用于严格的异步设计
理论上，你可以
- 为每个应该获取结果消息的请求和消息分配一个 ID;
- 创建一个哈希函数，将此 ID 映射到分区的标识符，
- 发送结果消息时，使用相同的哈希函数获取要发送到的分区的标识符，
- 在生产者中，您只能观察给定的分区。
这将减少在该主题中爬网许多消息以筛选出等待请求处理程序所需的结果的需要。