Выбор стратегии запуска
В этом разделе описаны параметры активации компонента Service Broker.
Компонент Service Broker поддерживает асинхронный обмен сообщениями посредством очередей. Поскольку диалоги могут продолжаться в течение нескольких дней, месяцев или лет, для динамического масштабирования во многих приложениях применяется активация. В этом подразделе описаны некоторые распространенные стратегии для запуска приложения, использующего компонент Service Broker.
Стратегии запуска
Стратегии запуска приложения разделяются на четыре крупные категории:
внутренняя активация;
активация на основе событий;
планируемая задача;
задача запуска.
Каждая стратегия активации обладает уникальными преимуществами. Приложение может сочетать различные стратегии. Например, в приложении в течение большей части времени может использоваться внутренняя активация для небольшого числа агентов чтения очереди. Но в определенное время суток приложение может запускать дополнительные агенты чтения очереди.
Внутренняя активация
Если в компоненте Service Broker используется внутренняя активация, то наблюдение за очередью компонента Service Broker непосредственно активирует хранимую процедуру в случае необходимости. Такой подход чаще всего является самым простым и очевидным. Использование прямой активации хранимой процедуры устраняет необходимость написания в приложении дополнительного кода для управления активацией. Однако для внутренней активации необходимо, чтобы приложение было создано в виде хранимой процедуры SQL Server. В случае использования внутренней активации код приложения должен завершать работу, когда не остается сообщений для обработки.
Активация на основе событий
Некоторые приложения запускаются в ответ на определенное событие. Например, можно запускать приложение, когда загрузка процессоров на компьютере опускается ниже определенного уровня, или запускать приложение, работающее с журналом, когда создается новая таблица.
Внешняя активация компонента Service Broker является частным случаем активации на основе событий. В случае внешней активации приложение запускается в ответ на событие QUEUE_ACTIVATION.
Для событий, которые могут запускаться уведомлениями о событиях, активацию на основе событий можно сочетать с внутренней активацией компонента Service Broker. В этом случае внутренняя активация применяется в очереди, которая получает уведомление о событии. Хранимая процедура активации получает сообщение уведомления и запускает приложение.
Для других событий можно использовать агент SQL Server для запуска заданий на том же компьютере, где работает SQL Server. Можно написать приложение, которое наблюдает за событиями инструментария управления Windows (WMI) с удаленного компьютера. Приложение может запускать задачу, когда на компьютере, где работает SQL Server, происходит событие инструментария WMI.
В случае использования активации на основе событий приложение обычно завершает работу, когда не остается сообщений для обработки.
Планируемая задача
В случае планируемой задачи приложение активируется по заданном расписанию. Эта стратегия хорошо подходит для приложений пакетной обработки. Приложение, которое выполняется в виде планируемой задачи, может завершать работу, когда не остается сообщений для обработку, или прекращать выполнение программы в определенное время.
Например, приложение, обрабатывающее заказы для поставщика, может хранить сообщения в течения дня, а ночью обрабатывать сообщения, образуя единый заказ. В этом случае приложение может использовать задание агента SQL Server, чтобы запускать приложение каждую ночь в определенное время.
Задача запуска
Некоторые приложения запускаются однократно, обычно при загрузке компьютера или запуске SQL Server. Примерами таких задач служат хранимая процедура запуска в SQL Server, приложение в группе запуска Windows и служба Windows. В этом случае приложение продолжает работу и обрабатывает сообщения по мере их прибытия. Приложению, которое работает постоянно, не нужно время на запуск, когда в очередь прибывает сообщение. Однако поскольку такое приложение не завершает работу, когда не остается сообщений для обработки, то программа расходует ресурсы даже в случае, когда для нее нет работы.
Такая стратегия может быть полезной для приложения, которое обрабатывает постоянный поток сообщений и которое предъявляет относительно высокие требования к объему ресурсов во время запуска.
См. также