Redis Stream on uus abstraktne andmetüüp, mis võeti Redis versiooniga 5.0 kasutusele
Põhimõtteliselt on Redis Stream loend, kuhu saate kirjeid lisada. Igal kirjel on kordumatu identifikaator. Vaikimisi luuakse ID automaatselt ja see sisaldab ajatemplit. Seetõttu saate aja jooksul teha päringuid kirjete vahemike kohta või saada uusi andmeid, kui need voogu saabuvad, sarnaselt sellele, nagu Unixi käsk "tail -f" loeb logifaili ja hangub uute andmete ootamise ajal. Pange tähele, et lõime saavad korraga kuulata mitu klienti, nii nagu paljud "tail -f" protsessid saavad lugeda faili üheaegselt ilma üksteisega konflikti tekitamata.

Et mõista kõiki uue andmetüübi eeliseid, vaatame lühidalt kaua eksisteerinud Redise struktuure, mis osaliselt kordavad Redis Streami funktsioone.

Redis PUB/SUB

Redis Pub/Sub on lihtne sõnumsidesüsteem, mis on teie võtmeväärtuste poodi juba sisse ehitatud. Lihtsusel on aga oma hind:

Kui kirjastaja mingil põhjusel ebaõnnestub, kaotab ta kõik oma tellijad
Väljaandja peab teadma kõigi oma tellijate täpset aadressi
Kirjastus võib oma tellijaid tööga üle koormata, kui andmed avaldatakse kiiremini kui neid töödeldakse
Sõnum kustutatakse väljaandja puhvrist kohe pärast avaldamist, olenemata sellest, kui paljudele tellijatele see edastati ja kui kiiresti nad suutsid seda sõnumit töödelda.
Kõik tellijad saavad sõnumi korraga. Tellijad peavad ise sama sõnumi töötlemise järjekorras kuidagi kokku leppima.
Puudub sisseehitatud mehhanism, mis kinnitaks, et tellija on sõnumi edukalt töödelnud. Kui tellija saab sõnumi ja jookseb töötlemise ajal kokku, ei saa väljaandja sellest teada.

Redise nimekiri

Redis List on andmestruktuur, mis toetab lugemiskäskude blokeerimist. Saate lisada ja lugeda sõnumeid loendi algusest või lõpust. Selle struktuuri põhjal saate oma hajutatud süsteemi jaoks luua hea pinu või järjekorra ja enamikul juhtudel sellest piisab. Peamised erinevused Redis Pub/Subist:

Sõnum edastatakse ühele kliendile. Esimene lugemisblokeeritud klient saab andmed esimesena.
Clint peab iga sõnumi lugemise ise algatama. List ei tea klientidest midagi.
Sõnumeid hoitakse seni, kuni keegi neid loeb või selgesõnaliselt kustutab. Kui konfigureerite Redise serveri andmeid kettale loputama, suureneb süsteemi töökindlus järsult.

Sissejuhatus voogu

Kirje lisamine voogu

Meeskond XADD lisab voogu uue kirje. Kirje ei ole lihtsalt string, see koosneb ühest või mitmest võtme-väärtuste paarist. Seega on iga kirje juba struktureeritud ja sarnaneb CSV-faili struktuuriga.

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

Ülaltoodud näites lisame voogu kaks välja nimega (võti) "mystream": "sensor-id" ja "temperature" väärtustega "1234" ja "19.8". Teise argumendina võtab käsk kirjele omistatava identifikaatori – see identifikaator identifitseerib voo iga kirje unikaalselt. Kuid antud juhul möödusime *-st, sest tahame, et Redis genereeriks meile uue ID. Iga uus ID suureneb. Seetõttu on igal uuel kirjel kõrgem identifikaator võrreldes eelmiste kirjetega.

Identifikaatori formaat

Käsu poolt tagastatud kirje ID XADD, koosneb kahest osast:

{millisecondsTime}-{sequenceNumber}
millisekunditAeg — Unixi aeg millisekundites (Redis serveri aeg). Kui aga praegune aeg on sama või väiksem kui eelmise salvestuse aeg, siis kasutatakse eelmise salvestuse ajatemplit. Seega, kui serveri aeg läheb ajas tagasi, säilitab uus identifikaator ikkagi juurdekasvu omaduse.

järjestusNumber kasutatakse sama millisekundi jooksul loodud kirjete jaoks. järjestusNumber suurendatakse eelmise kirjega võrreldes 1 võrra. Kuna järjestusNumber on 64 bitti suur, siis praktikas ei tohiks te ühe millisekundi jooksul genereeritavate kirjete arvu piirata.

Selliste identifikaatorite formaat võib esmapilgul veider tunduda. Umbusaldav lugeja võib küsida, miks aeg on identifikaatori osa. Põhjus on selles, et Redise vood toetavad vahemiku päringuid ID järgi. Kuna identifikaator on seotud kirje loomise ajaga, võimaldab see küsida ajavahemikke. Vaatleme konkreetset näidet, kui vaatame käsku XRANGE.

Kui kasutajal on mingil põhjusel vaja määrata oma identifikaator, mis on näiteks seotud mõne välise süsteemiga, siis saame selle käsule edastada XADD * 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 sellisel juhul peate ID-i juurdekasvu ise jälgima. Meie näites on minimaalne identifikaator "0-1", nii et käsk ei aktsepteeri teist identifikaatorit, mis on võrdne "0-1" või sellest väiksem.

> XADD somestream 0-1 foo bar
(error) ERR The ID specified in XADD is equal or smaller than the target stream top item

Kirjete arv voo kohta

Voo kirjete arvu on võimalik saada lihtsalt käsu abil XLEN. Meie näites tagastab see käsk järgmise väärtuse:

> XLEN somestream
(integer) 2

Vahemiku päringud – XRANGE ja XREVRANGE

Andmete taotlemiseks vahemiku järgi peame määrama kaks identifikaatorit – vahemiku alguse ja lõpu. Tagastatud vahemik sisaldab kõiki elemente, sealhulgas piire. Samuti on kaks spetsiaalset identifikaatorit “-” ja “+”, mis tähistavad vastavalt väikseimat (esimene kirje) ja suurimat (viimane kirje) identifikaatorit voos. Allolevas näites on loetletud kõik vookirjed.

> 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 tagastatud kirje on kahe elemendi massiiv: identifikaator ja võtme-väärtuste paaride loend. Me juba ütlesime, et kirje identifikaatorid on seotud ajaga. Seetõttu saame taotleda teatud ajavahemikku. Päringus saame aga täpsustada mitte täielikku identifikaatorit, vaid ainult Unixi aega, jättes välja osa, mis on seotud järjestusNumber. Identifikaatori väljajäetud osa seatakse vahemiku alguses automaatselt nulliks ja vahemiku lõpus maksimaalsele võimalikule väärtusele. Allpool on näide selle kohta, kuidas saate taotleda kahe millisekundi pikkust vahemikku.

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

Meil on selles vahemikus ainult üks kirje, kuid tegelikes andmekogumites võib tagastatav tulemus olla tohutu. Sel põhjusel XRANGE toetab valikut COUNT. Määrates koguse, saame lihtsalt N esimest kirjet. Kui meil on vaja hankida järgmised N kirjet (lehekülgede jagamine), saame kasutada viimati saadud ID-d, seda suurendada järjestusNumber ühekaupa ja küsi uuesti. Vaatame seda järgmises näites. Alustame 10 elemendi lisamist XADD (eeldusel, et mystream oli juba 10 elemendiga täidetud). Et alustada iteratsiooni, et saada iga käsu kohta 2 elementi, alustame kogu vahemikust, kuid COUNT võrdub 2-ga.

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

Järgmise kahe elemendiga itereerimise jätkamiseks peame valima viimati saadud ID, st 1519073279157-0, ja lisama 1 järjestusNumber.
Saadud ID-d, antud juhul 1519073279157-1, saab nüüd kasutada järgmise kõne uue vahemiku alguse argumendina 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. Keerukuse tõttu XRANGE on O(log(N)), et otsida ja seejärel O(M), et tagastada M elementi, siis on iga iteratsioonisamm kiire. Seega, kasutades XRANGE vooge saab tõhusalt itereerida.

Meeskond XREVRANGE on samaväärne XRANGE, kuid tagastab elemendid vastupidises järjekorras:

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

Pange tähele, et käsk XREVRANGE võtab vahemiku argumendid algus ja lõpp vastupidises järjekorras.

Uute kirjete lugemine XREADi abil

Sageli tekib ülesandeks voo tellimine ja ainult uute sõnumite vastuvõtmine. See kontseptsioon võib tunduda sarnane Redis Pub/Sub või Redis Listi blokeerimisega, kuid Redis Streami kasutamisel on põhimõttelisi erinevusi:

