Redis Stream – en ny abstrakt datatyp som introducerades i Redis med version 5.0
Konceptuellt är Redis Stream en lista där du kan lägga till poster. Varje post har ett unikt identifierare. Som standard genereras identifieraren automatiskt och inkluderar en tidsstämpel. Därför kan du begära intervall av poster baserat på tid eller få nya data i realtid när de kommer in i strömmen, likt Unix-kommandot "tail -f" som läser en loggfil och stannar upp i väntan på nya data. Tänk på att flera klienter kan lyssna på strömmen samtidigt, precis som många "tail -f" processer kan läsa en fil utan att kollidera med varandra.

För att förstå alla fördelar med den nya datatypen, låt oss snabbt påminna oss om de äldre Redis-strukturer som delvis återger funktionaliteten hos Redis Stream.

Redis PUB/SUB

Redis Pub/Sub – ett enkelt meddelandesystem, redan inbyggt i ditt key-value lagringssystem. Men enkelheten har sina nackdelar:

Om en utgivare av någon anledning går ner förlorar de alla sina prenumeranter
Utgivaren måste känna till den exakta adressen till alla sina prenumeranter
Utgivaren kan överbelasta sina prenumeranter om data publiceras snabbare än de kan bearbeta
Meddelandet tas bort från utgivarens buffert omedelbart efter publicering, oavsett hur många prenumeranter det har levererats till och hur snabbt de lyckas bearbeta meddelandet.
Alla prenumeranter får meddelandet samtidigt. Prenumeranterna måste själva samordna ordningen för bearbetningen av samma meddelande.
Det finns ingen inbyggd mekanism för att bekräfta att prenumeranten har bearbetat meddelandet framgångsrikt. Om prenumeranten tar emot meddelandet och kraschar under bearbetningen, kommer utgivaren inte att veta något om det.

Redis List

Redis List – en datatyp som stödjer blockerande läsorder. Du kan lägga till och läsa meddelanden från början eller slutet av listan. Baserat på denna struktur kan man skapa en ganska bra stack eller kö för ditt distribuerade system, vilket i de flesta fall kommer att vara tillräckligt. De huvudsakliga skillnaderna från Redis Pub/Sub är:

Meddelandet levereras till en enda klient. Den första blockerade läsande klienten får data först.
Clint måste själv initiera läsoperationen för varje meddelande. List vet ingenting om kunder.
Meddelanden lagras tills någon läser dem eller raderar dem explicit. Om du har konfigurerat Redis-servern att spara data på disk ökar systemets tillförlitlighet kraftigt.

Introduktion till Stream

Lägga till en post i strömmen

Team XADD lägger till en ny post i strömmen. En post är inte bara en rad, utan består av en eller flera nyckel-värde-par. Således är varje post redan strukturerad och påminner om strukturen av en CSV-fil.

> XADD mystream * sensor-id 1234 temperature 19.8
1518951480106-0

I exemplet ovan lägger vi till i strömmen med namnet (nyckeln) "mystream" två fält: "sensor-id" och "temperature" med värdena "1234" och "19.8" respektive. Som andra argument tar kommandot en identifierare som kommer att tilldelas posten - denna identifierare identifierar entydigt varje post i strömmen. I det här fallet skickade vi *, eftersom vi vill att Redis ska generera en ny identifierare för oss. Varje ny identifierare kommer att vara högre. Därför kommer varje ny post att ha en större identifierare i förhållande till de tidigare posterna.

Format för identifierare

Identifieraren för posten som returneras av kommandot XADD, består av två delar:

{millisecondsTime}-{sequenceNumber}
millisecondsTime — Unix-tid i millisekunder (tid servern Redis). Men om den aktuella tiden visar sig vara densamma eller mindre än tiden för den föregående posten, används tidsstämplingen för den föregående posten. Därför, om serverns tid går bakåt, kommer den nya identifieraren fortfarande att behålla sin egenskap av att öka.

sequenceNumber används för poster som skapades vid samma millisekund. sequenceNumber kommer att ökas med 1 i förhållande till den föregående posten. Eftersom sequenceNumber har en storlek på 64 bitar, så bör du i praktiken inte stöta på begränsningen av antalet poster som kan genereras under en millisekund.

