У меня есть API, который имеет ряд конечных точек, которые все преформируют очень долго выполняемые задания, например, в заданиях, выполнение которых может занять до 48 часов.
Конечно, я не могу заставить клиента ждать ответа в течение 48 часов, поэтому я ищу лучшее решение для этих случаев.
У меня есть представление о том, что делать, но я не уверен, что это стоящее решение или как все это делается в производственном приложении. Кроме того, я хотел бы реализовать способ отмены заданий, когда они выполняются, если это необходимо, и обновлять / отслеживать общий ход выполнения заданий.
Моя текущая настройка работает следующим образом:
API получает запрос на запуск длинной работы
Запись для информации о работе сохраняется в БД с состоянием работы, установленным в ОЖИДАНИЕ
Эта информация о вакансии помещается в сообщение Rabbit MQ и отправляется Производителем RabbitMQ
Идентификатор задания возвращается к клиенту, который инициировал вызов API с 202, принятый статус
RabbitMQ Consumer получает сообщение с информацией о задании и вызывает класс, отвечающий за выполнение долго выполняемого задания, статус задания обновляется до IN-PROGRESS
Теперь клиент может проверить состояние задания с помощью другой конечной точки, которая принимает идентификатор задания и возвращает текущее состояние / информация
Я думаю, что этот подход работает, и он кажется масштабируемым, но у меня есть несколько опасений, которые, возможно, кто-то мог бы пролить на некоторых или помочь мне решить:
A. Я хочу иметь возможность убить работу из другой уязвимой конечной точки, если это необходимо, каков наилучший способ выполнить такую вещь? Я подумал, что, возможно, я мог бы также сохранить идентификатор потока с информацией о задании на шаге 5, когда служба обновит статус на IN-PROGRESS и начнет обработку. Затем, когда я достиг конечной точки отмены задания, я мог просто присвоить ему идентификатор задания и затем уничтожить связанный поток. Это жизнеспособное решение или есть лучший способ справиться с этим?
B. Я хотел бы реализовать стратегию обновления, которая позволила бы мне количественно оценить общий ход выполнения задания, поэтому вместо того, чтобы просто видеть ПРОГРЕСС или ОЖИДАНИЕ из внешнего интерфейса, я могу видеть процент выполненного задания. Внешний интерфейс будет настольным приложением, поэтому в конечном итоге я бы хотел использовать эту информацию для поддержки индикатора выполнения. Тем не менее, я обеспокоен производительностью, потому что мне нужно будет постоянно записывать в таблицу заданий каждый раз, когда прогресс увеличивается, а также постоянно читать из таблицы, когда клиент проверяет конечную точку для проверки состояния (я я думаю каждые 10 секунд или около того) есть ли лучшее решение для обработки этого на основе данной информации?
Если это имеет какое-либо значение, только одна работа должна обрабатываться за один раз ... это для административного портала, поэтому только несколько человек будут иметь доступ к этой функции, и если определенный тип работы уже находится в ПРОГРЕССЕ, чем другой такой тип не будет разрешен до тех пор, пока он не будет завершен, отменен или не выполнен