@Artikul2

Какой брокер сообщений выбрать под задачу — принять данные по api и записать в базу?

Моя задача принимать через api данные в формате json, записывать их в соответствующую таблицу в зависимости от кого эти данные пришли. Каждый источник может отправлять данные любого размера, например json с 1 млн элементов, где каждый элемент имеет 30 пар ключ-значение, а может отправить один элемент в json. Таких источников может быть сотни, а общее поступление новых данных в минуту может быть в пределах 200 максимум.
На деле - все цифры в разы меньше. Пример привел на перспективу.

Я вижу краткую логистику данных:
Данные отправляются запросом post, мой сервер принимает данные. Файл Json ложится во временную папку и переименовывается. В Mysql пишем отправителя, путь к файлу, указываем метод к которому применяем эти данные и отправляем в ответ на post запрос статус 200 - загружено.
По крону раз в минуту запускаем скрипт, который получит имеющиеся данные в mysql и выполнит операцию вставки json в базу данных. Если при вставке нет проблем, то запускаем код, который обновит статус в mysql, что данная задача выполнена, а затем удалит файл данных. Готово.

Из минусов вижу, что такие задачи будут выполняться последовательно и 200 штук файлов за минуту не будут записаны в базу.

Конечно, я бы хотел сделать все по нормальному, но у меня крайне мало времени во всем разобраться, потому ищу более простое решение под мою задачу. Я полагаю брокер сообщений может выполнять множество задач по загрузке данных за время.
1. В идеале мне нужно гарантировать, что полученные данные будут записаны (даже после reboot сервера) в конечную базу данных, а если в json отправителя есть ошибка и файл не может быть записан, например ошибка (когда ожидаем число, а пришла строка), в ответе на post запрос высылать код ошибки с описанием.
2. Также мне нужно сделать триггеры, когда в базе данных появляются новые данные, например пересчитать данные в таблице или вывести в веб-интерфейс, что появились новые данные. Но я не знаю, относится ли этот пункт к брокеру сообщений.

На данный момент, мне кажется, что Redis Stream подходит, но я не уверен, потому что никогда не работал с подобными брокерами.
  • Вопрос задан
  • 218 просмотров
Пригласить эксперта
Ответы на вопрос 2
@rPman
Миллион? В json? Передай хороший пинок архитектору...

Твоя задача упирается в 2 узких места - это парксинг больших json и запись в базу.

Паркинг делай потоковым размером, они быстрые и удобные как раз для ситуаций, когда в одном json много объектов, даже если разнородные.

Запись в базу делай тут же либо через любую очередь, особенно если работа с базой будет асинхронной.

Усложнять не советую.
Ответ написан
AshBlade
@AshBlade
Просто хочу быть счастливым
Миллион элементов в json - это сильно (жирно).
Предлагаю следующий вариант:
- В качестве брокера использовать любой брокер сообщений/менеджер очередей с ACK/NACK механизмом (Redis Streams, RabbitMQ, Kafka)
- Все json разбиваем на 2 категории - большие и маленькие в зависимости от размера (кот. поддерживает брокер)

Алгоритм будет следующий:
Producer:
- Приходит запрос с json
- Если json маленький, то отправляем в брокер напрямую
- Если json большой, то сохраняем его в отдельную БД и получаем ID этой записи, в брокер отправляем ID этой записи

Consumer:
- Получает сообщение из брокера
- Если json содержится в сообщении (когда маленький), то сохраняем в БД
- Если json был большим и передан ID из БД, то читаем этот JSON из временный БД и сохраняем в целевую БД
- Коммитим сообщение

Пример такого запроса:
// Маленький объект
{
   "data": {
       "key": "value"
    },
    "id": null
}

// Большой объект
{
    "data": null,
    "id": 13123123
}


P.S. название паттерна хранения большого объекта во внешнем хранилище и передача только его id не помню
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы