Jag älskar att modifiera SQL Server-kod för att förbättra prestandan, men det finns ibland scenarier där det tar längre tid att slutföra en användaruppgift från applikationen efter att ha justerat koden, indexerat och designat längre än den förväntade slutanvändarupplevelsen. När detta händer måste användargränssnittet antingen vänta på att processen ska slutföras eller så måste vi komma på ett alternativt sätt att hantera uppgiften. Den asynkrona bearbetningen som tillhandahålls av Service Broker är en bra passform för många av dessa scenarier och tillåter bakgrundsbearbetning av den långvariga uppgiften att utföras separat från användargränssnittet, vilket gör att användaren kan fortsätta arbeta omedelbart utan att vänta på att uppgiften faktiskt ska utföras . Under mina kommande artiklar hoppas jag kunna skapa en serie om hur du kan dra nytta av Service Broker med lämpliga förklaringar och kodexempel längs vägen för att göra det lättare att dra nytta av Service Brokers möjligheter utan implementeringsproblem.
Metoder för att utföra asynkron bearbetning
Det finns ett antal sätt att hantera en långvarig, men redan avstämd process. Applikationskoden kan också skrivas om för att använda en BackgroundWorker, bakgrunden ThreadPool eller en manuellt skriven trådbaserad lösning i .NET som utför operationen asynkront. Detta tillåter dock att ett obegränsat antal av dessa långvariga processer skickas in av ansökan, såvida inte ytterligare kodningsarbete görs för att spåra och begränsa antalet aktiva processer. Detta innebär att applikationen kommer att ha en potentiell inverkan på prestanda, eller att under belastning kommer att träffa en gräns och återgå till den tidigare väntan vi försökte förhindra från början.
Jag har också sett den här typen av processer förvandlas till SQL Agent-jobb kopplade till en tabell som används för att lagra informationen som ska bearbetas. Sedan är jobbet antingen schemalagt att köras regelbundet eller startas av applikationen med sp_start_job när en ändring lagras för bearbetning. Detta tillåter dock bara en seriell exekvering av de långa processerna, eftersom SQL Agent inte tillåter att ett jobb körs flera gånger samtidigt. Jobbet måste också utformas för att hantera scenarier där flera rader kommer in i bearbetningstabellen så att korrekt ordningsföljd för bearbetning inträffar och efterföljande inlämningar behandlas separat.
Att utnyttja Service Broker för asynkron bearbetning i SQL Server åtgärdar faktiskt begränsningarna med de tidigare nämnda metoderna för att hantera den asynkrona bearbetningen. Mäklarimplementeringen tillåter att nya uppgifter köas för asynkron bearbetning i bakgrunden, och möjliggör också parallell bearbetning av de uppgifter som har köats upp till en konfigurerad gräns. Men till skillnad från att applikationsnivån måste vänta när gränsen nås, ställer mäklarlösningen helt enkelt det nya meddelandet som tas emot och låter det behandlas när en av de aktuella bearbetningsuppgifterna är klara – detta gör att applikationen kan fortsätta utan att vänta.
Single Databas Service Broker Configuration
Även om Service Broker-konfigurationer kan bli komplexa, behöver du för enkel asynkron bearbetning bara känna till de grundläggande begreppen för att bygga en enda databaskonfiguration. En enda databaskonfiguration kräver endast:
- Skapar två meddelandetyper
- En för att begära den asynkrona behandlingen
- Ett för returmeddelandet när bearbetningen är klar
- Ett kontrakt som använder meddelandetyperna
- Definierar vilken meddelandetyp som skickas av initiatortjänsten och vilken meddelandetyp som returneras av måltjänsten
- En kö, tjänst och aktiveringsprocedur för målet
- Kön tillhandahåller lagring av meddelanden som skickas till måltjänsten av initiatortjänsten
- Aktiveringsproceduren automatiserar behandlingen av meddelanden från kön
- Returnerar ett slutfört meddelande till initiatortjänsten när den har slutfört bearbetningen av en begärd uppgift
- Hanterar systemmeddelandetyperna http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog och http://schemas.microsoft.com/SQL/ServiceBroker/Error
- En kö, tjänst och aktiveringsprocedur för initiatorn
- Kön tillhandahåller lagring av meddelanden som skickas till tjänsten
- Aktiveringsproceduren är valfri men automatiserar behandlingen av meddelanden från kön
- Behandlar det färdiga meddelandet till måltjänsten och avslutar konversationen
- Hanterar systemmeddelandetyperna http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog och http://schemas.microsoft.com/SQL/ServiceBroker/Error
Utöver dessa grundläggande komponenter föredrar jag att använda en omslagslagrad procedur för att skapa en konversation och skicka meddelanden mellan mäklartjänster för att hålla koden ren och göra det lättare att skala efter behov genom att implementera konversationsåteranvändning eller tricket 150 konversationer som förklaras i SQLCAT-teamets whitepaper. För många av de enkla asynkrona bearbetningskonfigurationerna kanske dessa prestandajusteringstekniker inte behöver implementeras. Men genom att använda en omslagslagrad procedur blir det mycket lättare att ändra en enda punkt i koden, istället för att ändra varje procedur som skickar ett meddelande i framtiden, om det skulle bli nödvändigt.
Om du inte har gett Service Broker en titt, kan det vara en alternativ metod för att utföra frikopplad bearbetning asynkront för att lösa ett antal möjliga scenarier. I mitt nästa inlägg går vi igenom källkoden för ett exempel på implementering och förklarar var specifika ändringar skulle behöva göras för att utnyttja koden för asynkron bearbetning.