Miluji úpravy kódu SQL Server za účelem zlepšení výkonu, ale občas se vyskytnou scénáře, kdy i po vyladění kódu, indexování a návrhu uživatelské úlohy z aplikace trvá dokončení déle, než očekává koncový uživatel. Když k tomu dojde, uživatelské rozhraní musí buď počkat na dokončení procesu, nebo musíme přijít s alternativním způsobem zpracování úkolu. Asynchronní zpracování poskytované Service Broker se hodí pro mnoho z těchto scénářů a umožňuje zpracování na pozadí dlouho běžící úlohy provádět odděleně od uživatelského rozhraní, což uživateli umožňuje okamžitě pokračovat v práci, aniž by čekal, až bude úloha skutečně provedena. . Doufám, že v několika mých příštích článcích vytvořím sérii o tom, jak můžete využít Service Broker s příslušnými vysvětleními a příklady kódu, aby bylo snazší využívat schopnosti Service Broker bez problémů s implementací.
Metody provádění asynchronního zpracování
Existuje řada způsobů, jak se vypořádat s dlouho běžícím, ale již vyladěným procesem. Kód aplikace lze také přepsat tak, aby používal BackgroundWorker, ThreadPool na pozadí nebo ručně napsané řešení založené na vláknech v .NET, které provádí operaci asynchronně. To však umožňuje aplikaci odeslat neomezený počet těchto dlouho běžících procesů, pokud není provedena další kódovací práce pro sledování a omezení počtu aktivních procesů. To znamená, že aplikace bude mít potenciální dopad na výkon nebo při zatížení narazí na limit a vrátí se k předchozímu čekání, kterému jsme se původně snažili zabránit.
Také jsem viděl, jak se tyto typy procesů změnily na úlohy SQL Agent vázané na tabulku, která se používá k ukládání informací ke zpracování. Poté je úloha naplánována tak, aby se spouštěla pravidelně, nebo ji spouští aplikace pomocí sp_start_job když je změna uložena ke zpracování. To však umožňuje pouze sériové spouštění dlouho běžících procesů, protože SQL Agent neumožňuje spouštění úlohy vícekrát současně. Úloha by také musela být navržena tak, aby zvládla scénáře, kdy do tabulky zpracování vstupuje více řádků, aby došlo ke správnému pořadí zpracování a následné odeslání byly zpracovány odděleně.
Využití Service Broker pro asynchronní zpracování v SQL Server ve skutečnosti řeší omezení s výše uvedenými metodami pro zpracování asynchronního zpracování. Implementace brokera umožňuje zařazení nových úloh do fronty pro asynchronní zpracování na pozadí a také umožňuje paralelní zpracování úloh, které byly zařazeny do fronty až do nastaveného limitu. Na rozdíl od toho, že aplikační vrstva musí čekat, když je dosaženo limitu, řešení zprostředkovatele jednoduše zařadí přijatou novou zprávu do fronty a umožní ji zpracovat, když se dokončí některý z aktuálních úloh zpracování — to aplikaci umožňuje pokračovat bez čekání.
Konfigurace zprostředkovatele jedné databázové služby
I když se konfigurace Service Broker mohou stát složitými, pro jednoduché asynchronní zpracování potřebujete znát pouze základní koncepty pro vytvoření konfigurace jediné databáze. Konfigurace jedné databáze vyžaduje pouze:
- Vytvoření dvou typů zpráv
- Jeden pro vyžádání asynchronního zpracování
- Jedna pro návratovou zprávu po dokončení zpracování
- Smlouva používající typy zpráv
- Definuje, který typ zprávy je odeslán službou iniciátoru a který typ zprávy vrací cílová služba.
- Fronta, služba a postup aktivace pro cíl
- Fronta poskytuje úložiště zpráv odeslaných cílové službě službou iniciátor
- Procedura aktivace automatizuje zpracování zpráv z fronty
- Po dokončení zpracování požadovaného úkolu vrátí službě iniciátor dokončenou zprávu
- Zvládá http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog a http://schemas.microsoft.com/SQL/ServiceBroker/Error typy systémových zpráv
- Fronta, služba a postup aktivace pro iniciátora
- Fronta poskytuje úložiště zpráv odeslaných službě
- Procedura aktivace je volitelná, ale automatizuje zpracování zpráv z fronty
- Zpracuje dokončenou zprávu do cílové služby a ukončí konverzaci
- Zvládá http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog a http://schemas.microsoft.com/SQL/ServiceBroker/Error typy systémových zpráv
Kromě těchto základních komponent dávám přednost použití procedury uložené v obalu pro vytváření konverzace a odesílání zpráv mezi zprostředkovatelskými službami, aby byl kód čistý a aby bylo snazší škálování podle potřeby implementací opětovného použití konverzace nebo trikem 150 konverzací vysvětleným v whitepaper týmu SQLCAT. U mnoha jednoduchých konfigurací asynchronního zpracování nemusí být tyto techniky ladění výkonu nutné implementovat. Použitím uložené procedury wrapperu je však mnohem snazší změnit jediný bod v kódu namísto změny každé procedury, která v budoucnu odešle zprávu, pokud to bude nutné.
Pokud jste se na Service Broker nepodívali, může poskytnout alternativní metodu provádění odděleného zpracování asynchronně k vyřešení řady možných scénářů. V mém dalším příspěvku si projdeme zdrojový kód pro příklad implementace a vysvětlíme, kde by bylo potřeba provést konkrétní změny, aby bylo možné využít kód pro asynchronní zpracování.