Обичам да променям кода на SQL Server, за да подобря производителността, но понякога има сценарии, при които дори след настройка на кода, индексирането и проектиране на потребителска задача от приложението отнема повече време за изпълнение от очакваното изживяване на крайния потребител. Когато това се случи, потребителският интерфейс или трябва да изчака процеса да завърши, или трябва да измислим алтернативен начин за справяне със задачата. Асинхронната обработка, осигурена от Service Broker, е подходяща за много от тези сценарии и позволява фоновата обработка на продължителната задача да се извършва отделно от потребителския интерфейс, което позволява на потребителя да продължи да работи незабавно, без да чака задачата действително да бъде изпълнена . В следващите си няколко статии се надявам да създам поредица за това как можете да използвате Service Broker с подходящи обяснения и примери за код по пътя, за да улесните използването на възможностите на Service Broker без проблеми с внедряването.
Методи за извършване на асинхронна обработка
Има няколко начина да се справите с продължителен, но вече настроен процес. Кодът на приложението може също да бъде пренаписан за използване на BackgroundWorker, фонов ThreadPool или ръчно написано Thread базирано решение в .NET, което изпълнява операцията асинхронно. Това обаче позволява неограничен брой от тези продължителни процеси, които да бъдат изпратени от приложението, освен ако не се извърши допълнителна работа по кодиране за проследяване и ограничаване на броя на активните процеси. Това означава, че приложението ще има потенциално въздействие върху производителността или при натоварване ще достигне лимит и ще се върне към предишното изчакване, което първоначално се опитвахме да предотвратим.
Виждал съм също този тип процеси, превърнати в задачи на SQL агент, обвързани с таблица, която се използва за съхраняване на информацията за обработка. След това заданието или се планира да се изпълнява периодично, или се стартира от приложението с помощта на sp_start_job когато промяната се съхранява за обработка. Това обаче позволява само серийно изпълнение на продължителните процеси, тъй като SQL Agent не позволява едно задание да се изпълнява няколко пъти едновременно. Заданието също трябва да бъде проектирано така, че да обработва сценарии, при които множество редове влизат в таблицата за обработка, така че да се получи правилният ред на обработка и последващите подавания да се обработват отделно.
Използването на Service Broker за асинхронна обработка в SQL Server всъщност адресира ограниченията с гореспоменатите методи за обработка на асинхронната обработка. Внедряването на брокера позволява нови задачи да се поставят на опашка за асинхронна обработка във фонов режим и също така позволява паралелна обработка на задачите, които са били наредени на опашка до конфигуриран лимит. Въпреки това, за разлика от нивото на приложението, което трябва да изчака, когато се достигне лимита, решението на брокера просто поставя на опашка полученото ново съобщение и позволява то да бъде обработено, когато една от текущите задачи за обработка завърши — това позволява на приложението да продължи без чакане.
Конфигурация на брокер на услуга за единична база данни
Докато конфигурациите на Service Broker могат да станат сложни, за проста асинхронна обработка трябва да знаете само основните концепции за изграждане на конфигурация на единна база данни. Една конфигурация на база данни изисква само:
- Създаване на два типа съобщения
- Един за заявка за асинхронна обработка
- Едно за съобщението за връщане, когато обработката приключи
- Договор, използващ типовете съобщения
- Определя кой тип съобщение се изпраща от услугата инициатор и кой тип съобщение се връща от целевата услуга
- Опашка, услуга и процедура за активиране за целта
- Опашката осигурява съхранението на съобщения, изпратени до целевата услуга от услугата инициатор
- Процедурата за активиране автоматизира обработката на съобщения от опашката
- Връща завършено съобщение на услугата инициатор, когато завърши обработката на заявена задача
- Обработва системните типове съобщения http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog и http://schemas.microsoft.com/SQL/ServiceBroker/Error
- Опашка, услуга и процедура за активиране за инициатора
- Опашката осигурява съхранение на съобщения, изпратени до услугата
- Процедурата за активиране не е задължителна, но автоматизира обработката на съобщения от опашката
- Обработва завършеното съобщение до целевата услуга и прекратява разговора
- Обработва системните типове съобщения http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog и http://schemas.microsoft.com/SQL/ServiceBroker/Error
В допълнение към тези основни компоненти, предпочитам да използвам съхранена процедура в обвивка за създаване на разговор и изпращане на съобщения между брокерски услуги, за да поддържам кода чист и да го направя по-лесен за мащабиране, ако е необходимо чрез внедряване на повторно използване на разговор или трика за 150 разговор, обяснен в бялата книга на екипа на SQLCAT. За много от простите конфигурации за асинхронна обработка, тези техники за настройка на производителността може да не се налага да се прилагат. Въпреки това, чрез използване на съхранена процедура в обвивка, става много по-лесно да промените една точка в кода, вместо да променяте всяка процедура, която изпраща съобщение в бъдеще, ако се наложи.
Ако не сте разгледали Service Broker, той може да предостави алтернативен метод за асинхронно извършване на отделена обработка за решаване на редица възможни сценарии. В следващата ми публикация ще разгледаме изходния код за примерна реализация и ще обясним къде трябва да се направят конкретни промени, за да се използва кодът за асинхронна обработка.
