我正在调查Kafka 9作为一个爱好项目，并完成了一些“Hello World”类型的例子。
我必须考虑基于请求响应消息传递的Real World Kafka应用程序，更具体地说，如何将Kafka请求消息链接到其响应消息。
我在考虑使用生成的UUID作为请求消息密钥，并将此请求UUID用作关联的响应消息密钥。与WebSphere MQ具有消息关联ID的机制大致相同。
我的结束2结束过程将是。
1）。 Kafka客户端生成随机UUID并发送单个Kafka请求消息。 2）。服务器将使用此请求消息提取＆amp;存储请求UUID值 3）。使用消息有效内容完成业务流程。 4）。响应响应消息，该消息使用来自请求消息的存储的UUID值作为响应消息Key。 5）。 Kafka客户端轮询响应主题，直到它超时或检索具有原始请求UUID值的消息。
我担心的是Kafka Consumer轮询会从响应主题中删除其他客户端消息，并增加偏移量，使其他客户端失败。
我是否尝试在用例中应用Kafka，它从未设计过？
是否可以在Kafka中实现请求/响应消息传递？
答案 0 :(得分：7)
尽管Kafka提供了方便的方法来保持给定消费者群体的承诺抵消，但您并不需要使用该行为，并且如果您认为有需要可以编写自己的行为。即便如此，使用Kafka的方式对于用例来说有点尴尬，因为每个客户端都需要反复搜索主题以获取特定的响应。这充其量只是效率低下。
您可以将问题分成两部分，继续使用Kafka向您的服务器发送请求和响应。您需要添加的唯一部分是客户端与之交谈的某种API层，它封装了客户端的Kafka特定逻辑。该层需要一个本地数据库（关系或NoSQL），可以通过uuid存储响应，使API能够非常快速，轻松地回答特定uuid的响应是否可用。
答案 1 :(得分：1)
容易！您只能在zookeeper上写入UUID X应该在分区Y上回答，并使发送该UUID的生产者使用分区Y ...这有意义吗？
答案 2 :(得分：0)
我从来没有尝试过，但从理论上讲，如果你在开始任何产品之前，产生一些消息，其中包含从0到答案主题的分区数量的数字，而你的生产者已经是该主题的消费者，所以每个制作人都会收到至少有一条消息。因此，您可以将该密钥存储在每个生产者上，并使用uuid发布...在消费者的流程之后，它可以使用uuid发布答案（在答案主题上）并键入与它一起发送的相同密钥，因此它将由发送它的同一个生产者获得...一旦具有相同密钥的所有消息都在同一分区中发布...
答案 3 :(得分：0)
我认为您需要一个定义良好的调用请求的服务的分片键。您的请求应包含此分片键以及主题的名称，以便在何处发布响应。你还应该创建某种状态机，当你的任务消息出现时，你会转换到某种状态...这将是严格的异步设计