Redis Stream — uus abstraktne andmetüüp, mis esitati Redis versiooniga 5.0
Kontseptsiooniliselt on Redis Stream nagu List, kuhu saate teha kirjeid. Igal kirjel on ainulaadne identifikaator. Vaikimisi genereeritakse identifikaator automaatselt ja sisaldab ajatemplit. Seetõttu saate taotleda kirjeid ajavahemike kaupa või saada uusi andmeid voos, nagu Unix käsk „tail -f” loeb logifaili ja ootab uusi andmeid. Pange tähele, et voogu võivad korraga kuulata mitu klienti, just nagu paljud „tail -f” protsessid saavad samal ajal faili lugeda, omavahel konfliktsitamata.

Uue andmetüübi kõiki eeliseid mõistmiseks tuletame meelde vanemaid Redis struktuure, mis osaliselt kordavad Redis Stream funktsionaalsust.

Redis PUB/SUB

Redis Pub/Sub on lihtne sõnumisüsteem, mis on juba teie key-value salvesse integreeritud. Kuid lihtsuse eest tuleb maksta:

Kui publisher mingil põhjusel ebaõnnestub, siis kaotab ta kõik oma tellijad.
Publisher peab teadma kõigi oma tellijate täpset aadressi.
Väljaandja võib koormata oma tellijaid, kui andmed avaldatakse kiiremini, kui neid töödeldakse.
Sõnum eemaldatakse väljaandja puhvrist kohe pärast avaldamist, sõltumata sellest, kui paljudele tellijatele see toimitakse ja kui kiiresti nad suudavad selle sõnumi töödelda.
Kõik tellijad saavad sõnumi samal ajal. Tellijad peavad omavahel kuidagi kokku leppima sama sõnumi töötlemise järjekorras.
Ei ole sisseehitatud mehhanismi tellijate sõnumi eduka töötlemise kinnitamiseks. Kui tellija saab sõnumi ja katkee töötlemise ajal, ei saa väljaandja sellest teada.

Redis List

Redis List on andmestruktuur, mis toetab lukustamisega lugemis käske. Saate lisada ja lugeda sõnumeid nimekirja algusest või lõpust. Selle struktuuri põhjal on võimalik luua hea virn või järjekord teie jaotatud süsteemile ning seda on enamasti piisavalt. Peamised erinevused Redis Pub/Sub-ist:

Sõnum toimetatakse ühele kliendile. Esimene lukustatud lugemisega klient saab andmed esimesena.
Klient peab iga sõnumi lugemise operatsiooni ise algatama. List ei tea klientidest midagi.
Sõnumid säilivad kuni need keegi loeb või ei kustutata selgesõnaliselt. Kui olete seadistanud Redis serveri andmete ketasse salvestamiseks, suureneb süsteemi usaldusväärtus järsult.

Sissejuhatus voogu

Salvestuse lisamine voogu

Meeskond XADD lisab voogu uue salvestuse. Salvestus ei ole lihtsalt rida, see koosneb ühest või mitmest võtme-väärtuse paarist. Seega on iga salvestus juba struktureeritud ja meenutab CSV faili struktuuri.

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

Ülaltoodud näites lisame nimega (võtmega) 'mystream' voogu kaks väljad: 'sensor-id' ja 'temperature' väärtustega '1234' ja '19.8'. Teise argumendina aktsepteerib käsk identifikaatorit, mis antakse kirjele — see identifikaator määratleb iga kirje voos üheselt. Kuid käesoleval juhul edastasime *, kuna soovime, et Redis genereeriks meile uue identifikaatori. Iga uus identifikaator suureneb, seega on igal uuel kirjel suurem identifikaator võrreldes eelnevate kirjadega.

Identifikaatori formaat

Käsklusest tagastatud kirje identifikaator XADD, koosneb kahest osast:

