Kommunikationsprotokoll för Service Broker

gäller för:SQL ServerAzure SQL Managed Instance

Service Broker använder ett asynkront protokoll för att kommunicera med fjärrkoordinatorer. Asynkron meddelandekö hanterar anslutningar separat från den normala poolen med klientanslutningar. För att två SQL Server-instanser ska kunna utbyta Service Broker-meddelanden måste varje instans kunna skicka TCP/IP-trafik till porten som den andra instansen använder för Service Broker-kommunikation. Enligt konventionen använder Service Broker ofta port 4022 för broker-to-broker-kommunikation. Den exakta porten anges dock när slutpunkten skapas.

Protokolllager

Service Broker använder ett skiktat sätt att kommunicera. Varje lager bygger på det underliggande lagret för att säkerställa tillförlitlig leverans. Med den här metoden kan ett program fungera utan kunskap om platsen för fjärrtjänsten eller den fysiska transport som mäklaren använder för att kommunicera. I de flesta fall är dessa protokoll transparenta för ett program. Att förstå vilken roll varje protokollskikt spelar kan dock hjälpa dig att felsöka problem med ett program.

Det protokoll på högsta nivån som asynkron meddelandekö använder är dialogprotokollet. Dialogprotokolllagret hanterar tillförlitlig, sekvenserad meddelandeöverföring. Dialogprotokolllagret genererar sekvensnummer för meddelanden, genererar bekräftelsemeddelanden, levererar meddelanden till rätt köer och fragment och sätter ihop meddelanden igen. Dialogprotokollet hanterar autentisering och kryptering för en dialogruta.

Dialogprotokollet använder det intilliggande koordinatorprotokollet för att överföra meddelandefragment. Det intilliggande broker-protokollet hanterar de nätverksöverföringar som utbyts mellan två broker-instanser.

Det intilliggande koordinatorprotokollet använder ett transportprotokoll, till exempel TCP/IP, för att flytta meddelanden från asynkron meddelandekö till koordinator.

Dialogprotokoll

Dialogprotokollet hanterar leveransmönstret exakt en gång i ordningen (EOIO) för meddelanden i en konversation. Det här protokollet beskriver inte det format som Service Broker-meddelanden använder i nätverket. I stället anger protokollet de logiska steg som krävs för en tillförlitlig konversation. Dialogprotokollet hanterar de uppgifter som krävs för tillförlitlig leverans, inklusive att generera och bearbeta bekräftelsemeddelanden.

Varje sida av en konversation är en slutpunkt i dialogprotokollskiktet Katalogvyn sys.conversation_endpoints visar information om dialogprotokollslutpunkter. Det finns en konversationsslutpunkt under konversationens livslängd.

Intilliggande koordinatorprotokoll

Det intilliggande broker-protokolllagret hanterar kommunikationsmekaniken mellan två SQL Server-instanser. Det här lagret kodar varje meddelandefragment till ett standardformat som lämpar sig för överföring över nätverket. Till skillnad från dialogprotokollskiktet är det intilliggande protokollskiktet medvetet om den nätverkstransport som används och formaterar meddelandefragmenten på rätt sätt. I själva verket tillhandahåller det intilliggande koordinatorprotokolllagret ett abstraktionslager mellan dialogprotokolllagret och transportprotokollskiktet.

Varje Service Broker-nätverksanslutning är en slutpunkt i det intilliggande protokolllagret. Vyn sys.dm_broker_connections dynamisk hantering visar information om Service Broker-nätverksanslutningar. Service Broker underhåller nätverksanslutningen medan meddelanden utbyts aktivt. Service Broker stänger nätverksanslutningen när inga meddelanden har skickats eller tagits emot via nätverksanslutningen under en kort tidsperiod.

Transportprotokoll

Transportprotokolllagret hanterar den faktiska nätverksöverföringen. Det här lagret ligger utanför Service Broker. Meddelanden till en asynkron meddelandekö som körs i en annan instans av SQL Server använder TCP/IP som transportprotokollskikt.

Service Broker-slutpunkter anger alternativ för transportprotokollet. SQL Server innehåller inte Service Broker-slutpunkter som standard. Mer information om hur du skapar en Service Broker-slutpunkt finns i Så här aktiverar du Service Broker-nätverk.