Formatet på dessa identifierare kan vid första anblicken verka konstigt. En skeptisk läsare kan undra varför tid är en del av identifieraren. Anledningen är att Redis-strömmar stödjer förfrågningar med intervall baserat på identifierare. Eftersom identifieraren är kopplad till tidpunkten för postens skapande, ger det möjlighet att begära tidsintervall. Vi kommer att gå igenom ett konkret exempel när vi studerar kommandot. XRANGE.

Om användaren av någon anledning behöver ange sin egen identifierare, som exempelvis är kopplad till något externt system, kan vi överföra den till kommandot XADD istället för prick (*) som visas nedan:

> XADD somestream 0-1 field value
0-1
> XADD somestream 0-2 foo bar
0-2

Observera att du i detta fall måste hålla koll på att identifieraren ökar. I vårt exempel är den minimi identifieraren "0-1", så kommandot kommer inte att acceptera ytterligare en identifierare som är lika med eller mindre än "0-1".

> XADD somestream 0-1 foo bar
(error) ERR ID:n som anges i XADD är lika med eller mindre än toppelementet i målströmmen

Antal poster i strömmen

Du kan få antalet poster i strömmen genom att helt enkelt använda kommandot XLEN. För vårt exempel kommer detta kommando att returnera följande värde:

> XLEN somestream
(integer) 2

Förfrågningar med intervall — XRANGE och XREVRANGE

För att begära data över ett intervall måste vi ange två identifierare — början och slutet av intervallet. Det returnerade intervallet kommer att inkludera alla element, inklusive gränser. Det finns också två specialidentifierare "-" och "+", som respektive betyder den minsta (första posten) och den största (senaste posten) identifieraren i strömmen. Exemplet nedan kommer att visa alla poster i strömmen.

> XRANGE mystream - +
1) 1) 1518951480106-0
   2) 1) "sensor-id"
      2) "1234"
      3) "temperature"
      4) "19.8"
2) 1) 1518951482479-0
   2) 1) "sensor-id"
      2) "9999"
      3) "temperature"
      4) "18.2"

Varje returnerad posten representerar en array med två element: identifierare och en lista av nyckel-värde-par. Vi har redan nämnt att identifierarna för poster är relaterade till tid. Således kan vi begära ett intervall för en specifik tidsperiod. Dock kan vi ange ett ofullständigt identifierare i begäran, genom att utelämna delen som rör sequenceNumber. Den utelämnade delen av identifieraren antas automatiskt vara noll i början av intervallet och det maximala värdet i slutet av intervallet. Här är ett exempel på hur man kan begära ett intervall som är två millisekunder.

> XRANGE mystream 1518951480106 1518951480107
1) 1) 1518951480106-0
   2) 1) "sensor-id"
      2) "1234"
      3) "temperatur"
      4) "19.8"

Vi har bara en post i det här intervallet, men i verkliga datamängder kan det returnerade resultatet vara enormt. Av den anledningen XRANGE stöder COUNT-alternativet. Genom att ange ett antal kan vi helt enkelt få de första N posterna. Om vi behöver hämta de nästa N posterna (sidhänvisning), kan vi använda den senaste hämtade identifieraren, öka den sequenceNumber med ett och begära igen. Låt oss se på detta i nästa exempel. Vi börjar lägga till 10 element med hjälp av XADD (låt oss anta att strömmen mystream redan har fyllts med 10 element). För att starta iterationen och hämta 2 element per kommando, börjar vi med det fullständiga intervallet, men med COUNT satt till 2.

> XRANGE mystream - + COUNT 2
1) 1) 1519073278252-0
   2) 1) "foo"
      2) "value_1"
2) 1) 1519073279157-0
   2) 1) "foo"
      2) "value_2"

För att fortsätta iterationen med de nästa två elementen måste vi välja den senaste hämtade identifieraren, det vill säga 1519073279157-0, och lägga till 1 till sequenceNumber.
den resulterande identifieraren, i detta fall 1519073279157-1, som nu kan användas som ett nytt startargument för nästa anrop XRANGE:

> XRANGE mystream 1519073279157-1 + COUNT 2
1) 1) 1519073280281-0
   2) 1) "foo"
      2) "value_3"
2) 1) 1519073281432-0
   2) 1) "foo"
      2) "value_4"

Och så vidare. Eftersom komplexiteten XRANGE är O(log (N)) för att söka, och sedan O(M) för att returnera M element, är varje steg i iterationen snabbt. På så sätt kan man XRANGE effektivt iterera över strömmar.

Team XREVRANGE är ekvivalent med XRANGE, men returnerar elementen i omvänd ordning:

> XREVRANGE mystream + - COUNT 1
1) 1) 1519073287312-0
   2) 1) "foo"
      2) "value_10"

Observera att kommandot XREVRANGE tar start- och stoppargument i omvänd ordning.

Att läsa nya poster med hjälp av XREAD

kan ofta innebära att man prenumererar på en ström och bara får nya meddelanden. Detta koncept kan verka liknande Redis Pub/Sub eller blockerande Redis List, men det finns grundläggande skillnader i hur Redis Stream används:

Varje nytt meddelande levereras som standard till varje prenumerant. Detta beteende skiljer sig från en blockerande Redis-lista, där ett nytt meddelande endast läses av en viss prenumerant.
Medan i Redis Pub/Sub glöms alla meddelanden bort och sparas aldrig, sparas alla meddelanden i Stream under obestämd tid (om klienten inte uttryckligen begär borttagning).
Redis Stream möjliggör att begränsa åtkomsten till meddelanden inom en och samma ström. En specifik prenumerant kan endast se sin personliga meddelandehistorik.

Du kan prenumerera på strömmen och ta emot nya meddelanden med kommandot XREAD. Detta är något mer komplicerat än XRANGE, så vi börjar med enklare exempel först.

> XREAD COUNT 2 STREAMS mystream 0
1) 1) "mystream"
   2) 1) 1) 1519073278252-0
         2) 1) "foo"
            2) "value_1"
      2) 1) 1519073279157-0
         2) 1) "foo"
            2) "value_2"

I exemplet ovan anges den icke-blockerande formen XREAD. Observera att alternativet COUNT inte är obligatoriskt. Den enda obligatoriska parametern för kommandot är alternativet STREAMS som anger listan över strömmar tillsammans med motsvarande maximala identifierare. Vi skrev "STREAMS mystream 0" — vi vill ta emot alla poster från strömmen mystream med en identifierare större än "0-0". Som framgår av exemplet returnerar kommandot namnet på strömmen, eftersom vi kan prenumerera på flera strömmar samtidigt. Vi skulle kunna skriva till exempel "STREAMS mystream otherstream 0 0". Observera att vi efter alternativet STREAMS först behöver ange namnen på alla behövliga strömmar och sedan listan över identifierare.

I denna enkla form gör kommandot inget särskilt jämfört med XRANGE. Det intressanta är dock att vi enkelt kan omvandla XREAD till ett blockerande kommando genom att ange argumentet BLOCK:

> XREAD BLOCK 0 STREAMS mystream $
I exemplet ovan anges den nya parametern BLOCK med en tidsgräns på 0 millisekunder (vilket innebär oändlig väntan). Dessutom, istället för att skicka en vanlig identifierare för strömmen mystream, gavs en speciell identifierare $. Denna speciella identifierare innebär att XREAD ska använda den maximala identifieraren i strömmen mystream. Så vi kommer att ta emot endast nya meddelanden från det ögonblick vi började lyssna. På sätt och vis liknar detta Unix-kommandot "tail -f".

Observera att när vi använder BLOCK-alternativet behöver vi inte nödvändigtvis använda ett speciellt ID $. Vi kan använda vilket befintligt ID som helst i strömmen. Om kommandot kan hantera vår förfrågan omedelbart, utan att blockera, kommer det att göra det, annars kommer det att blockeras.

Blockerande XREAD kan också lyssna på flera strömmar samtidigt, det är bara nödvändigt att ange deras namn. I så fall kommer kommandot att returnera posten för den första strömmen som fick data. Den första prenumeranten som blockeras för denna ström kommer att ta emot data först.

Konsumentgrupper

I vissa uppgifter vill vi avgränsa prenumeranternas tillgång till meddelanden inom en ström. Ett exempel på när detta kan vara användbart är en meddelandekö med arbetare som kommer att ta emot olika meddelanden från strömmen, vilket möjliggör att skala behandling av meddelanden.

