У меня есть установленная Kafka, в которую по API передаются разные данные, которые оттуда идут уже в приложение для загрузки.
Каждая сущность API, например, товары и склады - это разные топики, следовательно - разные консьюмеры. При одновременной работе консьюмеров получается так, что связи между товаром и складом не создаются, по причине того, что товар и склад создаются в один момент времени и просто не могут найти друг друга в базе.
Для того, чтобы решить эту проблему, необходимо сделать последовательную передачу данных с учётом их связей. Сейчас я сделал общий топик incoming, который принимает все входящие сообщения, его считывает консьюмер и создает новые сообщения в Kafka по каждой сущности в соответствующем топике.
Román Mirilaczvili, смысл в брокере сообщений. Одна входная точка для всех запросов на разные продукты. Внутри продуктов есть сущности, имеющие связи. Поэтому нужно как-то организовать слаженную работу сообщений таким образом, чтобы данные не терялись. Поэтому нужна какая-то очередь.
Дмитрий, а как так получается, что запрос на добавление товара в несуществующий склад вообще попадает в очередь?
Может попробовать подойти с этой стороны?
Ещё вариант - попробовать пропустить этап с проверкой на существование склада, если гарантируется, что рано или поздно он будет создан (тогда придётся убрать FK, если у вас в конце какая-то реляционная база)
Román Mirilaczvili, вы уходите от вопроса в другие степи, но не отвечаете на сам вопрос :)
Я спросил лишь - нормальная ли практика передавать сообщения из топика в консмьюмер, чтобы он передал это сообщение в новый топик или нет? Я хочу понять best practices, а не рассказывать о том, какие у меня там запросы и цифры.
Василий Банников, учётная система по регламентному заданию выгружает данные на сайты. Сайтов очень много, несколько десятков. Там есть зависимости складов от сайтов, сайтов от юр.лиц, номенклатуры и свойств и так далее. Товаров очень много, информации очень много. Поэтому, чтобы правильно организовать передачу данных, я хочу понять, как лучше это сделать с точки зрения работы с Кафкой.
Для такого используется Kafka Streams, два потока джойнятся по ключу, можно записывать результат в третий поток или отправлять в БД. Вот описание краткое, чтобы было понятно, куда копать: https://kafka-school.ru/blogs/kafka-stream-unit/
Ну это асинхронная обработка, типа норма ) я сносил внешние ключи в базе, прописывал правила в своей ORM. Наверно более правильный вариант делать таблицу входящих сообщений, типа инбокс, и уже с него пытаться распихивать по нормальным таблицам, если не записалось - делать ретраи через паузы
Средний
Средний
Сложный