{millisecondsTime}-{sequenceNumber}
millisecondsTime — Unix-aeg millisekundites (ajakood Redis). Kui aga praegune aeg osutub eelneva kirje ajast samaks või väiksemaks, kasutatakse eelneva kirje ajamärki. Seega, kui serveri aeg tagastatakse minevikku, siis uus identifikaator säilitab endiselt suureneva omaduse. serverile Redis). Kuid kui praegune aeg osutub sama või väiksemaks kui eelneva kirje aeg, kasutatakse eelneva kirje ajatemplit. Seega, kui serveri aeg läheb minevikku, säilitab uus identifikaator endiselt kasvamise omaduse.

sequenceNumber kasutatakse ühe ja sama millisekundi jooksul loodud kirjete puhul. sequenceNumber suurendatakse 1 võrreldes eelneva kirje numbriga. Kuna sequenceNumber on 64 biti suurune, siis praktikas ei tohiks te sattuda piirangusse selle kohta, kui palju kirjeid saab ühe millisekundi jooksul genereerida.

Selliste tuvastajate formaat võib esmapilgul tunduda kummaline. Skeptiline lugeja võib küsida, miks aeg on osa tuvastajast. Põhjus on see, et Redis vood toetavad vahemiku päringuid tuvastajate järgi. Kuna tuvastaja on seotud kirje loomise ajaga, siis võimaldab see küsida ajavahemikke. Toome välja konkreetse näite, kui liigume edasi käsitsi, XRANGE.

Kui kasutajal on mingil põhjusel vaja määrata oma tuvastaja, mis on näiteks seotud mõne välist süsteemiga, saame selle edastada käsule XADD tähe * asemel, nagu allpool näidatud:

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

Pange tähele, et sel juhul peate ise jälgima tuvastaja suurendamist. Meie näites on minimaalne tuvastaja „0-1“, seega ei aktsepteeri käsk veel ühte tuvastajat, mis on võrdne või väiksem kui „0-1“.

> XADD somestream 0-1 foo bar
(error) ERR Määratud ID XADD on võrdne või väiksem sihtvoo ülemisest elemendist

Kirjete arv voos

Võite voos olevate kirjeid saada, kasutades lihtsalt käsku XLEN. Meie näite jaoks tagastab see käsk järgmise väärtuse:

> XLEN somestream
(integer) 2

Küsimused vahemiku järgi — XRANGE ja XREVRANGE

Et küsida andmeid vahemiku järgi, peame määrama kaks identifikaatorit — vahemiku algus ja lõpp. Tagastatav vahemik sisaldab kõiki elemente, sealhulgas piire. Samuti on olemas kaks erilise identifikaatorit «-» ja «+», mis vastavad vastavalt kõige väiksemale (esimene kirje) ja kõige suuremale (viimane kirje) identifikaatorile voos. Allolev näide kuvab voos kõik kirjed.

> 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"

Iga tagastatav kirje on kahest elemendist koosnev massiiv: ID ja võtme-väärtuse paaride loend. Oleme juba maininud, et kirje id-d on ajaga seotud. Seetõttu saame küsida konkreetse ajavahemiku ulatust. Siiski saame päringus näidata mitte täis id-d, vaid ainult Unix-aega, jättes välja osa, mis seondub sequenceNumber. Välja jäetud osa id-st omistatakse automaatselt nulliks ulatuse alguses ja maksimaalsele võimalikule väärtusele ulatuse lõpus. Allpool on näide, kuidas küsida kahe millisekundi ulatust.

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

Meil on sellel ulatusel ainult üks kirje, kuid reaalses andmekogus võib tagastatav tulemus olla tohutu. Just sellepärast XRANGE toetab COUNT valikut. Täites arv, saame lihtsalt vastu võtta esimesed N kirjet. Kui peame saama järgmised N kirjet (lehtede vahel navigeerimine), saame kasutada viimati saadud id-d ja suurendada seda sequenceNumber üksuse ja küsida uuesti. Vaadakem seda järgmises näites. Alustame 10 elemendi lisamisega XADD (eeldades, et voog mystream on juba täidetud 10 elemendiga). Itereerimise alustamiseks, saades iga käsku 2 elementi, alustame täielikust vahemikust, kuid COUNTiga, mis on 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"

Et jätkata iteratsiooni järgmiste kahe elemendiga, peame valima viimase saadud identifikaatori, st 1519073279157-0, ja lisama 1 sequenceNumber.
Saadav identifikaator, antud juhul 1519073279157-1, võib nüüd kasutada uue vahemiku algusargumendina järgmise kutse jaoks 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"

Ja nii edasi. Kuna keerukus XRANGE on O(log (N)) otsimise jaoks ja seejärel O(M) M elemendi tagastamiseks, on iga iteratsiooni samm kiire. Seega, kasutades XRANGE on võimalik tõhusalt vooge iteratsiooni teha.

Meeskond XREVRANGE on võrdne XRANGE, kuid tagastab elemendid vastupidises järjekorras:

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

Märge, et käsk XREVRANGE võtab argumentide vahemiku start ja stop vastupidises järjekorras.

Uute kirjeid lugemine XREAD abil

Tihti tekib vajadus tellida voog ja saada ainult uusi sõnumeid. See kontseptsioon võib tunduda sarnane Redis Pub/Sub-ile või tõkestava Redis List-i suhtes, kuid Redis Streami kasutamise viisid on põhimõtteliselt erinevad:

Iga uus sõnum saadetakse vaikimisi iga tellijani. See käitumine erineb tõkestavast Redis List-ist, kus uut sõnumit loeb ainult üks tellija.
Samal ajal, kui Redis Pub/Sub unustab kõik sõnumid ja ei salvesta neid kunagi, salvestatakse Streamis kõik sõnumid määramatuks ajaks (kui klient seda selgesõnaliselt ei tuvasta).
Redis Stream võimaldab piirduda sõnumite juurdepääsuga ühes voos. Spetsiifiline tellija näeb ainult oma isiklikku sõnumite ajalugu.

Võite tellida voogu ja saada uusi sõnumeid, kasutades käsku XREAD. See on veidi keerulisem kui XRANGE, seega alustame alguses lihtsamate näidete abil.

> 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"

Eeltoodud näites on toodud mitteblokeeriv vorm. XREADPange tähele, et valik COUNT ei ole kohustuslik. Tegelikult on ainus kohustuslik valik käsus STREAMS, mis määrab voogude nimekirja koos vastava maksimaalse identifikaatoriga. Oleme kirjutanud «STREAMS mystream 0» — me tahame saada kõik kirjed voos mystream, mille identifikaator on suurem kui «0-0». Nagu näha näites, tagastab käsk voonime, kuna saame samal ajal liituda mitme vooga. Oleme võinud kirjutada näiteks «STREAMS mystream otherstream 0 0». Pange tähele, et pärast valikut STREAMS peame esmalt esitama kõigi vajalike voogude nimed ja seejärel identifikaatorite loendi.

Selles lihtsas vormis ei tee käsk midagi erilist võrreldes XRANGE. Kuid huvitav on see, et saame hõlpsasti muuta XREAD blokeerivaks käskuks, määrates argumendi BLOCK:

> XREAD BLOCK 0 STREAMS mystream $
Eespool toodud näites on uus BLOCK valik, mille ooteaeg on 0 millisekundit (see tähendab lõputut ootamist). Veelgi enam, tavapärase mystream voolu identifikaatori edastamise asemel edastati spetsiaalne identifikaator $. See spetsiaalne identifikaator tähistab, et XREAD peame kasutama maksimaalset identifikaatorit voolus mystream. Nii et me saame ainult uusi sõnumeid alates hetkest, mil alustasime kuulamist. Teatud määral sarnaneb see Unix käsuga «tail -f».

Pange tähele, et BLOCK valiku kasutamisel ei ole meil tingimata vaja kasutada spetsiaalset identifikaatorit $. Me võime kasutada mistahes olemasolevat voolu identifikaatorit. Kui käsk suudab meie soovi kohe täita, ilma blokeerimiseta, teeb ta seda; vastasel juhul blokeerib ta.

Blokeeriv XREAD saab samuti kuulata mitut voolu korraga, lihtsalt tuleb nende nimed määrata. Sel juhul tagastab käsk esimese voolu kirje, kuhu andmed saabusid. Esimene uusi andmeid blokeeritud tellija antud voolus saab andmeid esimesena.

