Привет всем Используем манго дб у нас пользователь запускает с админки

задание, там есть такое поле как кол-во повторений задания

мы каждое повторение разбираем на + 1 строку в базе

потом когда обработчики будут исполнять, они будут брать каждую строку себе в обработку и будет каждое повторение как отдельная строка


так вот заданий у нас от пользоватлей планируется тысячи, возьмем к примеру условно 2000 заданий

и если каждое задание юзер захочет повторить по 10 000 раз, это в сумме будет

2000 * 10 000 = 20 000 000 строк


вообще такой подход имеет право на жизнь? Или обычно по другому делают?

Что за задания такие, где нужно выполнить их 10к раз?

Повторы задания, там Парсинг данных, но речь не об этом

И что, если данные не удалось распарсить, задание 10к раз будет падать с той же ошибкой?

У каждого повтора своя ошибка и в это в Кафке

Самый простой вариант реализации: Приложение получает от пользователя запрос с типом задания и параметрами, в т.ч. количеством повторов. Для задания в базе создаётся 1 строка. Кроме столбцов с параметрами запуска нужны следующие: состояние задачи (Scheduled), число ошибочных запусков (0) и максимальное количество запусков. Затем процесс/поток шедулер триггерит его запуск, записывая в очередь (rabbitmq, activemq, kafka) сообщение с данными по выполнению задачи и меняет его состояние на Running. Воркер получает сообщение, обрабатывает, затем в другую очередь возвращает состояние Success или Failed. Шедулер его получает и меняет состояние задачи. В случае статуса Failed нужно увеличить счётчик ошибочных запусков. Периодически шедулер проверяет, нужно ли запускать задачу. Если состояние Success, или Canceled (пользователь отменил через интерфейс), или Running (уже запущено), или Failed и количество запусков стало равно максимальному, то ничего делать не нужно, в противном случае нужно ещё раз отправить в очередь задание на обработку. В таком виде база не будет засираться ненужными записями. Плюс есть возможность отменять задания. Можно даже реализовать прибивание запущенного воркера. Для этого он должен сразу при получении сообщения о выполнении задачи отправлять в очередь с результатами свой идентификатор (например, pid), который шедулер затем запишет в базу. При получении от пользователя запроса на остановку отправять в очередь сообщение, которое либо воркер получит из очереди в отдельном потоке и воспримет как сигнал к собственной остановке, либо его получит другой воркер и как-то сможет найти его среди процессов и убить. Отправку этого запроса в очередь можно тоже реализовать по-разному, либо писать в обход шедулера, но тогда он как-то должен узнавать о том, что воркер был прибит, либо завести отдельное состояние Stopping, которое будет учитывать шедулер. Плюс есть возможность вносить задержку между запусками. Например, записывать в отдельный столбец время последнего обновления и пропускать задание, если с момента последнего запуска прошло менее 5 минут. Плюс есть возможность управлять временем запуска задания, например строго в период 10:00-20:00 (если это вообще нужно). Плюс управляя приоритетом заданий и количеством очередей можно достаточно гибко ограничивать разрешенную нагрузку. Ну и самое главное, на мой взгляд - можно масштабировать воркеры, если заданий станет очень много (может и шедулер тоже, но там могут быть проблемы с одновременной записью, которые я хз как решить). Если задания отрабатывают параллельно, схема усложняется, но реализация сильно зависит от деталей.

Благодарю Вас!