Storage Queues and Service Bus Queues - Compared and Contrasted (Storage-wachtrijen en Service Bus-wachtrijen: overeenkomsten en verschillen)

In dit artikel worden de verschillen en overeenkomsten geanalyseerd tussen de twee typen wachtrijen die door Microsoft Azure worden aangeboden: Storage wachtrijen en Service Bus wachtrijen. Aan de hand van deze informatie kunt u een beter geïnformeerde beslissing nemen over welke oplossing het beste voldoet aan uw behoeften.

Introductie

Azure ondersteunt twee soorten wachtrijmechanismen: Storage wachtrijen en Service Bus wachtrijen.

Storage wachtrijen maken deel uit van de Azure Storage infrastructuur. Ze bieden u de mogelijkheid om grote aantallen berichten op te slaan. U hebt overal ter wereld toegang tot berichten via geverifieerde oproepen met HTTP of HTTPS. Een wachtrijbericht kan maximaal 64 KB groot zijn. Een wachtrij kan miljoenen berichten bevatten, tot aan de totale capaciteitslimiet van een opslagaccount. Wachtrijen worden vaak gebruikt om een voorraad werk te maken dat asynchroon moet worden verwerkt. Zie What are Azure Storage queues (Wat Azure Storage wachtrijen) voor meer informatie.

Service Bus wachtrijen maken deel uit van een bredere Azure-berichteninfrastructuur die ondersteuning biedt voor wachtrijen, publiceren/abonneren en geavanceerdere integratiepatronen. Ze zijn ontworpen om toepassingen of toepassingsonderdelen te integreren die meerdere communicatieprotocollen, gegevenscontracten, vertrouwensdomeinen of netwerkomgevingen kunnen bevatten. Zie Service Bus wachtrijen, onderwerpen en abonnementen voor meer informatie over Service Bus wachtrijen, onderwerpen en abonnementen.

Overwegingen bij het selecteren van technologie

Storage wachtrijen en Service Bus hebben een iets andere functieset. U kunt een of beide kiezen, afhankelijk van de behoeften van uw specifieke oplossing.

Bij het bepalen welke wachtrijtechnologie past bij het doel van een bepaalde oplossing, moeten oplossingsarchitecten en ontwikkelaars rekening houden met deze aanbevelingen.

Overweeg het gebruik Storage wachtrijen

Als oplossingsarchitect/-ontwikkelaar moet u overwegen om Storage wachtrijen te gebruiken wanneer:

• Uw toepassing moet meer dan 80 gigabyte aan berichten in een wachtrij opslaan.
• Uw toepassing wil de voortgang voor het verwerken van een bericht in de wachtrij bijhouden. Dit is handig als de werkmedewerker die een bericht verwerkt, vast loopt. Een andere werker kan die informatie vervolgens gebruiken om door te gaan vanaf de plek waar de eerdere werkmedewerker was gebleven.
• U hebt logboeken aan de serverzijde nodig van alle transacties die worden uitgevoerd voor uw wachtrijen.

Overweeg het gebruik Service Bus wachtrijen

Als oplossingsarchitect/-ontwikkelaar moet u overwegen om Service Bus wachtrijen te gebruiken wanneer:

• Uw oplossing moet berichten ontvangen zonder de wachtrij te hoeven peilen. Met Service Bus kunt u dit bereiken met behulp van een bewerking voor het ontvangen van lange polling met behulp van de TCP-protocollen die Service Bus ondersteunt.
• Uw oplossing vereist dat de wachtrij een gegarandeerde fifo-levering (first-in-first-out) biedt.
• Uw oplossing moet automatische duplicaatdetectie ondersteunen.
• U wilt dat uw toepassing berichten verwerkt als parallelle, langlopende streams (berichten worden gekoppeld aan een stroom met behulp van de sessie-id-eigenschap in het bericht). In dit model concurreert elk knooppunt in de verbruikende toepassing om stromen, in plaats van berichten. Wanneer een stroom wordt gegeven aan een verbruikt knooppunt, kan het knooppunt de status van de toepassingsstroom onderzoeken met behulp van transacties.
• Uw oplossing vereist transactioneel gedrag en atomiciteit bij het verzenden of ontvangen van meerdere berichten uit een wachtrij.
• Uw toepassing verwerkt berichten die de 64 kB kunnen overschrijden, maar die waarschijnlijk niet de limiet van 256 kB overschrijden.
• U moet een op rollen gebaseerd toegangsmodel voor de wachtrijen en verschillende rechten/machtigingen voor afzenders en ontvangers bieden. Raadpleeg voor meer informatie de volgende artikelen:
  • Verifiëren met beheerde identiteiten
  • Verifiëren vanuit een toepassing