Tarbijagrupp

Teatud ülesannetes soovime piirata tellijate juurdepääsu sõnumitele ühes voos. Näide, kui see võib olla kasulik, on sõnumijärjekord töötajatega, kes saavad voost erinevaid sõnumeid, võimaldades sõnumite töötlemise skaleerimist.

Kui kujutame ette, et meil on kolm tellijat C1, C2, C3 ja voog, mis sisaldab sõnumeid 1, 2, 3, 4, 5, 6, 7, siis sõnumite teenindamine toimub nagu alloleval diagrammil:

1 -> C1 2 -> C2 3 -> C3 4 -> C1 5 -> C2 6 -> C3 7 -> C1
Selle efekti saavutamiseks kasutab Redis Stream kontseptsiooni, mida nimetatakse Tarbijagrupiks. See kontseptsioon on sarnane pseudo-tellijaga, kes saab andmeid voost, kuid seda teenindab tegelikult mitu tellijat grupi sees, pakkudes teatud garanteeritud omadusi:

Iga sõnum toimetatakse erinevatele tellijatele grupi sees.
Grupi sees identifitseeritakse tellijad nime järgi, mis on juhtumiselt suur- ja väiketähtedega. Kui mõni tellija jääb grupist ajutiselt välja, võib ta taastuda grupis oma ainulaadse nime kaudu.
Iga Consumer Group järgib põhimõtet „esimene lugemata sõnum”. Kui tellija küsib uusi sõnumeid, saab ta ainult need sõnumid, mida pole kunagi varem ühelegi tellijale grupis edastatud.
On olemas selge käsu süsteem, et kinnitada sõnumi edastamise edukust tellijale. Kuni seda käsku ei kutsuta, jääb küsitud sõnum olekusse „pending”.
Iga tellija Consumer Group'i sees võib küsida sõnumite ajalugu, mis on just tema jaoks edastatud, kuid ei ole veel töödeldud (olekus „pending”).

Teatud mõttes võib grupi olekut esitada järgmiselt:

+----------------------------------------+
| consumer_group_name: mygroup          
| consumer_group_stream: somekey        
| last_delivered_id: 1292309234234-92    
|                                                           
| consumers:                                          
|    "consumer-1" with pending messages  
|       1292309234234-4                          
|       1292309234232-8                          
|    "consumer-42" with pending messages 
|       ... (and so forth)                             
+----------------------------------------+

Nüüd on aeg tutvuda peamiste käskudega Consumer Group'i jaoks, nimelt:

XGROUP kasutatakse gruppide loomise, hävitamise ja haldamise jaoks
XREADGROUP kasutatakse vooge gruppi lugemiseks
XACK — see käsk võimaldab tellijal märgistada sõnum edukalt töödelduna

Consumer Group'i loomine

Oletame, et voog mystream juba eksisteerib. Siis näeb grupi loomise käsk välja nii:

> XGROUP CREATE mystream mygroup $ OK
Grupi loomisel peame edastama ID, millest alates grupp hakkab sõnumeid saama. Kui soovime lihtsalt saada kõik uued sõnumid, saame kasutada spetsiaalset ID-d $, nagu meie ülaltoodud näites. Kui spetsiaalse ID asemel määratakse 0, on grupile saadaval kõik vooge sõnumid.

Nüüd, kui grupp on loodud, saame kohe alustada sõnumite lugemist käsuga XREADGROUP. See käsk on väga sarnane XREAD ja toetab valikulist võimalust BLOCK. Kuid on olemas kohustuslik valik GROUP, mis peab alati olema määratud kahe argumendiga: grupi nimi ja tellija nimi. Valik COUNT on samuti toetatud.

Enne voogude lugemist paneme sinna mõned sõnumid:

> 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

Nüüd proovime seda voogu lugeda grupi kaudu:

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

Ülaltoodud käsk ütleb sõna sõnalt järgmist:

