Это открытый вопрос, но позвольте мне предложить некоторые потенциальные подходы к проектированию.
Предполагая, что у вас много пользователей, у каждого пользователя есть много расписаний, и у каждого расписания есть спецификация времени (формат cron иличто угодно): хранить с каждым расписанием время последнего запуска расписанияСоздайте отдельное «задание» (задачу, программу и т. Д.), Которое при запуске циклически просматривает всех ваших пользователей и оценивает их расписания: для каждого расписания используйте последний запуск времени и его спецификацию времени для расчета следующего запланированноговремя для запуска, и если текущее время уже или прошло, добавьте расписание в список.Затем выполните цикл по списку, запустите каждый Расписание (независимо от того, что это влечет за собой) и обновите время последнего запуска.
Создавая свою работу таким образом, вы можете выбрать использование cron или нет.Вы можете запускать эту программу вручную один раз в день, вы можете запланировать ее запуск каждые 60 секунд на вашем основном сервере приложений (вероятно, для многих запусков она завершится без каких-либо действий, так как больше нет пользователей, которые должны запускать расписания).Я думаю, что системный cron все еще полезен для планирования задач такого типа, но это зависит от вас.
В масштабе (скажем, у вас 100 000 пользователей с 1-5 расписаниями в каждом), я бы предложилсистема очередей на основе работы.Используя что-то вроде node-resque , вы можете использовать cron для запуска задания проверки расписания каждые 5 минут, что добавит отдельные задания расписания запуска для каждого расписаниячто нужно было бежать.В конечном итоге у вас будет слишком много пользователей для оценки в одной проверке расписания; задание проверки расписания можно изменить так, чтобы он просто подсчитывал ваших пользователей, отбрасывал их и запускал меньшие задания проверки расписания (один для пользователей 1-5000, один для пользователей 5001-10000,и тд и тп).Это позволило бы вам масштабироваться и использовать 5, 10 или 15 рабочих-ресквитеров.
(я предложил рескв, поскольку я фанат redis, но вы могли бы так же легко использовать другую систему очередей или дажеЕсли вы используете Jenkins на своем производстве, серию заданий Jenkins, которые запускают друг друга и используют рабочие машины Jenkins для выполнения заданий. Это преимущество структурирования вашего бегуна таким образом, вы можете отобразить его практически на любую технологию..)
Вам все еще предстоит решить множество задач: если все эти вызовы относятся к одному удаленному API, вам придется обнаруживать и обрабатывать перегрузку удаленного API и получать ошибки ограничения скорости (это можетвлияет на то, насколько велико решение о масштабировании, бессмысленно поддерживать 1000 запросов в секунду к удаленному серверу, если это будет стоить вам 5 запросов в секунду).Вы также можете подумать о том, что произойдет, если что-то сломается, и вы не выполняете задания в течение нескольких часов (в зависимости от вашего приложения, хотите ли вы, чтобы графики вашего пользователя «догоняли» и запускались позже, чем предполагалось для каждого запланированного запускаили он должен «пропустить» до последнего времени и игнорировать потерянное время).К другим нюансам относятся расписания, которые удаляются или изменяются пользователем, пока они находятся в очереди выполнения, и т. Д.
Удачи!