• Uw wachtrijgrootte wordt niet groter dan 80 GB.
• U wilt het op standaarden gebaseerde AMQP 1.0-berichtenprotocol gebruiken. Zie amqp-overzicht voor Service Bus amqp voor meer informatie over AMQP.
• U ziet een uiteindelijke migratie van op wachtrij gebaseerde punt-naar-punt-communicatie naar een publicatie-/abonnementsberichtenpatroon. Dit patroon maakt integratie van extra ontvangers (abonnees) mogelijk. Elke ontvanger ontvangt onafhankelijke kopieën van sommige of alle berichten die naar de wachtrij worden verzonden.
• Uw berichtenoplossing moet de 'At-Most-Once'-leveringsgarantie ondersteunen zonder dat u de aanvullende infrastructuuronderdelen hoeft te bouwen.
• Uw oplossing moet batches berichten publiceren en gebruiken.

De Storage en Service Bus vergelijken

De tabellen in de volgende secties bieden een logische groepering van wachtrijfuncties. Met deze functies kunt u in één oogopslag de mogelijkheden vergelijken die beschikbaar zijn in Azure Storage wachtrijen en Service Bus wachtrijen.

Basismogelijkheden

In deze sectie worden enkele van de fundamentele wachtrijmogelijkheden van Storage wachtrijen en Service Bus vergeleken.

Aanvullende informatie

• Berichten in Storage wachtrijen zijn doorgaans first-in-first-out, maar soms kunnen ze niet in de orde zijn. Bijvoorbeeld wanneer de duur van de time-out voor zichtbaarheid van een bericht verloopt omdat een clienttoepassing is vastgelopen tijdens het verwerken van een bericht. Wanneer de time-out voor zichtbaarheid is verlopen, wordt het bericht weer zichtbaar in de wachtrij, voor een andere werkrol om het uit de wachtrij te laten in de wachtrij. Op dat moment kan het nieuw zichtbare bericht in de wachtrij worden geplaatst om opnieuw uit de wachtrij te worden verwijderd.
• Het gegarandeerde FIFO-patroon in Service Bus wachtrijen vereist het gebruik van berichtensessies. Als de toepassing vastgelopen is tijdens het verwerken van een bericht dat is ontvangen in de modus Peek & Lock, wordt de volgende keer dat een wachtrijontvanger een berichtensessie accepteert, het bericht met de foutmelding weergegeven nadat de time-to-live-periode (TTL) van het bericht is verlopen.
• Storage wachtrijen zijn ontworpen ter ondersteuning van standaardwachtrijscenario's, zoals de volgende:
  • Toepassingsonderdelen loskoppelen om de schaalbaarheid en tolerantie voor fouten te verhogen
  • Load leveling
  • Proceswerkstromen bouwen.