Iga uus sõnum edastatakse vaikimisi igale tellijale. See käitumine erineb blokeerivast Redise loendist, kus uut sõnumit loeb ainult üks tellija.
Kui Redis Pubis/Subis unustatakse kõik sõnumid ja neid ei säilitata kunagi, siis Streamis säilitatakse kõiki sõnumeid määramata aja jooksul (välja arvatud juhul, kui klient otseselt kustutab).
Redis Stream võimaldab teil eristada juurdepääsu ühe voo sõnumitele. Konkreetne tellija näeb ainult oma isiklikku sõnumite ajalugu.

Käsu abil saate lõime tellida ja uusi sõnumeid vastu võtta XLOE. See on natuke keerulisem kui XRANGE, seega alustame esmalt lihtsamate näidetega.

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

Ülaltoodud näide näitab mitteblokeerivat vormi XLOE. Pange tähele, et valik COUNT on valikuline. Tegelikult on ainus nõutav käsusuvand STREAMS, mis määrab voogude loendi koos vastava maksimaalse identifikaatoriga. Kirjutasime “STREAMS mystream 0” – tahame saada kõik mystreami voo kirjed, mille identifikaator on suurem kui “0-0”. Nagu näitest näha, tagastab käsk lõime nime, kuna saame korraga tellida mitu lõime. Võiksime 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 alles seejärel identifikaatorite loendi.

Sellel lihtsal kujul ei tee käsk võrreldes sellega midagi erilist XRANGE. Huvitav on aga see, et me saame kergesti pöörata XLOE blokeerimiskäsku, täpsustades argumendi BLOCK:

> XREAD BLOCK 0 STREAMS mystream $
Ülaltoodud näites on uus suvand BLOKKI määratud ajalõpuga 0 millisekundit (see tähendab määramatut ootamist). Veelgi enam, voo mystream tavapärase identifikaatori edastamise asemel edastati spetsiaalne identifikaator $. See eritunnus tähendab seda XLOE peab kasutama identifikaatorina mystreami maksimaalset identifikaatorit. Seega saame uusi sõnumeid ainult alates hetkest, kui kuulama hakkasime. Mõnes mõttes sarnaneb see Unixi käsuga "tail -f".

Pange tähele, et suvandi BLOCK kasutamisel ei pea me tingimata kasutama spetsiaalset identifikaatorit $. Saame kasutada mis tahes voos olemasolevat identifikaatorit. Kui meeskond saab meie päringu koheselt ilma blokeerimata teenindada, teeb ta seda, vastasel juhul blokeeritakse.

Blokeerimine XLOE saab kuulata ka mitut lõime korraga, peate lihtsalt määrama nende nimed. Sel juhul tagastab käsk esimese andmed vastu võtnud voo kirje. Esimene antud lõime jaoks blokeeritud tellija saab andmed esimesena.

Tarbijarühmad

Teatud ülesannete puhul soovime piirata abonendi juurdepääsu ühe lõime sees olevatele sõnumitele. Näide, kus see võib olla kasulik, on sõnumijärjekord töötajatega, kes saavad lõimest erinevaid sõnumeid, võimaldades sõnumite töötlemisel skaleerida.

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

1 -> C1 2 -> C2 3 -> C3 4 -> C1 5 -> C2 6 -> C3 7 -> C1
Selle efekti saavutamiseks kasutab Redis Stream kontseptsiooni nimega Consumer Group. See kontseptsioon sarnaneb pseudoabonendiga, kes saab voost andmeid, kuid tegelikult teenindab teda mitu grupi tellijat, pakkudes teatud garantiisid:

Iga sõnum toimetatakse rühmas erinevale abonendile.
Grupi sees tuvastatakse abonendid nende nime järgi, mis on tõstutundlik string. Kui tellija ajutiselt grupist välja langeb, saab ta gruppi taastada, kasutades tema enda unikaalset nime.
Iga tarbijagrupp järgib "esimese lugemata sõnumi" kontseptsiooni. Kui tellija taotleb uusi sõnumeid, saab ta vastu võtta ainult sõnumeid, mida pole kunagi varem ühelegi grupi abonendile edastatud.
Seal on käsk, mis kinnitab selgesõnaliselt, et tellija on sõnumi edukalt töödelnud. Kuni selle käsu kutsumiseni jääb taotletud teade olekusse "ootel".
Tarbijagrupis saab iga tellija taotleda talle saadetud, kuid veel töötlemata sõnumite ajalugu (olekus "ootel").