Om vi föreställer oss att vi har tre prenumeranter C1, C2, C3 och en ström som innehåller meddelandena 1, 2, 3, 4, 5, 6, 7, kommer behandlingen av meddelandena att ske som i diagrammet nedan:

1 -> C1 2 -> C2 3 -> C3 4 -> C1 5 -> C2 6 -> C3 7 -> C1
För att uppnå denna effekt använder Redis Stream ett begrepp som kallas Konsumentgrupp. Detta begrepp liknar en pseudoprenumerant som får data från strömmen, men hanteras faktiskt av flera prenumeranter inom gruppen och ger specifika garantier:

Varje meddelande levereras till olika prenumeranter inom gruppen.
Inom gruppen identifieras prenumeranter av ett namn som är en sträng med skiftlägeskänslighet. Om någon prenumerant tillfälligt faller ur gruppen kan den återfå sin plats i gruppen med sitt unika namn.
Varje konsumentgrupp följer begreppet 'första olästa meddelande'. När en prenumerant begär nya meddelanden kan den endast få de meddelanden som aldrig tidigare har levererats till någon prenumerant inom gruppen.
Det finns ett kommando för att bekräfta framgångsrik behandling av meddelandet av prenumeranten. Så länge detta kommando inte har anropats kommer det begärda meddelandet att förbli i statusen 'pending'.
Inom konsumentgruppen kan varje prenumerant begära en historik av meddelanden som har levererats just till honom, men som ännu inte har behandlats (i statusen 'pending').

På ett sätt kan tillståndet hos gruppen representeras så här:

+----------------------------------------+
| consumer_group_name: mygroup          
| consumer_group_stream: somekey        
| last_delivered_id: 1292309234234-92    
|                                                           
| consumers:                                          
|    "consumer-1" med väntande meddelanden  
|       1292309234234-4                          
|       1292309234232-8                          
|    "consumer-42" med väntande meddelanden 
|       ... (och så vidare)                             
+----------------------------------------+

Nu är det dags att bekanta sig med de grundläggande kommandona för Consumer Group, nämligen:

XGROUP används för att skapa, radera och hantera grupper
XREADGROUP används för att läsa strömmen via gruppen
XACK — detta kommando låter prenumeranten markera meddelandet som framgångsrikt behandlat

Skapa en Consumer Group

Anta att strömmen mystream redan finns. Då kommer kommandot för att skapa gruppen att se ut som följer:

> XGROUP CREATE mystream mygroup $ OK
När vi skapar en grupp måste vi ange ett ID, med vilket gruppen kommer att börja ta emot meddelanden. Om vi vill ta emot alla nya meddelanden kan vi använda det speciella ID:t $ (som i vårt exempel ovan). Om istället det speciella ID:t anges som 0, så kommer gruppen att få tillgång till alla meddelanden i strömmen.

Nu när gruppen har skapats kan vi genast börja läsa meddelanden med hjälp av kommandot XREADGROUP. Detta kommando liknar mycket XREAD och har en valfri parameter BLOCK. Men det finns en obligatorisk parameter GROUP som alltid måste anges med två argument: gruppens namn och prenumerantens namn. Parameter COUNT stöds också.

Innan vi läser strömmen, låt oss lägga till några meddelanden där:

> XADD mystream * message apple
1526569495631-0
> XADD mystream * message orange
1526569498055-0
> XADD mystream * message strawberry
1526569506935-0
> XADD mystream * message apricot
1526569535168-0
> XADD mystream * message banana
1526569544280-0

Och nu ska vi försöka läsa denna ström genom gruppen:

> XREADGROUP GROUP mygroup Alice COUNT 1 STREAMS mystream >
1) 1) "mystream"
   2) 1) 1) 1526569495631-0
         2) 1) "message"
            2) "apple"

Det ovanstående kommandot säger ordagrant följande:

«Jag, Alice-prenumeranten, medlem av gruppen mygroup, vill läsa från strömmen mystream ett meddelande som aldrig har levererats till någon tidigare.»

Varje gång en prenumerant utför en åtgärd med en grupp måste han ange sitt namn och tydligt identifiera sig inom gruppen. I kommandot ovan finns en till mycket viktig detalj – den speciella identifieraren ">>". Denna speciella identifierare filtrerar meddelanden och behåller endast de som inte tidigare har levererats.

