Если есть вероятность, что каждую минуту выполняется какая-то работа, запланированная работа не так уж плоха. И даже если это маловероятно, использование постоянного интервала планирования может быть адекватным выбором, потому что он очень надежен и обычно имеет лучшее поведение в худшем случае, когда многие элементы готовы (из-за примерно постоянной нагрузки).

Но в понятии «каждую минуту» есть недостаток. Прежде всего, если задание не запустится один раз, события в эту минуту будут потеряны навсегда. И если работа занимает более одной минуты, могут возникнуть аналогичные проблемы.

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

Однако, если вы хотите выполнение на основе событий, т. е. не запускать задание до тех пор, пока элемент не будет готов к обработке, вам обязательно понадобится какой-то демон, работающий в фоновом режиме, который планирует задачи по готовности. Некоторые базы данных имеют встроенные планировщики, которые могут выполнять эту работу. Команда Unix at также может выполнить эту работу. (Учитывайте проблемы с часовым поясом.)

Итак, если у вас есть какой-то демон, который может выполнять задание в заданное время, вам нужно накормить этого демона. Каждый раз, когда обновление базы данных приводит к изменению времени следующей регистрации, вам необходимо настроить время запуска следующего задания. Для этой цели можно использовать триггер базы данных. Но вам нужно знать об условиях гонки, потому что одновременные обновления могут запускаться параллельно. Вам также необходимо позаботиться о потерянных запусках из-за неожиданного сбоя системы или по какой-либо другой причине. т.е. требуется определенный вид мониторинга.

Я бы не рекомендовал запускать новое задание для каждого элемента, чтобы избежать описанной выше сложности, поскольку это может привести к чрезмерному использованию ресурсов. Кроме того, это требует еще большего контроля.

Вывод

Если нет веских причин не делать этого, циклическое запланированное задание, которое проверяет работу, является простым и надежным решением.

Более сложный способ планировать только тогда, когда есть что обрабатывать, рекомендуется, если энергопотребление является проблемой и/или интервал планирования должен быть очень маленьким, чтобы выполнить планирование время очень точно. Например. ядро ОС использует эту технику, чтобы избежать ненужных пробуждений ЦП, но здесь мы говорим о точности в диапазоне миллисекунд.