Я создал простое веб-приложение, используя flask, которое выполняет задания cron, используя APScheduler , чтобы указать c. Однако, когда я упаковываю код с помощью WSGI (uWSGI, gunicorn ...), я заметил, что, поскольку WSGI имеет тенденцию разделять приложение на несколько процессов, оно не будет вести себя так же, как в среде разработки (Запуск одно и то же задание несколько раз, задание вообще не запускается ...).
После долгого исследования, чтения через docs , я нашел решение:
Запуск автономного процесса, который объединяет функцию планировщика с некоторым механизмом удаленного доступа (например, RPy C) и заставляет процессы flask взаимодействовать с этим процессом для любых действий, связанных с планированием.
Забудьте о Планировщике, просто воспользуйтесь командой cron, предоставляемой ОС
При запуске WSGI Server один из рабочих процесс будет отвечать за запуск планировщика. Если какой-либо другой процесс имеет nedd для доступа к планировщику, поговорите с процессом, который запускает сервер. (Это концептуальная мысль, я тоже не уверен, возможно ли это: (
Итак, мой вопрос: как это так сложно?
Несмотря на это языка программирования, операционной системы, стека развертывания и т. д. c, я почти уверен, что я не из тех, кому нужно запускать задания cron вместе с веб-приложением. Однако ни одно из вышеперечисленных решений На самом деле, мне кажется достаточно удовлетворительным.
Так как я впервые создаю веб-приложение, мне интересно, как другие языки программирования, фреймворки или стеки решают эту проблему, или просто планирую задание. не входит в объем приложения, и о нем следует позаботиться в некоторых других местах.
Ps На мой взгляд, планировщик должен быть ...
Независимо от ОС, не зависит от интерфейса / функции ОС, поэтому приложение является переносимым, т. Е. Может работать в любом стеке.
Простое объединение в стек, без дополнительных команда для установки / запуска / остановки, запускается при запуске приложения, выкл. Когда приложение остановлено.
Привязка / обработка в приложении. Кроме того, согласно пункту 2., приложение отвечает за выполнение любых неправильно уволенных заданий в случае простоя. (с тех пор, как я проверял в последний раз, ни одна из ОС не предоставляла такой функции)