• Inconsistenties met betrekking tot de verwerking van berichten in de context van Service Bus-sessies kunnen worden vermeden door de sessietoestand te gebruiken voor het opslaan van de status van de toepassing ten opzichte van de voortgang van de verwerking van de berichtenreeks van de sessie, en door transacties te gebruiken voor het afhandelen van ontvangen berichten en het bijwerken van de sessietoestand. Dit type consistentiefunctie wordt soms exact eenmaal verwerkt in producten van andere leveranciers. Eventuele transactiefouten zorgen er uiteraard voor dat berichten opnieuw wordenlived en daarom is de term niet precies voldoende.
• Storage wachtrijen bieden een uniform en consistent programmeermodel voor wachtrijen, tabellen en BLOBs, zowel voor ontwikkelaars als voor operationele teams.
• Service Bus wachtrijen bieden ondersteuning voor lokale transacties in de context van één wachtrij.
• De receive- en delete-modus die wordt ondersteund door Service Bus biedt de mogelijkheid om het aantal berichtenbewerkingen (en de bijbehorende kosten) te verminderen in uitwisseling voor een lagere leveringsgarantie.
• Storage bieden leases met de mogelijkheid om de leases voor berichten uit te breiden. Met deze functie kunnen werkprocessen korte leases voor berichten onderhouden. Dus als een werkmedewerker vast loopt, kan het bericht snel opnieuw worden verwerkt door een andere werker. Een werkmedewerker kan ook de lease voor een bericht verlengen als deze langer moet worden verwerkt dan de huidige leasetijd.
• Storage wachtrijen bieden een time-out voor zichtbaarheid die u kunt instellen bij het enqueuing of het uit de wachtrij nemen van een bericht. U kunt ook een bericht bijwerken met verschillende leasewaarden tijdens run-time en verschillende waarden bijwerken voor berichten in dezelfde wachtrij. Service Bus vergrendelings-time-outs worden gedefinieerd in de metagegevens van de wachtrij. U kunt de berichtvergrendeling echter handmatig vernieuwen voor de vooraf gedefinieerde vergrendelingsduur of de functie voor automatisch verlengen van vergrendeling gebruiken, waarbij de client de verlenging van vergrendelingen voor u beheert.
• De maximale time-out voor een blokkerende ontvangstbewerking in Service Bus wachtrijen is 24 dagen. Time-outs op basis van REST hebben echter een maximale waarde van 55 seconden.
• Batching aan de clientzijde die wordt geleverd door Service Bus een wachtrijclient in staat om meerdere berichten in één verzendbewerking te batchen. Batchbewerkingen zijn alleen beschikbaar voor asynchrone verzendbewerkingen.
• Functies zoals het maximum van 200 TB aan Storage wachtrijen (meer wanneer u accounts virtualiseert) en onbeperkte wachtrijen maken het een ideaal platform voor SaaS-providers.
• Storage wachtrijen bieden een flexibel en goed presterend mechanisme voor gedelegeerd toegangsbeheer.

Geavanceerde mogelijkheden

In deze sectie worden geavanceerde mogelijkheden van Storage wachtrijen en Service Bus vergeleken.

Aanvullende informatie

• Met beide technologieën voor wachtrijen kan een bericht op een later tijdstip worden gepland voor levering.
• Door de wachtrij automatisch door te sturen, kunnen duizenden wachtrijen hun berichten automatisch naar één wachtrij sturen, van waaruit de ontvangende toepassing het bericht verbruikt. U kunt dit mechanisme gebruiken om beveiliging, controlestroom en isolatie van opslag tussen elke berichtuitgever te realiseren.
• Storage wachtrijen bieden ondersteuning voor het bijwerken van berichtinhoud. U kunt deze functionaliteit gebruiken voor het persistent maken van statusinformatie en incrementele voortgangsupdates in het bericht, zodat deze kunnen worden verwerkt vanaf het laatst bekende controlepunt, in plaats van vanaf het begin. Met Service Bus wachtrijen kunt u hetzelfde scenario inschakelen met behulp van berichtsessies. Zie Berichtsessietoestand voor meer informatie.
• Service Bus wachtrijen bieden ondersteuning voor dead lettering. Dit kan handig zijn voor het isoleren van berichten die voldoen aan de volgende criteria:
  • Berichten kunnen niet worden verwerkt door de ontvangende toepassing
  • Berichten kunnen hun doel niet bereiken vanwege een verlopen TTL-eigenschap (time-to-live). De TTL-waarde geeft aan hoelang een bericht in de wachtrij blijft. Met Service Bus wordt het bericht verplaatst naar een speciale wachtrij met de $DeadLetterQueue wanneer de TTL-periode is verlopen.