Mõnes mõttes saab rühma seisundit väljendada 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 tarbijagrupi peamiste käskudega, nimelt:

XGROUP kasutatakse rühmade loomiseks, hävitamiseks ja haldamiseks
XREADGROUP kasutatakse grupi kaudu voo lugemiseks
XACK - see käsk võimaldab tellijal märkida sõnumi edukalt töödeldud

Tarbijagrupi loomine

Oletame, et mystream on juba olemas. Seejärel näeb rühma loomise käsk välja selline:

> XGROUP CREATE mystream mygroup $ OK
Grupi loomisel peame edastama identifikaatori, millest alates hakkab grupp sõnumeid vastu võtma. Kui tahame lihtsalt kõiki uusi sõnumeid vastu võtta, saame kasutada spetsiaalset identifikaatorit $ (nagu meie ülaltoodud näites). Kui määrate spetsiaalse identifikaatori asemel 0, on kõik lõimes olevad sõnumid rühmale kättesaadavad.

Nüüd, kui grupp on loodud, saame käsu abil kohe sõnumeid lugema hakata XREADGROUP. See käsk on väga sarnane XLOE ja toetab valikulist BLOCK valikut. Siiski on nõutav suvand GROUP, mis tuleb alati määrata kahe argumendiga: rühma nimi ja abonendi nimi. Toetatakse ka valikut COUNT.

Enne lõime 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

Proovime nüüd seda voogu rühma kaudu lugeda:

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

Ülaltoodud käsk loetakse sõna-sõnalt järgmiselt:

"Mina, tellija Alice, minu grupi liige, tahan lugeda üht sõnumit oma voost, mida pole kunagi varem kellelegi edastatud."

Iga kord, kui abonent sooritab grupiga toimingu, peab ta esitama oma nime, identifitseerides end grupis unikaalselt. Ülaltoodud käsus on veel üks väga oluline detail - spetsiaalne identifikaator ">". See spetsiaalne identifikaator filtreerib sõnumid, jättes alles ainult need, mida pole kunagi varem edastatud.

Samuti saate erijuhtudel määrata tegeliku identifikaatori, näiteks 0 või mõne muu kehtiva identifikaatori. Sel juhul käsk XREADGROUP tagastab teile "ootel" olekuga sõnumite ajaloo, mis saadeti määratud abonendile (Alice), kuid mida ei ole veel käsuga kinnitatud XACK.

Saame seda käitumist testida, määrates kohe ID 0, ilma selle valikuta COUNT. Näeme lihtsalt ühte ootel sõnumit, see tähendab Apple'i sõnumit:

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

Kui aga kinnitame, et teade on edukalt töödeldud, siis seda enam ei kuvata:

> XACK mystream mygroup 1526569495631-0
(integer) 1
> XREADGROUP GROUP mygroup Alice STREAMS mystream 0
1) 1) "mystream"
   2) (empty list or set)

Nüüd on Bobi kord midagi lugeda:

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

Minu grupi liige Bob palus mitte rohkem kui kahte sõnumit. Käsk teatab ainult eriidentifikaatori ">" tõttu edastamata sõnumitest. Nagu näete, teadet "õun" ei kuvata, kuna see on juba Alice'ile toimetatud, nii et Bob saab "apelsini" ja "maasika".

Nii saavad Alice, Bob ja kõik teised grupi tellijad lugeda samast voost erinevaid sõnumeid. Samuti saavad nad lugeda oma töötlemata sõnumite ajalugu või märkida sõnumeid töödelduks.

Tasub meeles pidada mõnda asja.

Niipea, kui tellija peab sõnumit käsuks XREADGROUP, läheb see teade ootelolekusse ja määratakse sellele konkreetsele abonendile. Teised grupi tellijad ei saa seda sõnumit lugeda.
Tellijad luuakse automaatselt esmamainimisel, neid pole vaja otseselt luua.
Koos XREADGROUP saate korraga lugeda sõnumeid mitmest erinevast lõimest, kuid selle toimimiseks peate esmalt looma iga lõime jaoks sama nimega rühmad, kasutades XGROUP

Taastumine pärast ebaõnnestumist

