Meerdere naamruimten gebruiken om toepassingen te isoleren tegen Service Bus-storingen en -rampen

Bedrijfskritieke toepassingen moeten continu werken, zelfs in aanwezigheid van ongeplande storingen of rampen. Tolerantie tegen rampzalige uitval van resources voor gegevensverwerking is een vereiste voor veel ondernemingen en in sommige gevallen zelfs vereist door branchevoorschriften.

Notitie

Service Bus Geo-Disaster Recovery en Geo-Replication helpen u bij het herstellen van grootschalige rampen of permanent een mislukte Azure-regio te verlaten zonder dat er wijzigingen in uw toepassingsconfiguratie nodig zijn. Zie Betrouwbaarheid in Azure Service Bus voor meer informatie over deze functies en het inschakelen van betrouwbaarheid en tolerantie in Azure Service Bus.

Als u Geo-Disaster Recovery of Geo-Replication niet kunt gebruiken om aan uw vereisten te voldoen, kunt u meerdere Service Bus-naamruimten implementeren. In dit artikel worden technieken beschreven die u kunt gebruiken om toepassingen te beschermen tegen een mogelijke servicestoring of noodgeval met behulp van meerdere naamruimten.

Replicatietypen

Als u tolerantie wilt bereiken tegen noodgevallen met de Service Bus Standard-laag, kunt u actieve of passieve replicatie gebruiken. Als een wachtrij of onderwerp beschikbaar moet blijven tijdens een storing in een datacenter, maakt u dezelfde entiteit in beide naamruimten. De entiteiten kunnen dezelfde naam delen omdat ze bestaan in afzonderlijke naamruimten. U kunt bijvoorbeeld een primaire wachtrij onder contosoPrimary.servicebus.windows.net/myQueue bereiken, terwijl u de secundaire tegenhanger onder contosoSecondary.servicebus.windows.net/myQueue kunt bereiken.

Notitie

De actieve replicatie en passieve replicatie-installatie zijn algemene concepten en geen specifieke functies van Service Bus. De replicatielogica (verzenden naar 2 verschillende naamruimten) bevindt zich in de afzendertoepassingen en de ontvanger moet aangepaste logica hebben voor dubbele detectie.

Als de toepassing geen permanente communicatie van afzender naar ontvanger vereist, kan de toepassing een duurzame wachtrij aan de clientzijde implementeren om berichtenverlies te voorkomen en de afzender te beschermen tegen tijdelijke Service Bus-fouten.

Actieve replicatie

Actieve replicatie maakt gebruik van entiteiten in beide naamruimten voor elke bewerking. Elke client die een bericht verzendt, verzendt twee kopieën van hetzelfde bericht. De eerste kopie wordt verzonden naar de primaire entiteit (bijvoorbeeld contosoPrimary.servicebus.windows.net/sales) en de tweede kopie van het bericht wordt verzonden naar de secundaire entiteit (bijvoorbeeld contosoSecondary.servicebus.windows.net/sales).

Een client ontvangt berichten van beide wachtrijen. De ontvanger verwerkt de eerste kopie van een bericht en de tweede kopie wordt onderdrukt. Als u dubbele berichten wilt onderdrukken, moet de afzender elk bericht taggen met een unieke id. Beide kopieën van het bericht moeten worden gelabeld met dezelfde id. U kunt de eigenschappen ServiceBusMessage.MessageId of ServiceBusMessage.Subject of een aangepaste eigenschap gebruiken om het bericht te taggen. De ontvanger moet een lijst onderhouden met berichten die al zijn ontvangen.

Notitie

De actieve replicatiebenadering verdubbelt het aantal bewerkingen, waardoor deze benadering tot hogere kosten kan leiden.

Passieve replicatie

In het probleemloze geval gebruikt passieve replicatie slechts één van de twee berichtenentiteiten. Een client verzendt het bericht naar de actieve entiteit. Als de bewerking op de actieve entiteit mislukt met een foutcode die aangeeft dat het datacenter dat als host fungeert voor de actieve entiteit mogelijk niet beschikbaar is, verzendt de client een kopie van het bericht naar de back-upentiteit. Op dat moment schakelen de actieve en de back-upentiteiten tussen rollen. De verzendende client beschouwt de oude actieve entiteit als de nieuwe back-upentiteit en de oude back-upentiteit is de nieuwe actieve entiteit. Als beide verzendbewerkingen mislukken, blijven de rollen van de twee entiteiten ongewijzigd en wordt er een fout geretourneerd.

Een client ontvangt berichten van beide wachtrijen. Omdat er een kans is dat de ontvanger twee kopieën van hetzelfde bericht ontvangt, moet de ontvanger dubbele berichten onderdrukken. U kunt duplicaten op dezelfde manier onderdrukken als beschreven voor actieve replicatie.

In het algemeen is passieve replicatie voordeliger dan actieve replicatie, omdat in de meeste gevallen slechts één bewerking wordt uitgevoerd. Latentie, doorvoer en monetaire kosten zijn identiek aan het niet-gerepliceerde scenario.

Wanneer u passieve replicatie gebruikt, kunnen berichten in de volgende scenario's twee keer verloren gaan of ontvangen:

  • Berichtvertraging of -verlies: Stel dat de afzender een bericht m1 naar de primaire wachtrij heeft verzonden en de wachtrij vervolgens niet meer beschikbaar is voordat de ontvanger m1 ontvangt. De afzender verzendt een volgend bericht m2 naar de secundaire wachtrij. Als de primaire wachtrij tijdelijk niet beschikbaar is, ontvangt de ontvanger m1 nadat de wachtrij weer beschikbaar is. Wanneer zich een noodgeval voordoet, ontvangt de ontvanger mogelijk nooit m1.
  • Dubbele ontvangst: Stel dat de afzender een bericht naar de primaire wachtrij verzendt. Service Bus verwerkt m, maar kan geen antwoord verzenden. Nadat er een time-out optreedt voor de verzendbewerking, verzendt de afzender een identieke kopie van m naar de secundaire wachtrij. Als de ontvanger de eerste kopie van m kan ontvangen voordat de primaire wachtrij niet meer beschikbaar is, ontvangt de ontvanger beide exemplaren van m op ongeveer hetzelfde moment. Als de ontvanger de eerste kopie van m niet kan ontvangen voordat de primaire wachtrij niet meer beschikbaar is, ontvangt de ontvanger aanvankelijk alleen de tweede kopie van m, maar ontvangt vervolgens een tweede kopie van m wanneer de primaire wachtrij beschikbaar is.

De Azure Messaging-replicatietaken met het .NET Core-voorbeeld laat de replicatie van berichten tussen naamruimten zien.

Volgende stappen

Zie de volgende artikelen voor meer informatie over herstel na noodgevallen:

  • Laatst bijgewerkt om