Meddelandebearbetning för Service Broker

Service Broker använder två olika kategorier av meddelanden. Ett sekvenserat meddelande är ett meddelande som måste levereras till ett program exakt en gång, i ordning. Ett icke-sekvenserat meddelande är ett meddelande som kan bearbetas omedelbart, oavsett i vilken ordning meddelandet tas emot.

Service Broker använder sekvenserade meddelanden för alla användardefinierade meddelandetyper, slutdialogrutor och felmeddelanden som skapats av ett program. Varje sekvenserat meddelande har ett sekvensnummer. Den instans som kommer från meddelandet skapar meddelandesekvensnumret och tilldelar sekvensnumret till meddelandet. Den mottagande asynkron meddelandekö använder meddelandesekvensnumret för att beställa de meddelanden som den tillhandahåller till ett program. För en viss dialogruta tar programmet alltid emot meddelandet med det lägsta sekvensnumret först. Service Broker använder också meddelandesekvensnumret för att identifiera duplicerade meddelanden. När dialogprotokolllagret tar emot två meddelanden i samma dialogruta med samma sekvensnummer anser dialogprotokolllagret att meddelandena är dubbletter och tar bort ett.

Service Broker använder icke-sekvenserade meddelanden för dedikerade bekräftelsemeddelanden och felmeddelanden som skapats av Service Broker. Service Broker vidtar inga särskilda försiktighetsåtgärder för att leverera ett icke-sekvenserat meddelande. Service Broker skapar dock icke-sekvenserade meddelanden som svar på inkommande meddelanden. Om det icke-sekvenserade meddelandet går förlorat försöker avsändaren därför igen med det ursprungliga meddelandet. mottagaren genererar sedan ett annat icke-sekvenserat meddelande.

Meddelandefragmentering

Service Broker delar upp utgående meddelanden i fragment och kombinerar inkommande fragment i det ursprungliga meddelandet. För små meddelanden finns hela meddelandet i ett fragment. För stora meddelanden skapar Service Broker många fragment.

Fragmentering av meddelanden har flera fördelar. Att skicka ett stort meddelande i små fragment förbättrar den övergripande hastigheten och tillförlitligheten vid kommunikation över relativt långsamma och otillförlitliga nätverk som Wide-Area Networks (WAN). Om ett fragment av meddelandet går förlorat överförs protokollet bara ett fragment i stället för det fullständiga meddelandet. Fragmentering av stora meddelanden kan också minska den tid som krävs för att ett litet meddelande ska nå målet. Service Broker kan skicka ett fragment som innehåller ett fullständigt litet meddelande mellan fragment av ett stort meddelande. Detta saktar ned det stora meddelandet något för att minska tiden som det lilla meddelandet väntar på att överföras.

När ett meddelande sätts ihop igen lagras det partiella meddelandet i målkön. Om målkön inte är tillgänglig lagras den i överföringskö. Ett partiellt meddelande kan inte tas emot av ett program. Kolumnen status för ett partiellt meddelande är inställd på 2 (Inaktiverad). Det här värdet används också för meddelanden som tas emot i fel ordning.

Meddelandebekräftelse

Service Broker bekräftar varje mottaget meddelande. En bekräftelse kan bekräfta ett eller flera meddelandefragment. Om möjligt ingår en bekräftelse i rubriken för ett meddelande som returneras i samma konversation. Om inga andra meddelanden är redo att skickas returnerar Service Broker ett dedikerat bekräftelsemeddelande. Meddelandebekräftelse hanteras helt av Service Broker; ett program som använder Service Broker tar inte emot dessa meddelanden.

En avsändare behåller meddelandefragment som mottagaren inte har bekräftat. Om ingen bekräftelse tas emot inom en systemdefinierad väntetid skickar avsändaren meddelandefragmentet igen. Om ingen bekräftelse tas emot under väntetiden ökar Service Broker exponentiellt tiden före nästa återförsök, upp till en maximal väntetid. Den första väntetiden för ett nytt försök är några sekunder. Den maximala väntetiden är cirka en minut. Väntetiden är inte avsedd att vara exakt. beroende på nätverkstrafik och den andra aktiviteten i SQL Server-instansen kanske ett meddelandefragment inte försöker igen på några sekunder efter att väntetiden upphör att gälla.