I vissa speciella fall kan du ange ett verkligt identifieringsnummer, som 0 eller något annat giltigt identifieringsnummer. I så fall kommer kommandot XREADGROUP att ge dig historiken för meddelanden med status "pending" som har levererats till den angivna prenumeranten (Alice), men som fortfarande inte har bekräftats med kommandot XACK.

Vi kan kontrollera detta beteende genom att omedelbart ange identifieraren 0, utan alternativet COUNT. Vi kommer att se ett enda väntande meddelande, nämligen meddelandet med äpplet:

> XREADGROUP GROUP mygroup Alice STREAMS mystream 0
1) 1) "mystream"
   2) 1) 1) 1526569495631-0
         2) 1) "message"
            2) "apple"

Men om vi bekräftar meddelandet som framgångsrikt behandlat, kommer det inte längre att visas:

> XACK mystream mygroup 1526569495631-0
(integer) 1
> XREADGROUP GROUP mygroup Alice STREAMS mystream 0
1) 1) "mystream"
   2) (tom lista eller uppsättning)

Nu är det Bobs tur att läsa något:

> XREADGROUP GROUP mygroup Bob COUNT 2 STREAMS mystream >
1) 1) "mystream"
   2) 1) 1) 1526569498055-0
         2) 1) "message"
            2) "orange"
      2) 1) 1526569506935-0
         2) 1) "message"
            2) "strawberry"

Bob, medlem av gruppen mygroup, bad om högst två meddelanden. Kommandot rapporterar bara otilldelade meddelanden på grund av den speciella identifieraren ">>". Som du ser visas inte meddelandet "apple", eftersom det redan har levererats till Alice, så Bob får "orange" och "strawberry".

Således kan Alice, Bob och alla andra prenumeranter i gruppen läsa olika meddelanden från samma ström. De kan också läsa sin historik av obearbetade meddelanden eller markera meddelanden som bearbetade.

Det finns några saker att tänka på:

Så snart prenumeranten läser meddelandet med kommandot XREADGROUP, går detta meddelande in i tillståndet "pending" och låses för den specifika prenumeranten. Andra prenumeranter i gruppen kan inte läsa detta meddelande.
Prenumeranter skapas automatiskt vid första omnämnandet, det är inte nödvändigt att skapa dem explicit.
Med hjälp av XREADGROUP Du kan läsa meddelanden från flera olika flöden samtidigt, men för att detta ska fungera måste du först skapa grupper med samma namn för varje flöde med hjälp av XGROUP

Återställning efter krasch

En prenumerant kan återhämta sig efter en krasch och läsa sin lista med meddelanden med status "pending". Men i den verkliga världen kan prenumeranter misslyckas helt. Vad händer med de hängande meddelandena om prenumeranten inte kan återhämta sig efter kraschen?
Consumer Group erbjuder en funktion som används just för sådana fall — när det är nödvändigt att byta ägare av meddelanden.

Först måste du anropa kommandot XPENDING, som visar alla meddelanden i gruppen med status "pending". I sin enklaste form anropas kommandot bara med två argument: namnet på flödet och namnet på gruppen:

> XPENDING mystream mygroup
1) (integer) 2
2) 1526569498055-0
3) 1526569506935-0
4) 1) 1) "Bob"
      2) "2"

Kommandot visade antalet obearbetade meddelanden för hela gruppen och för varje prenumerant. Vi har bara Bob med två obearbetade meddelanden, eftersom det enda meddelandet som begärdes av Alice bekräftades med XACK.

Vi kan begära ytterligare information genom att använda fler argument:

XPENDING {key} {groupname} [{start-id} {end-id} {count} [{consumer-name}]]
{start-id} {end-id} — intervall av identifierare (kan använda "-" och "+")
{count} — antal leveransförsök
{consumer-name} — namn på gruppen

> XPENDING mystream mygroup - + 10
1) 1) 1526569498055-0
   2) "Bob"
   3) (integer) 74170458
   4) (integer) 1
2) 1) 1526569506935-0
   2) "Bob"
   3) (integer) 74170458
   4) (integer) 1

