Я хотел бы запускать задания, но поскольку они могут быть длинными, я хотел бы знать, как далеко они были обработаны во время их выполнения. То есть исполнитель будет регулярно возвращать свой прогресс, не завершая выполняемую работу. Я пытался сделать это с помощью APScheduler, но, похоже, планировщик может получать только сообщения о событиях, такие как EVENT_JOB_EXECUTED или EVENT_JOB_ERROR.
Можно ли получить информацию от исполнителя во время выполнения задания?
Заранее спасибо!
Я думаю, что в APScheduler нет особой поддержки для этого. Это требование возникало у меня много раз, и лучшее решение будет зависеть от того, что именно вам нужно. Некоторые возможности:
Самым простым решением было бы использовать простой словарь Python. Сделайте ключ ключом задания, а значение — любой требуемой информацией о состоянии. Это решение работает лучше всего, если у вас есть только одна копия каждого задания, работающего одновременно (max_instances=1), конечно. Если вам нужна некоторая структура для вашей информации о состоянии, я являюсь поклонником namedtuples для этого. Затем вы либо сохраняете словарь как глобальную переменную зла, либо передаете его в каждую функцию задания.
Однако есть некоторые недостатки. Информация о состоянии останется в словаре навсегда, если вы ее не удалите. Если вы удалите его в конце задания, вы не сможете прочитать статус «задание завершено», и в противном случае вы должны убедиться, что все, что отслеживает состояние, определенно проверяет и очищает каждое задание. Это, конечно, не имеет большого значения, если у вас есть набор заданий/ключей разумного размера.
Если вам нужны дополнительные функции, вы можете сделать, как указано выше, но подкласс dict (или UserDict или MutableMapping, в зависимости от того, что вы хотите).
Если у вас есть memcached-сервер, который вы можете использовать, хранение отчетов о состоянии в memcached прекрасно работает, поскольку срок их действия может истечь автоматически, и они должны быть глобально доступны для вашего приложения. Одним, вероятно, незначительным недостатком является то, что информация о состоянии может быть удалена с сервера memcached, если на нем закончится память, поэтому вы не можете гарантировать, что информация будет доступна.
Более серьезным недостатком является то, что для этого требуется доступный сервер memcached. Если он у вас есть, а может и не быть, вы можете использовать dogpile.cache и выбрать бэкэнд, который подходит в то время.
Комментарий Питера об использовании функции обратного вызова заслуживает внимания. Если вы знаете, какая информация о состоянии вам понадобится, но не знаете, как вы в конечном итоге будете ее хранить или использовать, передача обертки вашим заданиям облегчит использование другого бэкэнда позже.
Однако, как всегда, будьте осторожны с чрезмерным проектированием вашего решения. Если все, что вам нужно, это отчет, в котором говорится «обработано 20/133 элементов», вероятно, достаточно простого словаря.