• Als u 'vertreinigde' berichten in Storage wachtrijen wilt vinden, onderzoekt de toepassing bij het uit de wachtrij verwijderen van een bericht de eigenschap DequeueCount van het bericht. Als DequeueCount groter is dan een bepaalde drempelwaarde, verplaatst de toepassing het bericht naar een door de toepassing gedefinieerde wachtrij voor 'dead letter'.
• Storage wachtrijen kunt u een gedetailleerd logboek van alle transacties die worden uitgevoerd op de wachtrij en geaggregeerde metrische gegevens verkrijgen. Beide opties zijn handig voor het debuggen en begrijpen hoe uw toepassing gebruikmaakt van Storage wachtrijen. Ze zijn ook handig voor het afstemmen van de prestaties van uw toepassing en het verlagen van de kosten voor het gebruik van wachtrijen.
• Berichtsessies die worden ondersteund door Service Bus inschakelen dat berichten die deel uitmaken van een logische groep aan een ontvanger worden gekoppeld. Er wordt een sessie-achtige affiniteit tussen berichten en hun respectieve ontvangers gemaakt. U kunt deze geavanceerde functionaliteit inschakelen in Service Bus door de sessie-id-eigenschap voor een bericht in te stellen. Ontvangers kunnen vervolgens luisteren naar een specifieke sessie-id en berichten ontvangen die de opgegeven sessie-id delen.
• De functie duplicatiedetectie van Service Bus wachtrijen verwijdert automatisch dubbele berichten die naar een wachtrij of onderwerp worden verzonden, op basis van de waarde van de eigenschap bericht-id.

Capaciteit en quota

In deze sectie worden Storage wachtrijen en Service Bus vergeleken vanuit het perspectief van capaciteit en quota die van toepassing kunnen zijn.

Aanvullende informatie

• Service Bus dwingt limieten voor de wachtrijgrootte af. De maximale wachtrijgrootte wordt opgegeven bij het maken van een wachtrij. Deze kan tussen 1 GB en 80 GB zijn. Als de grootte van de wachtrij deze limiet bereikt, worden extra binnenkomende berichten geweigerd en ontvangt de aanroeper een uitzondering. Zie Quota voor meer informatie Service Bus quota in Service Bus quota.
• Partitionering wordt niet ondersteund in de Premium laag. In de standard messaging-laag kunt u Service Bus wachtrijen en onderwerpen in 1 (standaard), 2, 3, 4 of 5 GB grootten maken. Als partitioneren is ingeschakeld, maakt Service Bus 16 kopieën (16 partities) van de entiteit, elk van dezelfde opgegeven grootte. Als u een wachtrij van 5 GB maakt, wordt met 16 partities de maximale wachtrijgrootte (5 * 16) = 80 GB. U kunt de maximale grootte van uw gepart partitioneerde wachtrij of onderwerp bekijken in Azure Portal.
• Met Storage wachtrijen moet de inhoud van het bericht base64-gecodeerd zijn als de inhoud van het bericht niet XML-veilig is. Als u het bericht base64-codeert, kan de nettolading van de gebruiker maximaal 48 kB zijn in plaats van 64 kB.
• Bij Service Bus wachtrijen bestaat elk bericht dat in een wachtrij is opgeslagen uit twee delen: een koptekst en een hoofdtekst. De totale grootte van het bericht mag niet groter zijn dan de maximale berichtgrootte die wordt ondersteund door de servicelaag.
• Wanneer clients communiceren met Service Bus wachtrijen via het TCP-protocol, is het maximum aantal gelijktijdige verbindingen met één Service Bus-wachtrij beperkt tot 100. Dit nummer wordt gedeeld tussen afzenders en ontvangers. Als dit quotum is bereikt, worden aanvragen voor extra verbindingen geweigerd en wordt er een uitzondering ontvangen door de aanroepcode. Deze limiet wordt niet opgelegd aan clients die verbinding maken met de wachtrijen met behulp van een OP REST gebaseerde API.
• Als u meer dan 10.000 wachtrijen in één Service Bus-naamruimte nodig hebt, kunt u contact opnemen met het ondersteuning voor Azure-team en een verhoging aanvragen. Als u meer dan 10.000 wachtrijen wilt schalen met Service Bus, kunt u ook extra naamruimten maken met behulp van Azure Portal.