Om en bekräftelse går förlorad eller fördröjs kan mottagaren få dubbletter av meddelanden. I det här fallet bekräftar mottagaren mottagandet av det duplicerade meddelandet, men levererar inte det duplicerade meddelandet till kön.

Service Broker använder meddelandebekräftelse för att tillhandahålla tillförlitliga meddelanden utan distribuerade transaktioner. En mottagare skickar endast en bekräftelse när meddelandet eller meddelandefragmentet har lagts till i kön. Avsändaren innehåller meddelandet i överföringskö tills bekräftelsen för meddelandet kommer. Även om avsändaren och mottagaren aldrig delar en transaktion garanterar protokollet att avsändaren inte tar bort meddelandet från överföringskö förrän mottagaren har tagit emot meddelandet.

Kontroll av meddelandeintegritet

Det format som Service Broker använder för att överföra meddelanden innehåller en kontroll av meddelandeintegritet för att avgöra om ett visst meddelande har ändrats eller skadats under transporten.

Kontrollen av meddelandeintegritet är en MD5-signatur för innehållet i meddelandet. SQL Server krypterar signaturen med sessionsnyckeln för meddelandet och innehåller signaturen i meddelanderubrikerna.

Målet för meddelandet dekrypterar meddelandet och jämför sedan signaturen i meddelandet med en ny signatur som beräknas över det faktiska innehållet som tas emot. Om signaturerna inte matchar har meddelandet skadats eller manipulerats under överföringen. Meddelandet misslyckas med meddelandets integritetskontroll. SQL Server tar bort meddelandet och bekräftar inte meddelandet till avsändaren. Händelseklassen Broker:Corrupted Message rapporterar information när ett meddelande misslyckas med meddelandets integritetskontroll.

Överföringsobjekt för Service Broker

Ett Service Broker-överföringsobjekt är ett minnesinternt objekt som hanterar och registrerar tillståndet för meddelandeöverföringar för en dialogruta. Varje konversationsslutpunkt har ett överföringsobjekt.

En dialogruta begär ett överföringsobjekt när det gör följande:

• Skickar ett meddelande via överföringskö. Detta inkluderar följande:

  • Alla meddelanden som skickas till en fjärrinstans av databasmotorn

  • Meddelanden till skickade köer i den lokala instansen om meddelandet inte kan infogas direkt i målkön

• Tar emot antingen ett fjärrmeddelande eller ett meddelande som kommer från en lokal överföringskö.

Ett överföringsobjekt skapas första gången som en dialogruta begär ett. Service Broker använder samma överföringsobjekt för efterföljande begäranden från den dialogrutan. Överföringsobjekt ändras varje gång som Service Broker måste registrera en ändring i tillståndet för överföringar för dialogrutan. Överföringsobjekt är cirka 1 KB.

För att frigöra minne lagrar Service Broker regelbundet batchar med inaktiva överföringsobjekt i tempdb arbetstabeller. När ett överföringsobjekt först ändras i minnet markeras det som smutsigt. Överföringsobjektet förblir markerat som smutsigt tills det töms till en arbetstabell.

Överföringsobjekt används inte för att antingen skicka eller ta emot lokala meddelanden som kan infogas direkt i målkön.

Nätverkskommunikationsflöde

Följande bild visar en övergripande vy över Service Broker-nätverkskommunikation mellan två SQL Server-instanser.

Konversationen är en beständig, logisk anslutning. Konversationen kan ske under vilken tidsperiod som helst, och under den tidsperioden kan konversationen använda valfritt antal nätverksanslutningar.

Nätverksanslutningar sker mellan två Service Broker-slutpunkter. Dessa anslutningar använder TCP/IP. Om anslutningen är inaktiv under en kort tid stänger SQL Server nätverksanslutningen.

För att leverera ett meddelande innehåller Service Broker meddelandet i överföringskö för databasen som skickade meddelandet. Mottagaren levererar meddelandet direkt till kön för måltjänsten. Om kön är OFFlagras meddelandet tillfälligt i överföringskö för den mottagande databasen. Kön för den sändande tjänsten ingår inte i åtgärden. Överföringskö för den databas som är värd för den mottagande tjänsten är bara involverad om målkön är OFF.

Relaterat innehåll

• Service Broker-routning