Tellija saab tõrkest taastuda ja uuesti lugeda oma sõnumite loendit ootelolekuga. Reaalses maailmas võivad tellijad aga lõpuks ebaõnnestuda. Mis juhtub abonendi kinni jäänud sõnumitega, kui tellija ei suuda tõrkest taastuda?
Consumer Group pakub funktsiooni, mida kasutatakse just sellisteks puhkudeks – kui on vaja vahetada sõnumite omanikku.

Esimene asi, mida peate tegema, on käsu kutsumine EXENDING, mis kuvab kõik rühmas olevad sõnumid olekuga "ootel". Kõige lihtsamal kujul kutsutakse käsku ainult kahe argumendiga: lõime nimi ja rühma nimi:

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

Meeskond kuvas töötlemata sõnumite arvu kogu rühma ja iga tellija kohta. Meil on Bobil ainult kaks lahendamata sõnumit, sest ainus sõnum, mida Alice taotles, kinnitati XACK.

Saame küsida lisateavet, kasutades rohkem argumente:

XPENDING {key} {groupname} [{start-id} {end-id} {count} [{consumer-name}]]
{start-id} {end-id} – identifikaatorite vahemik (võite kasutada "-" ja "+")
{count} — tarnekatsete 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 üksikasjad: ID, abonendi nimi, jõudeaeg millisekundites ja lõpuks kohaletoimetamiskatsete arv. Meil on Bobilt kaks sõnumit ja need on seisnud jõude 74170458 millisekundit ehk umbes 20 tundi.

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

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

Peame lihtsalt argumentides kordama sama identifikaatorit kaks korda. Nüüd, kui meil on aimu, võib Alice otsustada, et pärast 20-tunnist seisakut Bob tõenäoliselt ei taastu ja on aeg nende sõnumite kohta päring teha ja Bobi jaoks nende töötlemist jätkata. Selleks kasutame käsku XCLAIM:

XCLAIM {key} {group} {consumer} {min-idle-time} {ID-1} {ID-2} ... {ID-N}
Seda käsku kasutades võime saada „võõra” sõnumi, mida pole veel töödeldud, muutes omanikuks {consumer}. Siiski saame pakkuda ka minimaalse tühikäiguaja {min-idle-time}. See aitab vältida olukorda, kus kaks klienti üritavad samaaegselt samade kirjade omanikku vahetada:

Client 1: XCLAIM mystream mygroup Alice 3600000 1526569498055-0 Clinet 2: XCLAIM mystream mygroup Lora 3600000 1526569498055-0
Esimene klient nullib seisakuaja ja suurendab tarneloendurit. Seega ei saa teine klient seda taotleda.

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

Alice võttis sõnumi edukalt vastu, saab nüüd sõnumit töödelda ja seda kinnitada.

Ülaltoodud näitest näete, et edukas päring tagastab sõnumi sisu. See pole aga vajalik. Suvandit JUSTID saab kasutada ainult sõnumite ID-de tagastamiseks. See on kasulik, kui te ei ole huvitatud sõnumi üksikasjadest ja soovite süsteemi jõudlust suurendada.

Kohaletoimetamise loendur

Loendur, mida näete väljundis EXENDING on iga sõnumi kohaletoimetamise arv. Sellist loendurit suurendatakse kahel viisil: kui sõnumit päritakse edukalt XCLAIM või kui kasutatakse kõnet XREADGROUP.

On normaalne, et mõned sõnumid edastatakse mitu korda. Peaasi, et kõik sõnumid lõpuks töödeldakse. Mõnikord ilmnevad probleemid sõnumi töötlemisel, kuna sõnum ise on rikutud või põhjustab sõnumi töötlemine tõrke töötleja koodis. Sel juhul võib selguda, et keegi ei saa seda sõnumit töödelda. Kuna meil on tarnekatsete loendur, saame seda loendurit selliste olukordade tuvastamiseks kasutada. Seega, kui tarnete arv jõuab teie määratud kõrgele numbrile, oleks ilmselt targem panna selline teade mõnele teisele lõimele ja saata teade süsteemiadministraatorile.

Lõime olek

Meeskond XINFO kasutatakse lõime ja selle rühmade kohta mitmesuguse teabe küsimiseks. Näiteks näeb põhikäsk välja selline:

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

Ülaltoodud käsk kuvab üldist teavet määratud voo kohta. Nüüd veidi keerulisem näide:

