Как организовать очередь сообщений в Kafka?

Question

[Дмитрий]

У меня есть установленная Kafka, в которую по API передаются разные данные, которые оттуда идут уже в приложение для загрузки.
Каждая сущность API, например, товары и склады - это разные топики, следовательно - разные консьюмеры. При одновременной работе консьюмеров получается так, что связи между товаром и складом не создаются, по причине того, что товар и склад создаются в один момент времени и просто не могут найти друг друга в базе.

Для того, чтобы решить эту проблему, необходимо сделать последовательную передачу данных с учётом их связей. Сейчас я сделал общий топик incoming, который принимает все входящие сообщения, его считывает консьюмер и создает новые сообщения в Kafka по каждой сущности в соответствующем топике.

Вопрос - норм логика или дичь какая-то?

Comments

[Дмитрий]

Ну может просто откладывать сообщения с товарами у которых склад не готов?

[Everything_is_not_so_bad]

Зачем вообще нужны очереди с Кафкой? Какой в этом смысл?

[Дмитрий]

Дмитрий, появляется множество проверок, следовательно вырастает нагрузка на БД. Таких сущностей множество, товар и склад лишь пример

[Дмитрий]

Román Mirilaczvili, смысл в брокере сообщений. Одна входная точка для всех запросов на разные продукты. Внутри продуктов есть сущности, имеющие связи. Поэтому нужно как-то организовать слаженную работу сообщений таким образом, чтобы данные не терялись. Поэтому нужна какая-то очередь.

[Дмитрий]

Дмитрий, какие? Если банально обвешать таблицу констрайнами - вставились норм, не вставилось - отложить

[Василий Банников]

Дмитрий, а как так получается, что запрос на добавление товара в несуществующий склад вообще попадает в очередь?
Может попробовать подойти с этой стороны?

Ещё вариант - попробовать пропустить этап с проверкой на существование склада, если гарантируется, что рано или поздно он будет создан (тогда придётся убрать FK, если у вас в конце какая-то реляционная база)

[Everything_is_not_so_bad]

Дмитрий,

появляется множество проверок, следовательно вырастает нагрузка на БД. Таких сущностей множество, товар и склад лишь пример

1. И каким образом Кафка должна решить проблему?
2. Подробнее, что за нагрузка? Где цифры, запросы, ...?

[Дмитрий]

Román Mirilaczvili, вы уходите от вопроса в другие степи, но не отвечаете на сам вопрос :)
Я спросил лишь - нормальная ли практика передавать сообщения из топика в консмьюмер, чтобы он передал это сообщение в новый топик или нет? Я хочу понять best practices, а не рассказывать о том, какие у меня там запросы и цифры.

[Дмитрий]

Василий Банников, учётная система по регламентному заданию выгружает данные на сайты. Сайтов очень много, несколько десятков. Там есть зависимости складов от сайтов, сайтов от юр.лиц, номенклатуры и свойств и так далее. Товаров очень много, информации очень много. Поэтому, чтобы правильно организовать передачу данных, я хочу понять, как лучше это сделать с точки зрения работы с Кафкой.

[Everything_is_not_so_bad]

Дмитрий,

товар и склад создаются в один момент времени

почему склад не существует заранее?

Answer 1

[holodoz]

Для такого используется Kafka Streams, два потока джойнятся по ключу, можно записывать результат в третий поток или отправлять в БД. Вот описание краткое, чтобы было понятно, куда копать:
https://kafka-school.ru/blogs/kafka-stream-unit/

Comments

[Дмитрий]

огромное вам спасибо за ответ!

[Everything_is_not_so_bad]

Дмитрий, напиши, что получилось в итоге?

Answer 2

[Виктор П.]

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