Välja en meddelandebaserad leverans med köer

  • 8 minuter

Anta att du planerar arkitekturen för ditt musikdelningsprogram. Du vill se till att musikfilerna överförs till webb-API:n på ett tillförlitligt sätt från mobilappen. Sedan vill du leverera information om nya låtar direkt till appen när en artist lägger till ny musik i sin samling. Det här scenariot är en perfekt användning av ett meddelandebaserat system, och Azure erbjuder två lösningar på det här problemet:

  • Azure Queue Storage
  • Azure Service Bus

Vad är Azure Queue Storage?

Queue Storage är en tjänst som använder Azure Storage för att lagra stora mängder meddelanden som på ett säkert sätt kan nås från var som helst i världen med ett enkelt REST-baserat gränssnitt. Köer kan innehålla miljontals meddelanden; det begränsas bara av kapaciteten för det lagringskonto som äger det.

Vad är Azure Service Bus Queues?

Service Bus är ett meddelandekösystem som är avsett för företagsprogram. Dessa appar använder ofta flera kommunikationsprotokoll, har olika datakontrakt och högre säkerhetskrav och kan omfatta både molntjänster och lokala tjänster. Service Bus är byggt ovanpå en dedikerad meddelandeinfrastruktur som har utformats för just dessa scenarier.

Båda tjänsterna baseras på konceptet med en kö som kvarhåller skickade meddelanden tills målet är redo att ta emot dem.

Vad är Azure Service Bus-ämnen?

Azure Service Bus-ämnen liknar köer, men kan ha flera prenumeranter. När ett meddelande skickas till ett ämne i stället för en kö kan flera komponenter aktiveras för att utföra deras arbete. Anta att en användare lyssnar på en låt i ett musikdelningsprogram. Mobilappen kan skicka ett meddelande till ämnet ”Listened”. Detta ämne har en prenumeration för ”UpdateUserListenHistory” och en annan prenumeration för ”UpdateArtistsFanList”. Var och en av dessa funktioner hanteras av olika komponenter som tar emot en egen kopia av meddelandet.

Internt används köer för ämnen. När du publicerar på ett ämne kopieras meddelandet och släpps i kön för varje prenumeration. Kön innebär att meddelandekopian stannar kvar för att bearbetas av varje prenumerationsgren även om komponentbearbetningen av prenumerationen är för upptagen för att hålla jämna steg.

Fördelarna med köer

Köinfrastrukturer kan ha stöd för många avancerade funktioner som gör dem användbara på följande sätt:

Ökad tillförlitlighet

Köer används av distribuerade program som en tillfällig lagringsplats för meddelanden som väntar på leverans till en målkomponent. Källkomponenten kan lägga till ett meddelande till kön, och målkomponenter kan hämta meddelandet längst fram i kön för bearbetning. Köer ökar tillförlitligheten för meddelanden eftersom det vid hög efterfrågan kan innebära att meddelanden får vänta tills en målkomponent är redo att bearbeta dem.

Garantier för meddelandeleverans

Kösystem garanterar vanligtvis att alla meddelanden i kön levereras till en målkomponent. Dessa garantier kan dock fungera på olika sätt:

  • Leverans minst en gång: I den här metoden garanteras varje meddelande leverans till minst en av de komponenter som hämtar meddelanden från kön. Observera dock att det under vissa omständigheter är möjligt att samma meddelande kan levereras mer än en gång. Om det till exempel finns två instanser av en webbapp som hämtar meddelanden från en kö skickas vanligtvis varje meddelande till endast en av dessa instanser. Men om en instans tar lång tid att bearbeta meddelandet och tidsgränsen går ut kan meddelandet också skickas till den andra instansen. Koden i din webbapp bör utformas för att ta hänsyn till den här möjligheten.

  • Leverans högst en gång: I den här metoden är varje meddelande inte garanterat för leverans och det finns en liten chans att det inte kommer fram. Men till skillnad från leverans minst en gång finns det ingen chans att meddelandet levereras två gånger. Detta kallas ibland automatisk dubblettidentifiering.

  • First-In-First-Out (FIFO): I de flesta meddelandesystem lämnar meddelanden vanligtvis kön i samma ordning som de lades till, men du bör överväga om den här leveransen är garanterad. Om det distribuerade programmet kräver att meddelanden behandlas i exakt rätt ordning måste du välja ett kösystem med FIFO-garanti.

