Välj en meddelandebaserad leverans med köer

  • 8 minuter

Anta att du planerar arkitekturen för ditt musikdelningsprogram. Du vill se till att musikfiler laddas upp till webb-API:et 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 ett stort antal meddelanden som kan nås på ett säkert sätt var som helst i världen med hjälp av ett enkelt REST-baserat gränssnitt. Köer kan innehålla miljontals meddelanden, som endast begränsas av kapaciteten för det lagringskonto som äger det.

Vad är Azure Service Bus-köer?

Service Bus är ett meddelandeförmedlarsystem som är avsett för företagsapplikationer. 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 bygger på en dedikerad meddelandeinfrastruktur som är utformad för exakt dessa scenarier.

Båda dessa tjänster är baserade på idén om en kö, som innehåller skickade meddelanden tills målet är redo att ta emot dem.

Vad är Azure Service Bus-ämnen?

Azure Service Bus-ämnen är som 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 utlösas för att utföra sitt arbete. Anta att en användare lyssnar på en låt i ett musikdelningsprogram. Mobilappen kan skicka ett meddelande till ett ämne Listened. Det ämnet har en prenumeration för UpdateUserListenHistory och en annan prenumeration för UpdateArtistsFanList. Var och en av dessa funktioner hanteras av en annan komponent som tar emot en egen kopia av meddelandet.

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

Fördelar 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 i kön och målkomponenterna kan hämta meddelandet längst fram i kön för bearbetning. Köer ökar tillförlitligheten för meddelandeutbytet eftersom meddelanden vid tider med hög efterfrågan kan vänta tills en målkomponent är redo att bearbeta dem.

Garantier för meddelandeleverans

Kösystem garanterar vanligtvis leverans av varje meddelande i kön till en målkomponent. Dessa garantier kan dock ha olika metoder:

  • At-Least-Once Delivery: I den här metoden garanteras att varje meddelande levereras 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 levereras mer än en gång. Om det till exempel finns två instanser av en webbapp som hämtar meddelanden från en kö går vanligtvis varje meddelande bara till 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. Din webbappskod bör utformas med den här möjligheten i åtanke.

  • At-Most-Once Delivery: 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 At-Least-Once leverans 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 bearbetas i exakt rätt ordning måste du välja ett kösystem som innehåller en FIFO-garanti.

Transaktionsstöd

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

Överväg till exempel 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 orderdetaljerna skickas till ett fullgörandecenter
  • 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 vill vi se till att alla meddelanden bearbetas eller att ingen av dem bearbetas. Vi kommer inte att vara verksamma länge om kreditkortsmeddelandet inte levereras och alla våra beställningar uppfylls utan betalning. Du kan undvika den här typen 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 meddelandeleveransen av kreditkortsinformation misslyckas kommer även orderinformationsmeddelandet att visas.

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 du:

  • Behöver en leveransgaranti för at-Most-Once.
  • Behöver en FIFO-garanti.
  • Du måste gruppera meddelanden i transaktioner.
  • Önskar ta emot meddelanden utan att söka igenom kön.
  • Behöver tillhandahålla en rollbaserad åtkomstmodell 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.
  • Vill publicera och bearbeta grupper av meddelanden.

Använd Service Bus-ämnen om du:

  • 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 är inte riktigt lika funktionsrikt, men om du inte behöver någon av dessa funktioner 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 Queue Storage om du:

  • Behöver en spårningslogg för alla meddelanden som passerar genom kön.
  • Förvänta dig att kön överskrider 1 TB i storlek.
  • Vill spåra 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ö för att organisera meddelanden och hantera oförutsägbara ökningar av efterfrågan på ett korrekt sätt.

Använd Lagringsköer när du vill ha ett enkelt och lätt att koda kösystem. Använd Service Bus-köer för mer avancerade behov. Om du har flera mål för ett enda meddelande, men behöver köliknande beteende, använder du Service Bus-ämnen.