apache-kafka - 匹配Kafka消费者和生产者分区

Question

我正在创建一个系统，其中前端服务将消息推送到 Kafka 的“请求”主题，并为某些下游后端消费者(实际上是一个最终推回 Kafka 的复杂系统)监听另一个“响应”主题以进行处理在“请求”消息上并最终推送到“响应”主题。

我试图找出最优雅的方法来确保消费者监听适当的分区并收到响应，并且后端推送到前端消费者正在监听的分区。我们总是需要确保响应发送到产生初始消息的同一个消费者。

到目前为止，我有两个解决方案，但都不是特别令人满意。任何想法或想法将不胜感激:

让每个前端决定它将监听哪个分区，并将该分区与消息一起传递给“请求”主题。当后端处理完成后，它会查看消息的分区成员并推送到相应的分区。这里的一个紧迫问题是如何协调前端服务，以便在每个分区上均匀分布(随机分配？)。

每条消息都有一个相关 ID，一个 GUID，因此对于我们前端的每个请求，我们可以根据将 GUID 散列到分区总数开始监听分区，然后将消息推送到“请求”主题。然后后端将查看相关 ID 以确定要推送到的适当分区。这里的一个问题是，对于传入的每个请求，前端必须在新分区上建立一个新使用者(这里有开销吗？)并且可能在同一分区上有多个事件使用者以及跨多个事件使用者许多分区。

有一个具有相同数量的消费者和分区的消费者组，然后采用与(1)类似的方法，但允许 Kafka 处理哪个消费者在哪个分区上。但是我们需要弄清楚当重新平衡发生时会发生什么，特别是对于后端已经在传输中的消息(因为可能所有分区都可能发生变化？)。

这似乎应该是一种常见模式，所以我想知道其他人是如何解决这个问题的。

Answer 1

请不要使用手动分配分区的消费者。它可能会变得非常困惑并且难以扩展。

您可以使用每个前端消费者的主题来代替分区。每个前端服务向request 生成一条包含前端服务id 的消息。话题。然后后端使用该消息并根据 id 生成对特定 unique-front-end-service-response 的响应消息。话题。
如果您有固定数量的前端服务，这可能是一个很好的解决方案。可能的缺点是每次要添加新的前端服务时都会创建一个新主题。然而，它比手动分区分配更容易维护。

另一种可能的解决方案是使用不同的工具。如果 Kafka 不是强制性的，请重新考虑您的要求并进行研究。可能有一种工具比 Kafka 更适合您的需求。