„Mina, Alice, rühmaliige mygroup, tahan lugeda voost mystream üht sõnumit, mis pole kellelegi varem kohale toimetatud.“

Iga kord, kui tellija sooritab grupiga tehingu, peab ta ütlema oma nime, selgelt tuvastades end grupis. Ülaltoodud käes on veel üks väga oluline detail — eriline identifikaator „>“. See eriline identifikaator filterdab sõnumeid, jättes alles ainult need, mis ei ole veel kunagi kohale toimetatud.

Samuti, erilistel juhtudel, võite märkida tõelise identifikaatori, nagu 0 või mõni muu kehtiv identifikaator. Sel juhul käsk XREADGROUP tagastab teile sõnumite ajalugu, mille staatuseks on „pending”, mis on saadetud määratud tellijale (Alice), kuid mida pole veel kinnitatud käsuga. XACK.

Saame seda käitumist kontrollida, määrates kohe identifikaatori 0, ilma valikuta. COUNTNäeme ainult ühte ootel sõnumit, mis on sõnum õunaga:

> XREADGROUP GROUP mygroup Alice STREAMS mystream 0
1) 1) "mystream"
   2) 1) 1) 1526569495631-0
         2) 1) "sõnum"
            2) "õun"

Kui me kinnitame sõnumi kui edukalt töödeldud, siis see enam ei kuvata:

> XACK mystream mygroup 1526569495631-0
(integer) 1
> XREADGROUP GROUP mygroup Alice STREAMS mystream 0
1) 1) "mystream"
   2) (tühi loend või kogum)

Nüüd on Bobil aeg midagi lugeda:

> XREADGROUP GROUP mygroup Bob COUNT 2 STREAMS mystream >
1) 1) "mystream"
   2) 1) 1) 1526569498055-0
         2) 1) "sõnum"
            2) "oranž"
      2) 1) 1526569506935-0
         2) 1) "sõnum"
            2) "maasikas"

Bob, mygroupi liige, palus mitte rohkem kui kahte sõnumit. Käsk teatab ainult mitte kohaletoimetatud sõnumitest spetsiaalse identifikaatori „>” tõttu. Nagu näete, sõnum „õun” ei kuvata, kuna see on juba Alice'le saadetud, seega saab Bob sõnumid „oranž” ja „maasikas”.

Seega saavad Alice, Bob ja iga teine grupi tellija lugeda erinevaid sõnumeid samast voost. Samuti saavad nad lugeda oma töötlemata sõnumite ajalugu või märgistada sõnumeid kui töödeldud.

On mitmeid asju, mida tuleb meeles pidada:

Kuni tellija loeb sõnumit käsuna, XREADGROUP, läheb see sõnum seisundisse 'ootel' ja seondub selle konkreetse tellijaga. Grupi teised tellijad ei saa seda sõnumit lugeda.
Tellijad luuakse automaatselt esimese mainimise korral, nende selgesõnaline loomine ei ole vajalik.
Käesoleva abil XREADGROUP saate lugeda sõnumeid mitmest erinevast voost korraga, kuid selleks, et see toimiks, peate eelnevalt looma rühmad sama nimega iga voog jaoks kasutades XGROUP

Taasteprotsess

Tellija saab pärast tõrket taastuda ja uuesti lugeda oma 'ootele' seisundiga sõnumite nimekirja. Siiski võivad reaalses maailmas tellijad lõpuks ebaõnnestuda. Mis juhtub tellija külmutatud sõnumitega, kui ta ei suutnud pärast tõrket taastuda?
Consumer Group pakub funktsiooni, mis on mõeldud just selliste olukordade jaoks — kui on vajalik sõnumite omandiõiguse vahetamine.

Esmalt tuleb kutsuda käsk XPENDING, mis kuvab kõik grupi sõnumid, mille seisund on „pending”. Lihtsaimas vormis kutsutakse käsku ainult kahe argumendiga: voolu nimi ja grupi nimi:

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

Käsk väljastas töötlemata sõnumite arvu kogu grupi ja iga tellija jaoks. Meil on ainult Bob, kellel on kaks töötlemata sõnumit, sest ainus sõnum, mille Alice küsis, kinnitati. XACK.