Nu har vi detaljer för varje meddelande: identifierare, prenumerantens namn, stilleståndstid i millisekunder och slutligen antal leveransförsök. Vi har två meddelanden från Bob, och de har varit stillastående i 74170458 millisekunder, ungefär 20 timmar.

Observera att ingenting hindrar oss från att kontrollera vad meddelandets innehåll var, bara genom att använda XRANGE.

> XRANGE mystream 1526569498055-0 1526569498055-0
1) 1) 1526569498055-0
   2) 1) "meddelande"
      2) "orange"

Vi måste helt enkelt upprepa samma identifierare två gånger i argumenten. Nu när vi har en viss uppfattning kan Alice besluta att efter 20 timmar av stillestånd är det troligt att Bob inte kommer att återhämta sig, och det är dags att begära dessa meddelanden och återuppta deras bearbetning istället för Bob. För detta använder vi kommandot XCLAIM:

XCLAIM {key} {group} {consumer} {min-idle-time} {ID-1} {ID-2} ... {ID-N}
Med det här kommandot kan vi få ett "främmande" meddelande som ännu inte har behandlats genom att byta ägare till {consumer}. Vi kan dock också ange minimal stilleståndstid {min-idle-time}. Detta hjälper till att undvika situationen där två kunder försöker byta ägare för samma meddelanden samtidigt.

Kund 1: XCLAIM mystream mygroup Alice 3600000 1526569498055-0 Kund 2: XCLAIM mystream mygroup Lora 3600000 1526569498055-0
Den första kunden kommer att återställa stilleståndstiden och öka räknaren för leveranser. Så den andra kunden kommer inte att kunna begära det.

> XCLAIM mystream mygroup Alice 3600000 1526569498055-0
1) 1) 1526569498055-0
   2) 1) "meddelande"
      2) "orange"

Meddelandet har framgångsrikt begärts av Alice, som nu kan bearbeta meddelandet och bekräfta det.

Av det ovanstående exemplet kan vi se att en lyckad begäran returnerar själva meddelandets innehåll. Men det är inte nödvändigt. JUSTID-alternativet kan användas för att returnera endast meddelande-ID:n. Detta är användbart om du inte är intresserad av meddelandets detaljer och vill öka systemets prestanda.

Leveransräknare

Räknaren som du ser i utskriften XPENDING – är antalet leveranser för varje meddelande. Denna räknare ökar på två sätt: när meddelandet framgångsrikt begärs via XCLAIM eller när anropet används XREADGROUP.

Det är normalt att vissa meddelanden levereras flera gånger. Det viktigaste är att alla meddelanden har behandlats till slut. Ibland kan det uppstå problem vid bearbetningen av ett meddelande, antingen på grund av skador på själva meddelandet eller för att bearbetningen av meddelandet orsakar ett fel i bearbetningskoden. I sådana fall kan det hända att ingen kan behandla detta meddelande. Eftersom vi har en leveransförsöksräknare kan vi använda den för att upptäcka sådana situationer. Därför, så snart leveransräknaren når det stora antal som du har angivit, kan det vara klokare att placera detta meddelande i en annan ström och skicka en avisering till systemadministratören.

Strömmarnas tillstånd

Team XINFO används för att begära olika typer av information om strömmen och dess grupper. Till exempel ser den grundläggande formen av kommandot ut så här:

> XINFO STREAM mystream
 1) length
 2) (integer) 13
 3) radix-tree-keys
 4) (integer) 1
 5) radix-tree-nodes
 6) (integer) 2
 7) groups
 8) (integer) 2
 9) first-entry
10) 1) 1524494395530-0
    2) 1) "a"
       2) "1"
       3) "b"
       4) "2"
11) last-entry
12) 1) 1526569544280-0
    2) 1) "meddelande"
       2) "banana"

Kommandot ovan visar allmän information om den angivna strömmen. Nu ett lite mer avancerat exempel:

> XINFO GROUPS mystream
1) 1) namn
   2) "mygroup"
   3) konsumenter
   4) (heltal) 2
   5) väntande
   6) (heltal) 2
2) 1) namn
   2) "some-other-group"
   3) konsumenter
   4) (heltal) 1
   5) väntande
   6) (heltal) 0

