Dela via

Använda flera namnområden för att isolera program mot Service Bus-avbrott och katastrofer

Verksamhetskritiska program måste fungera kontinuerligt, även om det finns oplanerade avbrott eller katastrofer. Motståndskraft mot katastrofala avbrott i databehandlingsresurser är ett krav för många företag och i vissa fall till och med nödvändigt enligt branschregler.

Kommentar

Service Bus Geo-Disaster Recovery och Geo-Replication hjälper dig att återställa efter storskaliga katastrofer eller permanent överge en misslyckad Azure-region utan att kräva ändringar i programkonfigurationen. Mer information om dessa funktioner och hur du aktiverar tillförlitlighet och återhämtning i Azure Service Bus finns i Tillförlitlighet i Azure Service Bus.

Om du inte kan använda Geo-Disaster Recovery eller Geo-Replication för att uppfylla dina krav kan du distribuera flera Service Bus-namnområden. I den här artikeln beskrivs tekniker som du kan använda för att skydda program mot ett potentiellt tjänststopp eller haveri med hjälp av flera namnområden.

Replikeringstyper

För att uppnå motståndskraft mot katastrofer med Service Bus Standard-nivån kan du använda aktiv eller passiv replikering. Om en kö eller ett ämne måste vara tillgängligt under ett datacenterstopp skapar du samma entitet i båda namnrymderna. Entiteterna kan dela samma namn eftersom de finns i separata namnområden. Du kan till exempel nå en primär kö under contosoPrimary.servicebus.windows.net/myQueue, medan du kan nå dess sekundära motsvarighet under contosoSecondary.servicebus.windows.net/myQueue.

Kommentar

Konfigurationen av aktiv replikering och passiv replikering är allmänna begrepp och inte specifika funktioner i Service Bus. Replikeringslogik (skicka till 2 olika namnområden) finns i avsändarprogrammen och mottagaren måste ha anpassad logik för dubblettidentifiering.

Om programmet inte kräver permanent kommunikation mellan avsändare och mottagare kan programmet implementera en varaktig kö på klientsidan för att förhindra meddelandeförlust och skydda avsändaren från tillfälliga Service Bus-fel.

Aktiv replikering

Aktiv replikering använder entiteter i båda namnrymderna för varje åtgärd. Alla klienter som skickar ett meddelande skickar två kopior av samma meddelande. Den första kopian skickas till den primära entiteten (till exempel contosoPrimary.servicebus.windows.net/sales) och den andra kopian av meddelandet skickas till den sekundära entiteten (till exempel contosoSecondary.servicebus.windows.net/sales).

En klient tar emot meddelanden från båda köerna. Mottagaren bearbetar den första kopian av ett meddelande och den andra kopian ignoreras. För att förhindra duplicerade meddelanden måste avsändaren tagga varje meddelande med en unik identifierare. Båda kopiorna av meddelandet måste taggas med samma identifierare. Du kan använda egenskaperna ServiceBusMessage.MessageId eller ServiceBusMessage.Subject eller en anpassad egenskap för att tagga meddelandet. Mottagaren måste ha en lista över meddelanden som den redan har tagit emot.

Kommentar

Den aktiva replikeringsmetoden fördubblar antalet åtgärder, därför kan den här metoden leda till högre kostnader.

Passiv replikering

I det felfria fallet använder passiv replikering endast en av de två meddelandeentiteterna. En klient skickar meddelandet till den aktiva entiteten. Om åtgärden på den aktiva entiteten misslyckas med en felkod som anger att det datacenter som är värd för den aktiva entiteten kanske inte är tillgängligt, skickar klienten en kopia av meddelandet till entiteten för säkerhetskopiering. Då byter de aktiva entiteterna och säkerhetskopieringsentiteterna roller. Den sändande klienten anser att den gamla aktiva entiteten är den nya säkerhetskopieringsentiteten, och den gamla säkerhetskopieringsentiteten är den nya aktiva entiteten. Om båda sändningsåtgärderna misslyckas förblir rollerna för de två entiteterna oförändrade och ett fel returneras.

En klient tar emot meddelanden från båda köerna. Eftersom det finns en chans att mottagaren tar emot två kopior av samma meddelande måste mottagaren utelämna duplicerade meddelanden. Du kan utelämna dubbletter på samma sätt som beskrivs för aktiv replikering.

I allmänhet är passiv replikering mer ekonomisk än aktiv replikering eftersom det i de flesta fall bara utförs en åtgärd. Svarstid, dataflöde och monetär kostnad är identiska med det icke-replikerade scenariot.

När du använder passiv replikering kan meddelanden gå förlorade eller tas emot två gånger i följande scenarier:

  • Fördröjning eller förlust av meddelanden: Anta att avsändaren har skickat ett meddelande m1 till den primära kön och sedan blir kön otillgänglig innan mottagaren tar emot m1. Avsändaren skickar ett efterföljande meddelande m2 till den sekundära kön. Om den primära kön är tillfälligt otillgänglig tar mottagaren emot m1 när kön blir tillgänglig igen. När en katastrof inträffar kanske mottagaren aldrig får m1.
  • Duplicerad mottagning: Anta att avsändaren skickar ett meddelande m till den primära kön. Service Bus bearbetar m men kan inte skicka ett svar. Efter tidsgränsen för sändningsåtgärden skickar avsändaren en identisk kopia av m till den sekundära kön. Om mottagaren kan ta emot den första kopian av m innan den primära kön blir otillgänglig tar mottagaren emot båda kopiorna av m ungefär samtidigt. Om mottagaren inte kan ta emot den första kopian av m innan den primära kön blir otillgänglig tar mottagaren först bara emot den andra kopian av m, men får sedan en andra kopia av m när den primära kön blir tillgänglig.

Azure Messaging Replication Tasks med .NET Core-exemplet visar replikering av meddelanden mellan namnområden.

Nästa steg

Mer information om haveriberedskap finns i följande artiklar:

  • Last updated on