Saame küsida lisainfot, kasutades rohkem argumente:

OOTE {key} {groupname} [{start-id} {end-id} {count} [{consumer-name}]]
{start-id} {end-id} — identifikaatorite vahemik (saab kasutada „-” ja „+”)
{count} — proovide kohaletoimetamise arv
{consumer-name} — grupi nimi

> 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

Nüüd on meil iga sõnumi kohta üksikasjad: identifikaator, tellija nimi, seisaku aeg millisekundites ja lõpuks kohaletoimetamise katsete arv. Meil on kaks sõnumit Bobilt, mis on olnud seisakus 74170458 millisekundit, umbes 20 tundi.

Pange tähele, et miski ei takista meil kontrollimast, mis sõnumi sisu oli, kasutades lihtsalt XRANGE.

> XRANGE mystream 1526569498055-0 1526569498055-0
1) 1) 1526569498055-0
   2) 1) "sõnum"
      2) "apelsin"

Me peame lihtsalt sama identifikaatori argumentides kaks korda kordama. Nüüd, kui meil on mingisugune ettekujutus, võib Alice otsustada, et pärast 20-tunnist seisakut ei taastu Bob tõenäoliselt ja on aeg küsida neid sõnumeid ja jätkata nende töötlemist Bobi asemel. Selleks kasutame käsku XCLAIM:

XCLAIM {key} {group} {consumer} {min-idle-time} {ID-1} {ID-2} ... {ID-N}
Selle käsku abil saame hankida "võõra" sõnumi, mida pole veel töödeldud, muutes omanikku {consumer}. Samuti saame esitada minimaalne seisaku aeg {min-idle-time}. See aitab vältida olukorda, kus kaks klienti üritavad samaaegselt sama sõnumi omaniku vahetada:

Klient 1: XCLAIM mystream mygroup Alice 3600000 1526569498055-0 Klient 2: XCLAIM mystream mygroup Lora 3600000 1526569498055-0
Esimene klient vähendab seisakuid ja suurendab kohaletoimetamiste arvu. Teiseks kliendiks ei saa ta seda nõuda.

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

Sõnum on Alica poolt edukalt nõutud, kes nüüd saab sõnumit töödelda ja kinnitada.

Ülaltoodud näitest on näha, et edukas päring tagastab sõnumi sisu. Kuid see ei ole kindlasti vajalik. JUSTID valikut saab kasutada ainult sõnumi identifikaatorite tagastamiseks. See on kasulik, kui te ei ole sõnumi detailidest huvitatud ja soovite süsteemi jõudlust suurendada.

Kohaletoimetamise arvesti

Arvesti, mida näete väljastuses XPENDING — on iga sõnumi kohaletoimetamiste arv. Selline arvesti suureneb kahel viisil: kui sõnum on edukalt nõutud läbi XCLAIM või kui kasutatakse kõnet XREADGROUP.

See, et mõned sõnumid saadetakse mitu korda, on normaalne. Peamine on see, et kõik sõnumid oleksid lõpuks töödeldud. Mõnikord võivad sõnumite töötlemise käigus ilmneda probleemid, kas sõnumi enda rikke tõttu või töötleja koodis esineva vea tõttu. Sellisel juhul võib juhtuda, et seda sõnumit ei suudeta töötleda. Kuna meil on saatmisproovide arvuti, saame seda arvestit kasutada selliste olukordade tuvastamiseks. Seetõttu, kui saatmisproovide arv ulatub teie seatud suure arvuni, on mõistlik viia selline sõnum teise voogu ja saata süsteemiadministraatorile teade.

Voogude seisund

Meeskond XINFO kasutatakse voogude ja nende gruppide erineva teabe pärimiseks. Näiteks käsk näeb selline välja:

> 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) "message"
       2) "banana"

Ülalolev käsk näitab antud voogude üldteavet. Järgmine on veidi keerulisem näide:

> XINFO GROUPS mystream
1) 1) nimi
   2) "mygroup"
   3) tarbijad
   4) (täisarv) 2
   5) ootel
   6) (täisarv) 2
