Использование Kafka для синхронизации данных между двумя микросервисами

Question

Я пытаюсь использовать kakfa для синхронизации c данных для двух микросервисов A & B.

A размещает некоторые данные для группы сотрудников компании в таблице базы данных , Затем конечный пользователь инициирует событие из пользовательского интерфейса в бэкэнд-сервис A , где он отправит сообщение (я) kakfa в топи, на которые подписан c B .

B затем берет данные из сообщения или из поэтапной таблицы, проверяет их и сохраняет в своей таблице базы данных.

У меня есть вопросы ..

1. Количество сотрудников может варьироваться от 10 до 1000 с каждой компании, и может быть несколько компаний, пытающихся синхронизировать c данных в определенное время года. Так что производительность - это проблема. Что было бы хорошим способом разделить нагрузку? смысл .. я должен разработать сообщение, чтобы быть на уровне сотрудника? Это будет означать, что могут быть тысячи сообщений, хотя в плане дизайна это будет самым простым. Или это должно быть на уровне компании? или группа сотрудников внутри компании? Микросервис не выполняет много операций обработки и сохранения в таблице. Сможет ли он справиться с нагрузкой? Что будет ограничивающим фактором?

2. Данные, которые мы обрабатываем, JSON хранятся в БД. Было бы лучше иметь промежуточную таблицу и искать от B , используя какой-то первичный ключ в сообщении? или все данные в сообщении будут в порядке? JSON не так велика для данных одного сотрудника, но если их объединить в группу сотрудников, скажем, 100, это может быть 10-100 килобайт. Много ли мы покупаем, просматривая данные из таблицы?

3. Нам необходимо отслеживать состояние / ошибки, чтобы конечный пользователь знал о любых проблемах и выполнял действия по их исправлению. данные и / или попробуйте resyn c. Некоторым подходом, о котором я думал, было создание таблицы, назовите ее BATCH_JOB и BATCH_TASK , чтобы отслеживать запросы на уровне работы (событие пользовательского интерфейса для группы сотрудников, как упомянуто, которые вызывают resyn c process) и задача (уровень сотрудника). Или был бы более понятный подход?

Любая помощь / советы по дизайну будут оценены.

Answer 1

Что было бы хорошим способом разделить нагрузку?

Краткий ответ - использование пользовательских схем разбиения с достаточно большим количеством разделов. Скажем 100.

Или вы можете создать топи c для каждой компании, в зависимости от того, используете ли вы разные схемы записи для топи c

Много ли мы покупаем из данные из таблицы?

Ну, вы не можете запросить topi c так же легко, как таблицу, так что в этом есть преимущество ... Вы также можете использовать KTable и интерактивные запросы

Данные, с которыми мы работаем, JSON хранятся в БД

Я предполагаю, что вы не просто помещаете один столбец BLOB в базу данных (и вы не уточнили, какую базу данных вы используете Используете либо).

Лично я бы посоветовал вам использовать Avro и Kafka Connect для ввода тем в базы данных. Это рекомендуемое решение для такой задачи в API-интерфейсах Kafka, без представления других проектов, таких как Spark, или написания собственного кода базы данных

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

Таблицы могут работать, но если вы можете записывать записи в таблицу, вы также можете записывать события в другую Kafka topi c и получать «уведомления» с этого