Kafka 主题过滤与微服务请求/回复模式的临时主题

Posted 2023-03-08

【中文标题】Kafka 主题过滤与微服务请求/回复模式的临时主题

【英文标题】：Kafka topic filtering vs. ephemeral topics for microservice request/reply pattern

【发布时间】：2019-07-20 16:35:46

【问题描述】：

我正在尝试使用 Kafka 实现请求/回复模式。我正在使用向这些服务发送消息的命名服务和未命名客户端，并且客户端可能希望得到回复。许多 (10s-100s) 客户端可能与单个服务或服务消费组交互。

策略一：过滤消息

第一个想法是每个服务有两个主题——“HelloWorld”服务将使用“HelloWorld”主题，并产生对“HelloWorld-Reply”主题的回复。客户端将使用该回复主题并过滤唯一的消息 ID，以了解哪些回复与他们相关。

其中的缺点是，当许多客户端与一项服务交互时，它似乎可能会给客户端带来不必要的工作，以过滤掉大量潜在的不相关消息。

策略二：临时主题

第二个想法是为每个客户端创建一个唯一 ID，并将该 ID 与消息一起发送。客户端将使用他们自己的唯一主题“[ClientID]”，并且服务会在收到回复时发送到该主题。因此，客户端不必过滤不相关的消息。

缺点是客户端的生命周期可能较短，例如它们可能是一次性脚本，他们必须事先创建主题并在之后将其删除。如果客户端在处理期间死亡，可能需要一些额外的过程来清除未使用的客户端主题。

其中哪一个看起来更好？

【问题讨论】：

我一直有同样的想法，并决定使用 NATS 来代替，因为它在设计上支持请求-回复模式，并带来了更多好处。 docs.nats.io/nats-concepts/reqreply

【参考方案1】：

我们在生产中使用 Kafka 作为基于事件的消息和请求/响应消息的处理程序。我们实现请求/响应的方法是您的第一个策略，因为当客户数量增加时，您必须创建许多主题，其中一些主题完全无用。选择第一种策略的另一个原因是我们的主题命名准则，即每个服务应该只属于一个主题以进行跟踪。但是，Kafka 不适用于请求/响应消息，但我推荐第一种策略，因为：

主题数量很少 更好的服务跟踪 更好的主题命名

但您必须小心您的消费群体。这可能会导致数据丢失。

更好的方法是使用第一种策略，在一个主题（服务）中包含多个分区，每个客户端使用唯一键发送和接收其消息。 Kafka 保证所有具有相同 key 的消息都将发送到特定的分区。这种方法不需要过滤不相关的消息，可能是您的两种策略的组合。

更新：

正如@ValBonn 在建议的方法中所说，您始终必须确保the number of partitions >= number of clients。

【讨论】：

嗨。出于同样的原因，我们也使用第一种策略。我只是想对您的“更好的方法”建议做出反应：Kafka 上的（默认）分区方式保证所有具有相同键的消息都进入同一个分区，正如您所写的那样。但这并不能保证您不会在同一个分区上有两个客户端，然后您就无法摆脱过滤不相关的消息。另一种方法是编写一个客户分区程序，它保证一个客户端=一个分区，但缺点是要保持分区的数量，与添加新主题的情况相同......

在看到写在我面前的问题后，我开始向这里倾斜...感谢您的确认

@ValBonn 嗨。谢谢你的建议。但是，缺点与添加新主题相同，但这次我们的主题是一门学科。