Kommandot ovan visar allmän information om alla grupper i den angivna strömmen

> XINFO CONSUMERS mystream mygroup
1) 1) namn
   2) "Alice"
   3) väntande
   4) (heltal) 1
   5) inaktiv
   6) (heltal) 9104628
2) 1) namn
   2) "Bob"
   3) väntande
   4) (heltal) 1
   5) inaktiv
   6) (heltal) 83841983

Kommandot ovan visar information om alla prenumeranter i den angivna strömmen och gruppen.
Om du glömmer syntaksen för kommandot kan du alltid be om hjälp av själva kommandot:

> XINFO HELP
1) XINFO {subcommand} arg arg ... arg. Underkommandon är:
2) CONSUMERS {nyckel} {gruppenamn}  -- Visa konsumentgrupper för grupp {gruppenamn}.
3) GROUPS {nyckel}                 -- Visa strömmens konsumentgrupper.
4) STREAM {nyckel}                 -- Visa information om strömmen.
5) HELP                         -- Skriv ut denna hjälp.

Begränsning av strömmens storlek

Många applikationer vill inte samla data i en ström för alltid. Det är ofta användbart att ha en maximal mängd meddelanden i strömmen. I andra fall är det bra att flytta alla meddelanden från strömmen till ett annat permanent lagringsutrymme när den angivna storleken på strömmen nås. Du kan begränsa strömmens storlek med hjälp av parametern MAXLEN i kommandot XADD:

> XADD mystream MAXLEN 2 * value 1
1526654998691-0
> XADD mystream MAXLEN 2 * value 2
1526654999635-0
> XADD mystream MAXLEN 2 * value 3
1526655000369-0
> XLEN mystream
(heltal) 2
> XRANGE mystream - +
1) 1) 1526654999635-0
   2) 1) "value"
      2) "2"
2) 1) 1526655000369-0
   2) 1) "value"
      2) "3"

När MAXLEN används tas gamla poster automatiskt bort när den angivna längden nås, så att strömmen har en konstant storlek. Men beskärning sker i detta fall inte på det mest effektiva sättet i minnet i Redis. Situationen kan förbättras på följande sätt:

XADD mystream MAXLEN ~ 1000 * ... inmatningsfält här ...
Argumentet ~ i exemplet ovan innebär att vi inte nödvändigtvis behöver begränsa strömmens längd till ett specifikt värde. I vårt exempel kan det vara vilket som helst värde som är större än eller lika med 1000 (till exempel 1000, 1010 eller 1030). Vi har bara tydligt angett att vi vill att vår ström skall lagra minst 1000 poster. Detta gör minneshanteringen mycket mer effektiv inuti Redis.

Det finns också ett separat kommando XTRIM, som gör samma sak:

> XTRIM mystream MAXLEN 10

> XTRIM mystream MAXLEN ~ 10

Permanenta lagring och replikering

Redis Stream replikeras asynkront till slavnoder och lagras i filer av typen AOF (snapshot av alla data) och RDB (logg över alla skrivoperationer). Återställning av tillstånd för Consumer Groups stöds också. Så om ett meddelande har statusen «pending» på masternoden, kommer det att ha samma status på slavnoderna.

Ta bort specifika element från strömmen

För att ta bort meddelanden finns det ett speciellt kommando XDEL. Kommandot tar ett strömnamn följt av identifierare för meddelanden som ska tas bort:

> XRANGE mystream - + COUNT 2
1) 1) 1526654999635-0
   2) 1) "value"
      2) "2"
2) 1) 1526655000369-0
   2) 1) "value"
      2) "3"
> XDEL mystream 1526654999635-0
(integer) 1
> XRANGE mystream - + COUNT 2
1) 1) 1526655000369-0
   2) 1) "value"
      2) "3"

Vid användning av detta kommando bör du beakta att minnet faktiskt inte kommer att frigöras omedelbart.

Strömmar med noll längd

Skillnaden mellan strömmar och andra datatyper i Redis är att när andra datatyper inte längre har några element, så raderas själva datatypen som en bieffekt från minnet. Till exempel kommer ett sorterat set att helt tas bort när ZREM-anropet tar bort det sista elementet. Istället tillåts strömmar att förbli i minnet även utan några element inuti.