Фильтрация тем Кафки против эфемерных тем для шаблона запроса / ответа микросервиса

Question

Я пытаюсь реализовать шаблон запроса / ответа с Kafka.Я работаю с именованными службами и неназванными клиентами, которые отправляют сообщения этим службам, и клиенты могут ожидать ответа.Многие клиенты (от 10 до 100 с) могут взаимодействовать с одной услугой или группой потребителей.

Стратегия первая: фильтрация сообщений

Первой мыслью былодве темы на службу - служба «HelloWorld» будет использовать тему «HelloWorld» и создавать ответы обратно на тему «HelloWorld-Reply».Клиенты будут использовать эту тему ответа и фильтровать уникальные идентификаторы сообщений, чтобы знать, какие ответы имеют к ним отношение.

Недостаток в том, что это может создать ненужную работу для клиентов, чтобы отфильтровать потенциально большое количество несущественных сообщений.сообщения, когда много клиентов взаимодействуют с одним сервисом.

Стратегия два: эфемерные темы

Вторая идея состояла в том, чтобы создать уникальный идентификатор для клиента и отправить этот идентификатор вместес сообщениями.Клиенты будут использовать свою собственную уникальную тему «[ClientID]», а службы будут отправлять эту тему, когда у них будет ответ.Таким образом, клиенты не должны будут фильтровать нерелевантные сообщения.

Недостатком является то, что клиенты могут иметь короткий срок службы, например, они могут быть одноразовыми сценариями, и им придется заранее создавать свою тему и впоследствии удалять ее.Может потребоваться дополнительный процесс для очистки неиспользуемых клиентских тем, если клиент умирает во время обработки.

Что из этого кажется лучшей идеей?

Answer 1

Мы используем Kafka в производстве как обработчик для сообщений на основе событий и сообщений запроса / ответа.наш подход к реализации запроса / ответа - ваша первая стратегия , потому что, когда число клиентов растет, вам приходится создавать множество тем, некоторые из которых совершенно бесполезны.Другой причиной выбора первой стратегии было наше руководство по именованию тем, что каждый сервис должен принадлежать только одной теме для привязки.однако, Kafka не предназначен для сообщений запроса / ответа, но я рекомендую первую стратегию, потому что:

• несколько номеров тем
• лучшее отслеживание службы
• лучшее название темы

но вы должны быть осторожны с вашими группами потребителей.что может привести к потере данных.

Лучшим подходом является использование первой стратегии со многими разделами в одной теме (службе), которую каждый клиент отправляет и получает свои сообщения с уникальным ключом.Kafka гарантирует, что все сообщения с одним и тем же ключом попадут в определенный раздел.этот подход не требует фильтрации ненужных сообщений и, возможно, представляет собой комбинацию двух ваших стратегий.

Обновление:

Как сказал @ValBonn в предлагаемом подходе, вы всегда имеетечтобы быть уверенным, что the number of partitions >= number of clients.