Transaktionsstöd

Vissa nära relaterade grupper av meddelanden kan orsaka problem när leveransen misslyckas för ett meddelande i gruppen.

Tänk dig exempelvis ett e-handelsprogram. När användaren väljer knappen Köp kan en serie meddelanden genereras och skickas till olika bearbetningsmål:

  • Ett meddelande med orderinformationen skickas till en expedieringscentral
  • Ett meddelande med totalsumman och betalningsinformationen skickas till en kreditkortsprocessor
  • Ett meddelande med kvittoinformationen skickas till en databas för att generera en faktura för kunden

I det här fallet vi vill vara säkra på att alla meddelanden bearbetas eller att inga av dem bearbetas. Vi kommer inte att vara i branschen länge om kreditkortsmeddelandet inte levereras och alla våra beställningar uppfylls utan betalning! Du kan undvika dessa typer av problem genom att gruppera de två meddelandena i en transaktion. Meddelandetransaktioner lyckas eller misslyckas som en enda enhet, precis som i databasvärlden. Om leveransen av kreditkortsinformationen misslyckas kommer även orderinformationen att göra det.

Vilken tjänst ska jag välja?

När du har förstått att kommunikationsstrategin för den här arkitekturen ska vara ett meddelande måste du välja om du vill använda Azure Storage-köer eller Azure Service Bus. Du kan använda båda teknikerna för att lagra och leverera meddelanden mellan dina komponenter. Var och en har en något annorlunda funktionsuppsättning, vilket innebär att du kan välja den ena eller den andra, eller använda båda, beroende på vilket problem du löser.

Använd Service Bus-köer om följande gäller:

  • Du behöver en garanti om leverans högst en gång.
  • Du behöver en FIFO-garanti.
  • Du behöver gruppera meddelanden i transaktioner.
  • Du vill ta emot meddelanden utan att avsöka kön.
  • Du behöver ange en modell för rollbaserad åtkomst till köerna.
  • Behöver hantera meddelanden som är större än 64 KB men mindre än 100 MB. Den maximala meddelandestorleken som stöds av standardnivån är 256 KB och premiumnivån är 100 MB.
  • Köstorleken blir inte större än 1 TB. Den maximala köstorleken för standardnivån är 80 GB och för premiumnivån är den 1 TB.
  • Du vill publicera och använda batchar av meddelanden.

Använd Service Bus-ämnen om följande gäller:

  • Behöver alla funktioner som tillhandahålls av Service Bus-köer och implementera dessutom ett pub-sub-mönster där meddelanden kan dirigeras till en av flera prenumerationer, var och en med sina egna oberoende mottagare

Kölagring har inte riktigt lika många funktioner, men om du inte behöver några av de funktionerna kan det vara ett enklare val. Dessutom är det den bästa lösningen om din app har något av följande krav.

Använd kölagring om följande gäller:

  • Du behöver en spårningslogg för alla meddelanden som skickas via kön.
  • Förvänta dig att kön överskrider 1 TB i storlek.
  • Du vill följa förloppet för bearbetning av ett meddelande i kön.

En kö är en enkel, tillfällig lagringsplats för meddelanden som skickas mellan komponenterna i ett distribuerat program. Använd en kö till att ordna meddelanden och smidigt hantera oväntade toppar i efterfrågan.

Använd Storage-köer om du vill ha ett enkelt kösystem som är lätt att koda. Använd Service Bus-köer för mer avancerade behov. Om du har flera mål för ett enskilt meddelande, men behöver köliknande beteende, kan du använda Service Bus-ämnen.