Как выполнить планирование с помощью python?

Я думаю, вы столкнулись с несколькими проблемами:

1. Как вы подозревали, ваш schedule находится в другом расписании/интервале, чем ваша работа cron. Они не синхронизированы (и вы никогда не можете ожидать, что они будут синхронизированы по следующей причине). С момента выполнения вашего скрипта jobs.py это начальная точка, от которой расписание отсчитывает интервалы.

то есть, если вы запускаете что-то каждую минуту, но скрипт jobs.py запускается через 30 секунд текущей минуты (т.е. 01:00:30 - 1:00 через 30 секунд), то планировщик запустит задание в 1:01:30. , затем 1:02:30, затем 1:03:30 и так далее.

2. Schedule Частотное исполнение не гарантирует вам точности. Когда планировщик запускает задание, время выполнения задания не учитывается. Поэтому, если вы запланируете что-то вроде заданий на рассылку/напоминания, это может занять некоторое время. После завершения выполнения планировщик решает, что следующее задание будет выполняться только 1 минуту после окончания предыдущей работы. Это означает, что ваше время выполнения может нарушить график.

Попробуйте запустить этот пример в скрипте Python, чтобы понять, о чем я говорю.

# Schedule Library imported
import schedule
import time
from datetime import datetime
     
def geeks():
    now = datetime.now() # current date and time
    date_time = now.strftime("%m/%d/%Y, %H:%M:%S")
    time.sleep(5)
    print(date_time + "- Look at the timestamp")
 
geeks();
# Task scheduling
# After every 10mins geeks() is called.
schedule.every(1).seconds.do(geeks)
 
# Loop so that the scheduling task
# keeps on running all time.
while True:
 
    # Checks whether a scheduled task
    # is pending to run or not
    schedule.run_pending()
    time.sleep(0.1)

Мы запланировали запуск функции geeks каждую секунду. Но если вы посмотрите на функцию гиков, я добавил time.sleep(5), чтобы представить, что здесь может быть какой-то блокирующий вызов API, который может занять 5 секунд. Затем посмотрите на записанные временные метки — вы заметите, что они не всегда соответствуют расписанию, которое мы изначально хотели!

Теперь о том, как ваша работа cron и планировщик не синхронизированы.

Посмотрите на следующие журналы:

13:07:00 [D] schedule Running job Job(interval=1, unit=minutes, do=job_feeds_update, args=(), kwargs = {})
13:07:00 [I] jobs job_feeds_update
13:07:00 [I] werkzeug 172.20.0.2 - - [08/May/2022 13:07:00] "GET /feeds/update_feeds HTTP/1.1" 200 -

# minute 8 doesn't trigger the schedule for feeds

13:09:00 [D] schedule Running job Job(interval=1, unit=minutes, do=job_feeds_update, args=(), kwargs = {})
13:09:00 [I] jobs job_feeds_update
13:09:00 [I] werkzeug 172.20.0.2 - - [08/May/2022 13:09:00] "GET /feeds/update_feeds HTTP/1.1" 200 -

Вероятно, здесь происходит следующее:

• в 13:07:00 ваш cron отправляет запрос на подачу элементов

• в 13:07:00 в расписании заданий есть ожидающее задание для элементов фида

• в 13:07:00: задание завершается, и расписание определяет, что следующее задание может быть запущено только через 1 минуту, что составляет примерно ~13:08:01 (обратите внимание на 01, это для учета миллисекунд/времени задания). выполнений, что позволяет предположить, что для запуска обновления элементов фида потребовалась 1 секунда)

• в 13:08:00 ваше задание cron запускает запрос, запрашивающий задания schedule run_pending.

• в 13:08:00 Однако, есть нет ожидающих выполнения заданий, потому что следующий раз, когда элементы ленты могут запускаться, будет 13:08:01, а не прямо сейчас.

• в 13:09:00 ваша вкладка cron снова запускает запрос

• в 13:09:00 доступно ожидающее задание, которое должно было выполняться в 13:08:01, чтобы оно было выполнено сейчас.

Я надеюсь, что это иллюстрирует проблему, с которой вы столкнулись, из-за рассинхронизации между cron и расписанием. Эта проблема усугубится в производственной среде. Вы можете прочитать больше о Параллельное исполнение для schedule как о средстве отвлечься от основного потока, но это пока не так далеко. Давайте поговорим о...

Возможные решения

1. Используйте run_all из расписания вместо run_pending, чтобы принудительно запускать задания, независимо от того, когда они фактически запланированы.

Но если подумать, это ничем не отличается от простого вызова job_feeds_update прямо из вашего маршрута API. Это неплохая идея сама по себе, но она все еще не очень чистая, поскольку она будет блокировать основной поток вашего API-сервера до тех пор, пока job_feeds_update не будет завершен, что может быть не идеальным, если у вас есть другие маршруты, которые нужны пользователям.

Вы можете объединить это со следующим предложением:

2. Использование очереди заданий и потоков Ознакомьтесь со вторым примером в Страница параллельного выполнения документации по расписанию. В нем показано, как использовать очередь заданий и потоки для разгрузки заданий.

Поскольку вы запускаете schedule.run_pending(), ваш основной поток на вашем сервере заблокирован до тех пор, пока не будут запущены задания. Используя потоки (+ очередь заданий), вы можете планировать задания в очереди + избегать блокировки основного сервера своими заданиями. Это должно немного оптимизировать работу для вас, позволяя планировать задания.

3. Вместо этого используйте ischedule, поскольку он учитывает время выполнения задания и предоставляет точные расписания: https://pypi.org/project/ischedule/. Это может быть простейшее решение для вас на случай, если 1+2 станет головной болью!

4. Не использовать расписание, и ваши задания cron просто попадут на маршрут, который просто запускает реальную функцию (так что в основном это противоречит совету использовать 1 + 2 выше). Проблема заключается в том, что если вашим функциям требуется больше минуты для обновления веб-канала, у вас может быть несколько перекрывающихся заданий cron, выполняющихся одновременно для обновления веб-канала. Поэтому я бы рекомендовал не делать этого и полагаться на механизм для постановки в очередь/планирования ваших запросов с потоками и заданиями. Только упоминая об этом как о потенциальном сценарии того, что еще вы могли бы сделать.