2) 1) nimi
   2) "some-other-group"
   3) tarbijad
   4) (täisarv) 1
   5) ootel
   6) (täisarv) 0

Ülalolev käsk näitab üldteavet kõigi antud voogude gruppide kohta.

> XINFO CONSUMERS mystream mygroup
1) 1) nimi
   2) "Alice"
   3) ootel
   4) (täisarv) 1
   5) tühi
   6) (täisarv) 9104628
2) 1) nimi
   2) "Bob"
   3) ootel
   4) (täisarv) 1
   5) tühi
   6) (täisarv) 83841983

Ülalolev käsk näitab teavet kõigi antud voo ja grupi tellijate kohta.
Kui unustate käsu süntaksi, pöörduge lihtsalt käsu enda poole abi saamiseks:

> XINFO HELP
1) XINFO {alamkäsk} arg arg ... arg. Alamkäskude hulka kuuluvad:
2) CONSUMERS {võti} {grupinimi}  -- Näita grupi {grupinimi} tarbijagrupe.
3) GROUPS {võti}                 -- Näita voogi tarbijagruppe.
4) STREAM {võti}                 -- Näita teavet voo kohta.
5) HELP                         -- Prindi see abi.

Voo suuruse piirang

Paljud rakendused ei soovi andmeid pidevalt voogu koguda. Sageli on kasulik, kui voos on maksimaalne lubatud sõnumite arv. Muudel juhtudel on mõistlik viia kõik sõnumid voost teisele püsivale salvestusse, kui voog on saavutanud määratud suuruse. Voo suurust saab piirata MAXLEN parameetri kaudu käsus. 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
(integer) 2
> XRANGE mystream - +
1) 1) 1526654999635-0
   2) 1) "value"
      2) "2"
2) 1) 1526655000369-0
   2) 1) "value"
      2) "3"

MAXLEN kasutamisel kustutatakse vanad kirjed automaatselt, kui jõutakse ettenähtud pikkusele, nii et voog on pideva suurusega. Siiski ei toimu sellisel juhul trimmimine Redis'i mälu kõige tõhusamal viisil. Olukorda saab parandada järgmiste meetoditega:

XADD mystream MAXLEN ~ 1000 * ... sisestusväljad siia ...
Argument ~ ülaltoodud näites tähendab, et me ei pea voolu pikkust piirama konkreetse väärtusega. Meie näites võib see olla mis tahes number, mis on suurem või võrdne 1000 (nt 1000, 1010 või 1030). Lihtsalt oleme selgelt öelnud, et soovime, et meie voog säilitaks vähemalt 1000 kirjet. See muudab mälu kasutamise palju efektiivsemaks Redis'is.

Samuti on olemas eraldi käsk XTRIM, mis teeb sama:

> XTRIM mystream MAXLEN 10

> XTRIM mystream MAXLEN ~ 10

Püsiv säilitamine ja replikatsioon

Redis Stream replitseerib asünkroonselt slave nootidesse ja salvestab failidesse AOF (kõigi andmete snapshot) ja RDB (kõigi kirjutamistehingute logi). Samuti toetatakse Consumer Groups oleku replikatsiooni. Seetõttu, kui sõnum on master noodi peal 'pending' olekus, siis slave nootides on selle sõnumi olek sama.

Eri elementide eemaldamine voost

Sõnumite eemaldamiseks on olemas eriline käsk XDEL. Käsk saab voogude nime, millele järgneb sõnumite identifikaatorid, mida tuleb eemaldada:

> 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"

Selle käsu kasutamise juures tuleb arvesse võtta, et mälu vabastamine ei toimu kohe.

Nullpikkusega vood

Vood ja teised Redis andmestruktuurid erinevad sellest, et kui teised andmestruktuurid ei sisalda enam elemente, siis kustutatakse andmestruktuur mälust. Näiteks, sorteeritud hulk kustutatakse täielikult, kui ZREM kutsub välja viimane element. Vastupidiselt on voogudel lubatud jääda mällu, isegi kui neil pole ühtegi elementi.