Beheer en bewerkingen

In deze sectie worden de beheerfuncties van Storage wachtrijen en Service Bus vergeleken.

Aanvullende informatie

• Storage wachtrijen bieden ondersteuning voor willekeurige kenmerken die kunnen worden toegepast op de beschrijving van de wachtrij, in de vorm van naam/waarde-paren.
• Beide wachtrijtechnologieën bieden de mogelijkheid om een bericht te bekijken zonder het te hoeven vergrendelen. Dit kan handig zijn bij het implementeren van een queue explorer-/browserhulpprogramma.
• De Service Bus .NET Brokered Messaging-API's maken gebruik van full-duplex TCP-verbindingen voor verbeterde prestaties in vergelijking met REST via HTTP en ondersteunen het standaardprotocol AMQP 1.0.
• Namen van Storage wachtrijen mogen 3 tot 63 tekens lang zijn en mogen kleine letters, cijfers en afbreekstreelopen bevatten. Zie Naming Queues and Metadata (Wachtrijen en metagegevens een naam geven) voor meer informatie.
• Service Bus wachtrijnamen kunnen maximaal 260 tekens lang zijn en minder beperkende naamgevingsregels hebben. Service Bus kunnen letters, cijfers, punten, afbreekstreepingen en onderstrepingstekens bevatten.

Verificatie en autorisatie

In deze sectie worden de verificatie- en autorisatiefuncties besproken die worden ondersteund door Storage wachtrijen en Service Bus wachtrijen.

Aanvullende informatie

• Elke aanvraag voor een van de wachtrijtechnologieën moet worden geverifieerd. Openbare wachtrijen met anonieme toegang worden niet ondersteund. Met SASkunt u dit scenario aanpakken door een alleen-schrijven SAS, alleen-lezen SAS of zelfs een SAS met volledige toegang te publiceren.
• Het verificatieschema dat wordt geleverd Storage wachtrijen omvat het gebruik van een symmetrische sleutel. Deze sleutel is een hash-Message Authentication Code (HMAC), berekend met het SHA-256-algoritme en gecodeerd als een Base64-tekenreeks. Zie Verificatie voor de Azure Storage Services voor meer informatie over Azure Storage protocol. Service Bus wachtrijen ondersteunen een vergelijkbaar model met behulp van symmetrische sleutels. Zie Verificatie met Shared Access Signature voor meer Service Bus.

Conclusie

Door meer inzicht te krijgen in de twee technologieën, kunt u een beter geïnformeerde beslissing nemen over welke wachtrijtechnologie u wilt gebruiken en wanneer. De beslissing over het gebruik van Storage of Service Bus wachtrijen is duidelijk afhankelijk van veel factoren. Deze factoren zijn mogelijk sterk afhankelijk van de afzonderlijke behoeften van uw toepassing en de architectuur ervan.

U kunt de Storage kiezen om redenen zoals de volgende:

• Als uw toepassing al gebruikmaakt van de belangrijkste mogelijkheden van Microsoft Azure
• Als u basiscommunicatie en berichten tussen services nodig hebt
• Wachtrijen nodig die groter kunnen zijn dan 80 GB

Service Bus wachtrijen bieden veel geavanceerde functies, zoals de volgende. Ze kunnen dus een voorkeurskeuze zijn als u een hybride toepassing bouwt of als uw toepassing anders deze functies vereist.

• Sessies
• Transacties
• Detectie van duplicaten
• Automatische dead-lettering
• Mogelijkheden voor duurzaam publiceren en abonneren

Volgende stappen

De volgende artikelen bevatten meer richtlijnen en informatie over het gebruik Storage wachtrijen of Service Bus wachtrijen.

• Aan de slag met Service Bus-wachtrijen
• De Queue Storage Service gebruiken
• Best practices voor prestatieverbeteringen met behulp Service Bus brokered messaging