> XINFO GROUPS mystream
1) 1) name
   2) "mygroup"
   3) consumers
   4) (integer) 2
   5) pending
   6) (integer) 2
2) 1) name
   2) "some-other-group"
   3) consumers
   4) (integer) 1
   5) pending
   6) (integer) 0

Ülaltoodud käsk kuvab üldist teavet määratud lõime kõigi rühmade kohta

> XINFO CONSUMERS mystream mygroup
1) 1) name
   2) "Alice"
   3) pending
   4) (integer) 1
   5) idle
   6) (integer) 9104628
2) 1) name
   2) "Bob"
   3) pending
   4) (integer) 1
   5) idle
   6) (integer) 83841983

Ülaltoodud käsk kuvab teabe kõigi määratud voo ja rühma tellijate kohta.
Kui unustate käsu süntaksi, küsige abi lihtsalt käsult endalt:

> XINFO HELP
1) XINFO {subcommand} arg arg ... arg. Subcommands are:
2) CONSUMERS {key} {groupname}  -- Show consumer groups of group {groupname}.
3) GROUPS {key}                 -- Show the stream consumer groups.
4) STREAM {key}                 -- Show information about the stream.
5) HELP                         -- Print this help.

Voo suuruse piirang

Paljud rakendused ei soovi igavesti andmeid voogu koguda. Sageli on kasulik, kui lõime kohta on lubatud maksimaalne arv sõnumeid. Muudel juhtudel on kasulik kõik sõnumid lõimest teise püsivasse poodi teisaldada, kui määratud lõime suurus on saavutatud. Saate piirata voo suurust, kasutades käsus olevat parameetrit MAXLEN 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"

MAXLENi kasutamisel kustutatakse vanad kirjed automaatselt, kui need saavutavad määratud pikkuse, nii et voo suurus on konstantne. Kärpimine ei toimu sel juhul aga Redise mälus kõige tõhusamal viisil. Saate olukorda parandada järgmiselt:

XADD mystream MAXLEN ~ 1000 * ... entry fields here ...
Argument ~ ülaltoodud näites tähendab, et me ei pea tingimata piirama voo pikkust konkreetse väärtusega. Meie näites võib see olla mis tahes arv, mis on suurem või võrdne 1000-ga (näiteks 1000, 1010 või 1030). Täpsustasime just selgesõnaliselt, et tahame, et meie voog salvestaks vähemalt 1000 kirjet. See muudab mäluhalduse Redises palju tõhusamaks.

Samuti on eraldi meeskond XTRIM, mis teeb sama:

> XTRIM mystream MAXLEN 10

> XTRIM mystream MAXLEN ~ 10

Püsiv salvestamine ja paljundamine

Redis Stream kopeeritakse asünkroonselt alamsõlmedesse ja salvestatakse sellistesse failidesse nagu AOF (kõikide andmete hetktõmmis) ja RDB (kõigi kirjutamistoimingute logi). Toetatud on ka tarbijarühmade oleku replikatsioon. Seega, kui sõnum on ülemsõlmes olekus "ootel", siis alamsõlmedes on sellel sõnumil sama olek.

Üksikute elementide eemaldamine voost

Sõnumite kustutamiseks on spetsiaalne käsk XDEL. Käsk saab lõime nime, millele järgneb kustutatava sõnumi ID:

> 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 kasutamisel peate arvestama, et tegelik mälu ei vabastata kohe.

Nullpikkusega ojad

Voogude erinevus muudest Redise andmestruktuuridest seisneb selles, et kui teistes andmestruktuurides enam elemente ei ole, siis kõrvalmõjuna eemaldatakse andmestruktuur ise mälust. Näiteks eemaldatakse sorteeritud komplekt täielikult, kui ZREM-kõne eemaldab viimase elemendi. Selle asemel lubatakse lõimedel mällu jääda isegi ilma elementideta.

Järeldus

Redis Stream sobib ideaalselt sõnumivahendajate, sõnumijärjekordade, ühtse logimise ja ajalugu säilitavate vestlussüsteemide loomiseks.

Nagu ma kunagi ütlesin Niklaus Wirth, programmid on algoritmid pluss andmestruktuurid ja Redis annab teile juba mõlemad.

Allikas: www.habr.com

Redis Stream – teie sõnumsidesüsteemide töökindlus ja mastaapsus