Преимущества компонента Service Broker
Используя средства компонента Service Broker, приложения баз данных получают ряд значительных преимуществ. К числу этих функций и преимуществ относятся:
Интеграция баз данных повышает производительность приложений и упрощает администрирование.
Упорядочение сообщений и координация упрощает процесс разработки приложений
Слабое связывание приложений обеспечивает возможность гибкого регулирования рабочих нагрузок.
Блокировка связанных сообщений позволяет использовать несколько экземпляров приложений для обработки сообщений из одной очереди без явной синхронизации.
Благодаря автоматической активации приложения могут масштабироваться в зависимости от количества сообщений.
Интеграция баз данных
Благодаря интегрированной структуре компонента Service Broker повышается быстродействие приложений и облегчается администрирование.
Интеграция с SQL Server обеспечивает возможность обмена транзакционными сообщениями без увеличения накладных расходов и без сложностей, возникающих в случае использования внешнего координатора распределенных транзакций. Приложение получает одно или несколько сообщений, обрабатывает это сообщение или сообщения и передает ответное сообщение в рамках одной транзакции базы данных. Если происходит сбой в выполнении транзакции, все действия отменяются и полученное сообщение возвращается в очередь, что дает возможность предпринять еще одну попытку его обработки. Никакие действия не могут вступить в силу до тех пор, пока приложение не зафиксирует транзакцию. Приложение остается в согласованном состоянии.
Задачи администрирования облегчаются, когда данные, сообщения и логика приложений сохраняются в базах данных, поскольку администрирование приложений (аварийное восстановление, обеспечение безопасности, резервное копирование данных и т. д.) в этих случаях становится частью повседневного управления базами данных и администратору не приходится иметь дело с тремя или четырьмя отдельными объектами.
При использовании традиционных систем обмена сообщениями может произойти потеря согласованности как хранилища сообщений, так и базы данных. Например, когда один из компонентов восстанавливается из резервной копии, другой компонент тоже должен быть восстановлен из резервной копии, снятой в то же время, иначе содержимое хранилища сообщений перестанет соответствовать сведениям из базы данных. Компонент Service Broker хранит сообщения и данные в одной и той же базе данных, поэтому проблем с согласованностью не возникает.
Еще одно преимущество, обеспечиваемое интеграцией баз данных, — это общая среда разработки. Разные части приложения, обрабатывающие сообщения и данные, могут применять одни и те же языки SQL Server и инструментальные средства приложения компонента Service Broker. Это дает возможность при организации работ по программированию модулей обработки сообщений воспользоваться тем обстоятельством, что разработчик знаком с приемами программирования баз данных. Реализующие компонент Service Broker хранимые процедуры можно писать на языке Transact-SQL или на одном из языков среды CLR. В программах, установленных вне базы данных, используется Transact-SQL и известные интерфейсы программирования баз данных, такие как ADO.NET.
В дополнение к этому интегрирование баз данных позволяет управлять ресурсами в автоматическом режиме. Компонент Service Broker выполняется в контексте экземпляра SQL Server, поэтому Service Broker отслеживает все сообщения, готовые к передаче всеми базами данных этого экземпляра. Поэтому все базы данных могут обслуживать собственные очереди и в то же время содействовать компоненту Service Broker в решении проблемы использования ресурсов во всем экземпляре SQL Server.
Упорядочивающие и координирующие сообщения
В традиционных системах обмена сообщениями ответственность за упорядочение и координирование сообщений, которые могут поступать в ненадлежащем порядке, возлагается на соответствующее приложение. Например, приложение A передает сообщения 1, 2 и 3. Приложение B получает сообщения 1 и 3 и подтверждает их прием, но при передаче сообщения 2 происходит ошибка. Приложение A вновь передает сообщение 2, причем теперь это сообщение принимается после сообщений 1 и 3. В прошлом в распоряжении разработчиков было два способа решения проблемы: или писать приложения таким образом, чтобы порядок поступления сообщений не имел значения, или помещать сообщение 3 во временный кэш до поступления сообщения 2 с тем, чтобы приложение могло обработать эти сообщения в надлежащем порядке. Как первое, так и второе решения не отличались ни эффективностью, ни простотой.
Для традиционных систем характерна еще одна проблема: дублирование доставки. Вернемся к предыдущему примеру. Если приложение B получает сообщение 2, но подтверждение приема, направленное приложению A, теряется, приложение A повторно передает сообщение 2, так что приложению B приходится получать сообщение 2 дважды. Поэтому код приложения нужно было писать таким образом, чтобы оно либо выявляло и отбрасывало дубликат, либо повторно обрабатывало дважды переданное сообщение без каких-либо отрицательных последствий. Опять-таки оба этих подхода было трудно реализовать.
Координирование сообщений также традиционно является трудноразрешимой проблемой. Например, приложение может направлять какой-либо службе сотни, а то и тысячи запросов. Служба осуществляет параллельную обработку этих запросов и возвращает ответ сразу же по завершении обработки соответствующего запроса. В связи с тем, что на обработку разных запросов уходит разное время, приложение получает ответы не в том порядке, в котором оно направляло исходящие запросы. Но приложение может обеспечить правильную обработку ответов лишь в том случае, если сможет корректно сопоставить каждый ответ с соответствующим исходным сообщением. В традиционных системах обмена сообщениями эта взаимосвязь выполнялась средствами приложений, что оборачивалось ростом издержек и повышением уровня сложности разработки приложений.
Компонент Service Broker решает эту проблему, обеспечивая автоматическое упорядочение сообщений, доставку без дубликатов, а также идентификацию диалогов. После установления диалога между двумя конечными точками компонента Service Broker приложения получают каждое сообщение только один раз и именно в том порядке, в котором эти сообщения были переданы. Приложения могут обрабатывать сообщения не более одного раза в надлежащем порядке, и никакого дополнительного кода для этого не требуется. Наконец, компонент Service Broker автоматически включает в каждое сообщение идентификатор. Приложения всегда имеют сведения о том, к какому диалогу относится то или иное сообщение.
Слабая связь и гибкое регулирование рабочих нагрузок
Компонент Service Broker обеспечивает слабую связь между инициирующим приложением и целевым приложением. Приложение может отправить сообщение в очередь и продолжать обработку, предоставив всю работу по доставке сообщения адресату компонента Service Broker. Слабая связь обеспечивает гибкость планирования. Приложение-инициатор может передавать множество сообщений, и несколько целевых служб могут параллельно выполнять их обработку. Каждая целевая служба осуществляет обработку сообщений в своем темпе, в зависимости от текущей рабочей нагрузки.
Возможность формирования очередей тоже способствует более равномерному распределению задач по обработке, что снижает требования к пиковой мощности серверов. Это дает возможность повысить общую пропускную способность и производительность приложений баз данных. Например, в определенное время суток количество транзакций, обрабатываемых многими приложениями баз данных, резко возрастает, что ведет к увеличению потребления ресурсов и к снижению времени отклика. С появлением компонента Service Broker этим приложениям уже не приходится выполнять все операции по обработке бизнес-транзакции при передаче ее приложению. Теперь это приложение с помощью компонента Service Broker передает сведения о транзакции прикладным программам, осуществляющим обработку в фоновом режиме. Эти приложения в течение определенного периода времени выполняют тщательную обработку транзакции, а расположенное «на входе» главное приложение продолжает получать новые бизнес-транзакции.
Если пункт назначения в данное время недоступен, сообщение остается в очереди передачи отправляющей базы данных. Компонент Service Broker осуществляет повторные попытки передачи до тех пор, пока сообщение не будет успешно отправлено, или до истечения срока поддержания диалога, что позволит продолжить надежный диалог между двумя службами даже в том случае, если в какой-то момент в ходе этого диалога одна из служб будет временно недоступна. Содержащиеся в очереди передачи сообщения являются частью соответствующей базы данных. Компонент Service Broker доставляет сообщение даже в случае аварийного переключения или повторного запуска данного экземпляра.
Блокировка связанных сообщений
Одна из самых сложных задач, с которыми приходится сталкиваться пользователям традиционных систем обмена сообщениями, состоит в том, как обеспечить параллельное обращение нескольких программ к одной и той же очереди. Когда к одной и той же очереди традиционной системы обмена сообщениями обращаются несколько программ или потоков, сообщения могут обрабатываться в произвольном порядке. Компонент Service Broker не допускает таких ситуаций с помощью блокировки групп сообщений.
Посмотрим, как функционирует традиционное приложение по обработке заказов. В очередь поступили как сообщение A, содержащее инструкции по формированию заголовка заказа, так и сообщение B, содержащее инструкции по созданию строк элементов заказа. Если оба эти сообщения будут извлечены из очереди различными экземплярами приложений и обработаны в одно и то же время, транзакция, обеспечивающая создание элементов строк заказа, может быть предъявлена для фиксации первой и не сможет состояться, потому что заказ пока еще не существует. Этот сбой в свою очередь приведет к откату транзакции, сообщение вновь поступит в очередь и будет вновь обработано, что обернется непроизводительным расходованием ресурсов. Традиционно программисты решали эту проблему путем объединения данных из сообщения A и из сообщения B в одно сообщение. Если приходится обрабатывать два сообщения, такой подход вполне эффективен, но, когда речь заходит о системах, координирующих десятки и сотни сообщений, на него вряд ли можно полагаться.
Компонент Service Broker решает эту проблему, объединяя связанные сообщения в группы сообщений. Компонент Service Broker автоматически блокирует все сообщения в одной группе сообщений, так что эти сообщения могут быть получены и обработаны одним экземпляром приложения. Между тем другие экземпляры приложения могут продолжать извлекать из очереди и обрабатывать сообщения из других групп сообщений Таким образом обеспечивается возможность надежной и эффективной работы нескольких параллельных экземпляров приложений и снимается необходимость включения в приложение сложных кодов блокировки.
Автоматическая активация
Одна из наиболее полезных функций компонента Service Broker — это активация. Активация позволяет приложению динамически масштабировать себя при изменении количества поступающих в очередь сообщений. Компонент Service Broker оснащен средствами, позволяющими как программам, выполняемым внутри базы данных, так и программам, выполняемым вне базы данных, пользоваться преимуществами активации. Однако компонент Service Broker не требует от приложений обязательного использования функции активации.
Компонент Service Broker отслеживает события очереди, чтобы определить, получает ли приложение сообщения по всем диалогам, которые имеют доступные сообщения. Активация компонента Service Broker запускает агент чтения очереди в тех случаях, когда для этого агента есть работа. Чтобы определить, есть ли работа для агента чтения очереди, компонент Service Broker отслеживает события очереди. Когда число запущенных агентов чтения очереди оказывается соразмерным входящему трафику, в очереди периодически создается такое положение, при котором либо в очереди вообще нет сообщений, либо все сообщения в очереди принадлежат диалогу, который в данное время обрабатывается другим агентом чтения очереди. Если же на протяжении некоторого времени очередь не попадает в эту ситуацию, компонент Service Broker активирует еще один экземпляр приложения.
Процедура активации по-разному реализуется в приложениях в зависимости от того, идет ли речь о программах, выполняемых внутри базы данных, или о программах, выполняемых вне базы данных. Для программ, выполняемых внутри базы данных, компонент Service Broker запускает еще одну копию хранимой процедуры, заданной в очереди. Для программ, выполняемых вне базы данных, компонент Service Broker создает событие активации. Программа следит за этим событием, чтобы определить, когда потребуется подключение еще одного агента чтения очереди.
Компонент Service Broker не приостанавливает выполнение программ, запущенных с использованием процедуры активации. Дело в том, что активируемые приложения автоматически закрываются по истечении определенного периода времени, после того как ими было получено последнее сообщение. Написанное таким образом приложение обеспечивает динамическое увеличение и сокращение числа своих экземпляров в зависимости от изменения объема трафика, поступающего к службе. Кроме того, если система закрывается или перезагружается, в момент повторного старта системы автоматически запускаются приложения для чтения сообщений в очереди.
Традиционные системы обмена сообщениями не наделены такими возможностями, и в ходе их эксплуатации часто возникают ситуации, когда в любой данный момент для той или иной очереди выделяется либо слишком много, либо слишком мало ресурсов.