Как реализуются службы, которые срабатывают по расписанию?

#c_sharp #net #service

Предположим, нужно сделать службу, которая должна выполнять разного вида задачи по
некоторому расписанию, которое задается в конфигурации(Например, список времен и типов
задач).

Как это правильно делается?

Правильно ли создавать список таймеров, на каждый таймер привязывать обработчик события(В
зависимости от типа задачи), затем высчитывать время срабатывания в мс относительно
текущего времени, а потом запускать отсчет?

Нашел еще какой-то Quartz.NET... На сколько он хорош?
    

Ответы

Ответ 1

Quartz.NET не пробовал, попробуйте, вдруг понравится =)

Обычно "Правильно" у каждого свое, мои соображения следующие: 

1. Короткие интервалы (секунды, минуты)

Набор задач для коротких интервалов времени обычно фиксирован и задачи тесно связаны
между собой. Поэтому предложенный вами вариант будет вполне уместным, но есть и недостатки:
При перезапуске службы все задачи будут прерваны в произвольном месте, если не предусмотрен
особый код завершения работы службы, таймеры будут перезапущены. Для изменения интервалов
необходимо перезапускать службу, если не предусмотрена специальная команда для этого.

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

Альтернативой может служить набор консольных программ (одна задача - одна программа)
запускаемых с помощью системного планировщика. Для коротких интервалов преимущества
данного метода весьма сомнительны если вообще есть.

2. Средние интервалы (часы, дни)

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

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

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

3. Длинные интервалы (недели, месяцы, годы)

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

4. Неопределенные интервалы или работа по событию

Этот вариант конечно имеет малое отношение к таймерам, однако в рамках сравнения
двух подходов его стоит рассмотреть.

В службе необходимо предусмотреть код слушающий необходимые события. Обрабатываемые
события могут быть вынесены в конфигурацию, а вот добавление или удаление действий
без пересборки и переустановки службы уже не сделать.

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

В целом, для работы по событиям, можно считать оба способа равнозначными.

Собственный планировщик задач.

В некоторых случаях использовать системный планировщик не очень удобно. Тогда можно
реализовать свой. Идея довольно простая:


один таймер с фиксированным минимальным шагом, например раз в секунду.
по событию таймера сравниваем текущее время с расписанием запланированных заданий.
запускаем в отдельном потоке или процессе выполнение заданий, время которых меньше
либо равно текущему.


Ответ 2

Для простых случаев -- запускать задачу раз в N секунд/минут/часов, один инстанс
сервиса, нет критичных требований к запускам -- таймеров будет достаточно.

Если же вам нужны гибкие расписания (читай, cron expressions), фейловер, возможность
ребалансировки, персистентность, тогда лучше использовать Quartz.NET.