Redis Stream 5.0 bertsioarekin Redis-en sartutako datu-mota abstraktu berria da
Kontzeptuki, Redis Stream sarrerak gehi ditzakezun zerrenda bat da. Sarrera bakoitzak identifikatzaile bakarra du. Lehenespenez, IDa automatikoki sortzen da eta denbora-zigilua du. Hori dela eta, denboran zehar erregistro-barrutiak kontsulta ditzakezu edo korrontean iristen diren heinean datu berriak jaso ditzakezu, Unix-en "tail -f" komandoak erregistro fitxategi bat irakurtzen duen eta datu berrien zain gelditzen den bezala. Kontuan izan hainbat bezerok hari bat aldi berean entzun dezaketela, "buztan -f" prozesu askok fitxategi bat aldi berean irakur dezaketela elkarren artean gatazkarik izan gabe.

Datu mota berriaren onura guztiak ulertzeko, ikus ditzagun Redis Stream-en funtzionaltasuna partzialki errepikatzen duten aspaldiko Redis egiturei.

Redis PUB/SUB

Redis Pub/Sub zure gako-balioen biltegian dagoeneko integratutako mezularitza-sistema sinplea da. Hala ere, sinpletasunak kostu bat du:

Argitaletxeak arrazoiren batengatik huts egiten badu, harpidedun guztiak galtzen ditu
Argitaletxeak bere harpidedun guztien helbide zehatza jakin behar du
Argitaletxe batek bere harpidedunak lanez gainkarga ditzake datuak prozesatzen baino azkarrago argitaratzen badira
Mezua argitaratzailearen bufferetik ezabatzen da argitaratu eta berehala, zenbat harpidedunei bidali zaien eta mezu hau zenbat azkar prozesatu ahal izan duten kontuan hartu gabe.
Harpidedun guztiek aldi berean jasoko dute mezua. Harpidedunek beren artean adostu behar dute nolabait mezu bera prozesatzeko ordena.
Ez dago barne-mekanismorik harpidedun batek mezu bat behar bezala prozesatu duela baieztatzeko. Harpidedun batek mezu bat jasotzen badu eta prozesatzean huts egiten badu, argitaletxeak ez du horren berri izango.

Redis Zerrenda

Redis List irakurtzeko komandoak blokeatzea onartzen duen datu-egitura bat da. Mezuak gehitu eta irakur ditzakezu zerrendaren hasieratik edo amaieratik. Egitura horretan oinarrituta, pila edo ilara on bat egin dezakezu zure sistema banaturako, eta kasu gehienetan nahikoa izango da. Redis Pub/Sub-en desberdintasun nagusiak:

Mezua bezero bati bidaltzen zaio. Irakurtzeko blokeatutako lehen bezeroak datuak jasoko ditu lehenik.
Clintek berak hasi behar du mezu bakoitzaren irakurketa eragiketa. Zerrendak ez daki ezer bezeroei buruz.
Mezuak gordetzen dira norbaitek irakurri edo esplizituki ezabatzen dituen arte. Redis zerbitzaria datuak diskora garbitzeko konfiguratzen baduzu, sistemaren fidagarritasuna nabarmen handitzen da.

Stream-en sarrera

Korronte bati sarrera bat gehitzea

Team XADD sarrera berri bat gehitzen du korrontean. Erregistro bat ez da kate bat soilik, gako-balio bikote batek edo gehiagok osatzen dute. Horrela, sarrera bakoitza dagoeneko egituratuta dago eta CSV fitxategi baten egituraren antza du.

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

Goiko adibidean, bi eremu gehitzen dizkiogu korrontean "mystream" izena (gakoa): "sensor-id" eta "tenperatura" "1234" eta "19.8" balioekin, hurrenez hurren. Bigarren argumentu gisa, komandoak sarrerari esleituko zaion identifikatzaile bat hartzen du - identifikatzaile honek korronteko sarrera bakoitza identifikatzen du modu esklusiboan. Hala ere, kasu honetan * gainditu dugu Redis-ek ID berri bat sortzea nahi dugulako. NAN berri bakoitza handitu egingo da. Beraz, sarrera berri bakoitzak identifikatzaile handiagoa izango du aurreko sarrerekin alderatuta.

Identifikatzailearen formatua

Komandoak itzultzen duen sarrera IDa XADD, bi zati ditu:

{millisecondsTime}-{sequenceNumber}
milisegundoakDenbora — Unix denbora milisegundotan (Redis zerbitzariaren denbora). Hala ere, uneko ordua aurreko grabazioaren ordua bera edo txikiagoa bada, aurreko grabazioaren denbora-zigilua erabiliko da. Beraz, zerbitzariaren denbora denboran atzera egiten badu, identifikatzaile berriak gehikuntzaren propietatea mantenduko du.

sequenceNumber milisegundo berean sortutako erregistroetarako erabiltzen da. sequenceNumber 1 gehituko da aurreko sarreraren aldean. Zeren sequenceNumber 64 biteko tamaina du, orduan praktikan ez zenuke milisegundo batean sor daitezkeen erregistro-kopuruaren mugarik topatu behar.

Horrelako identifikatzaileen formatuak arraroa dirudi lehen begiratuan. Irakurle mesfidati batek galdetuko luke zergatik den denbora identifikatzailearen parte. Arrazoia da Redis korronteek IDaren araberako barrutiaren kontsultak onartzen dituztela. Identifikatzailea erregistroa sortu zen denborarekin lotuta dagoenez, honek denbora tarteak kontsultatzeko aukera ematen du. Adibide zehatz bat ikusiko dugu komandoa aztertzen dugunean X SORTEIA.

Arrazoiren batengatik erabiltzaileak bere identifikatzailea zehaztu behar badu, adibidez, kanpoko sistemaren batekin lotuta dagoena, komandoari pasa diezaiokegu. XADD *-ren ordez behean erakusten den moduan:

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

Kontuan izan kasu honetan nortasun agiriaren gehikuntza zuk zeuk kontrolatu behar duzula. Gure adibidean, gutxieneko identifikatzailea "0-1" da, beraz komandoak ez du onartuko "0-1"ren berdina edo txikiagoa den beste identifikatzaile bat.

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

Korronte bakoitzeko erregistro kopurua

Korronte bateko erregistro kopurua lortu daiteke komandoa erabiliz XLEN. Gure adibiderako, komando honek balio hau itzuliko du:

> XLEN somestream
(integer) 2

Barrutiko kontsultak - XRANGE eta XREVRANGE

Datuak barrutiaren arabera eskatzeko, bi identifikatzaile zehaztu behar ditugu: barrutiaren hasiera eta amaiera. Itzulitako barrutiak elementu guztiak barne hartuko ditu, mugak barne. "-" eta "+" bi identifikatzaile berezi ere badaude, hurrenez hurren, korrontearen identifikatzaile txikiena (lehen erregistroa) eta handiena (azken erregistroa) esan nahi du. Beheko adibidean korronte-sarrera guztiak zerrendatuko dira.

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

Itzulitako erregistro bakoitza bi elementuz osatutako array bat da: identifikatzaile bat eta gako-balio bikoteen zerrenda. Lehen esan dugu erregistro-identifikatzaileak denborarekin erlazionatuta daudela. Hori dela eta, epe jakin bateko tartea eska dezakegu. Hala ere, eskaeran zehaztu dezakegu ez identifikatzaile osoa, baizik eta Unix-en ordua soilik, eta horrekin erlazionatutako zatia kenduta. sequenceNumber. Identifikatzailearen zati baztertua automatikoki zeroan ezarriko da barrutiaren hasieran eta ahalik eta balio maximoan tartearen amaieran. Jarraian, bi milisegundoko tartea eska dezakezun adibide bat dago.

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

Barruti honetan sarrera bakarra dugu, baina benetako datu multzoetan itzultzen den emaitza handia izan daiteke. Horregatik X SORTEIA COUNT aukera onartzen du. Kantitatea zehaztuz, lehen N erregistroak besterik gabe lor ditzakegu. Hurrengo N erregistroak (paginazioa) lortu behar baditugu, jasotako azken IDa erabil dezakegu, handitu sequenceNumber batek eta berriro galdetu. Ikus dezagun hurrengo adibidean. 10 elementu gehitzen hasten gara XADD (mystream dagoeneko 10 elementuz beteta zegoela suposatuz). Iterazioa komando bakoitzeko 2 elementu lortzen hasteko, barruti osoarekin hasiko gara baina COUNT 2ren berdinarekin.

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

Hurrengo bi elementuekin errepikatzen jarraitzeko, jasotako azken IDa hautatu behar dugu, hau da, 1519073279157-0, eta 1 gehitu. sequenceNumber.
Sortutako IDa, kasu honetan 1519073279157-1, hurrengo deirako barrutiaren hasierako argumentu berri gisa erabil daiteke. X SORTEIA:

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

Eta abar. Konplexutasuna delako X SORTEIA O(log(N)) da bilatzeko eta gero O(M) M elementuak itzultzeko, orduan iterazio-urrats bakoitza azkarra da. Horrela, erabiliz X SORTEIA korronteak modu eraginkorrean errepika daitezke.

Team XREBRANGE baliokidea da X SORTEIA, baina elementuak alderantzizko ordenan itzultzen ditu:

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

Kontuan izan komandoa XREBRANGE barrutiaren argumentuak alderantzizko ordenan hasten eta gelditzen ditu.

XREAD erabiliz sarrera berriak irakurtzea

Askotan korronte batera harpidetu eta mezu berriak soilik jasotzea sortzen da. Kontzeptu honek Redis Pub/Sub-en edo Redis List blokeatzearen antzekoa izan daiteke, baina Redis Stream erabiltzeko oinarrizko desberdintasunak daude:

Mezu berri bakoitza harpidedun guztiei bidaltzen zaie lehenespenez. Jokaera hau Redis Zerrenda blokeatzaile baten desberdina da, non mezu berri bat harpidedun batek bakarrik irakurriko duen.
Redis Pub/Sub-en mezu guztiak ahazten diren bitartean eta ez dira inoiz iraungo, Stream-en mezu guztiak mugagabean gordetzen dira (bezeroak esplizituki ezabatzen ez badu).
Redis Stream-ek korronte batean mezuetarako sarbidea bereizteko aukera ematen du. Harpidedun jakin batek bere mezuen historia pertsonala soilik ikus dezake.

Komandoa erabiliz hari batera harpidetu eta mezu berriak jaso ditzakezu XIRAKURRI. baino apur bat konplikatuagoa da X SORTEIA, beraz, adibide sinpleagoekin hasiko gara lehenik.

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

Goiko adibidean blokeatzen ez den forma bat erakusten da XIRAKURRI. Kontuan izan ZENBATU aukera hautazkoa dela. Izan ere, beharrezkoa den komando-aukera bakarra STREAMS aukera da, korronteen zerrenda bat zehazten baitu dagokion identifikatzaile maximoarekin batera. "STREAMS mystream 0" idatzi dugu: "0-0" baino identifikatzaile handiagoa duten mystream korrontearen erregistro guztiak jaso nahi ditugu. Adibidean ikus dezakezun bezala, komandoak hariaren izena itzultzen du, aldi berean hainbat hari harpidetu gaitezkeelako. Idatz genezake, adibidez, "SREAMS mystream otherstream 0 0". Kontuan izan STREAM aukeraren ondoren beharrezko korronte guztien izenak eman behar ditugula lehenik eta ondoren identifikatzaileen zerrenda.

Forma sinple honetan komandoak ez du ezer berezirik egiten X SORTEIA. Hala ere, interesgarria da erraz buelta gaitezkeela XIRAKURRI blokeatzeko komando batera, BLOCK argumentua zehaztuz:

> XREAD BLOCK 0 STREAMS mystream $
Goiko adibidean, BLOKEA aukera berri bat zehazten da 0 milisegundoko denbora-muga batekin (horrek mugarik gabe itxarotea esan nahi du). Gainera, mystream korronterako ohiko identifikatzailea pasatu beharrean, $ identifikatzaile berezi bat pasatu zen. Identifikatzaile berezi honek esan nahi du XIRAKURRI mystream-en gehienezko identifikatzailea erabili behar du identifikatzaile gisa. Beraz, entzuten hasi garen unetik hasita soilik jasoko ditugu mezu berriak. Nolabait, hau Unix-en "tail -f" komandoaren antzekoa da.

Kontuan izan BLOKEA aukera erabiltzean ez dugula zertan $ identifikatzaile berezia erabili behar. Korrontean dagoen edozein identifikatzaile erabil dezakegu. Taldeak berehala gure eskaera blokeatu gabe artatu badezake, hala egingo du, bestela blokeatu egingo du.

Blokeatzea XIRAKURRI hainbat hari aldi berean entzun ditzakete, haien izenak zehaztu besterik ez duzu behar. Kasu honetan, komandoak datuak jaso dituen lehen korrontearen erregistroa itzuliko du. Hari jakin baterako blokeatutako lehen harpidedunak datuak jasoko ditu lehenik.

Kontsumo Taldeak

Zeregin jakin batzuetan, harpidedunen sarbidea mugatu nahi dugu hari bakarreko mezuetara. Hau erabilgarria izan daitekeen adibide bat hari batetik mezu desberdinak jasoko dituzten langileekin mezu-ilara bat da, mezuen prozesamendua eskalatzeko aukera emanez.

Irudikatzen badugu hiru harpidedun C1, C2, C3 eta 1, 2, 3, 4, 5, 6, 7 mezuak dituen hari bat ditugula, orduan mezuak beheko diagraman bezala zerbitzatuko dira:

1 -> C1 2 -> C2 3 -> C3 4 -> C1 5 -> C2 6 -> C3 7 -> C1
Efektu hori lortzeko, Redis Stream-ek Consumer Group izeneko kontzeptua erabiltzen du. Kontzeptu hau sasi-harpidedun baten antzekoa da, korronte batetik datuak jasotzen dituena, baina talde bateko harpidedun anitzek hornitzen dute, berme batzuk emanez:

Mezu bakoitza taldeko harpidedun ezberdin bati bidaltzen zaio.
Talde baten barruan, harpidedunak beren izenarekin identifikatzen dira, hau da, maiuskulak eta minuskulak bereizten dituen kate bat da. Harpidedun bat aldi baterako taldetik kanpo uzten bada, taldera itzul daiteke bere izen esklusiboa erabiliz.
Kontsumo Talde bakoitzak "irakurturiko lehen mezua" kontzeptua jarraitzen du. Harpidedun batek mezu berriak eskatzen dituenean, aldez aurretik inoiz bidali ez diren mezuak soilik jaso ditzake taldeko edozein harpidedun.
Harpidedunak mezua behar bezala prozesatu duela berresteko komando bat dago. Komando hau deitu arte, eskatutako mezuak "zain" egoeran jarraituko du.
Kontsumo Taldearen barruan, harpidedun bakoitzak bidalitako mezuen historia eska dezake, baina oraindik prozesatu ez diren («zain» egoeran)

Zentzu batean, taldearen egoera honela adieraz daiteke:

+----------------------------------------+
| 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)                             
+----------------------------------------+

Orain Kontsumo Taldearen komando nagusiak ezagutzeko garaia da, hau da:

XGROUP taldeak sortzeko, suntsitzeko eta kudeatzeko erabiltzen da
XREADGROUP korrontea taldean irakurtzeko erabiltzen da
XACK - Komando honek harpidedunari mezua behar bezala prozesatu gisa markatzeko aukera ematen dio

Kontsumo Taldea sortzea

Demagun mystream dagoeneko existitzen dela. Ondoren, taldeak sortzeko komandoak itxura izango du:

> XGROUP CREATE mystream mygroup $ OK
Talde bat sortzerakoan identifikatzaile bat pasatu behar dugu, eta bertatik taldeak mezuak jasoko ditu. Mezu berri guztiak jaso nahi baditugu, $ identifikatzaile berezia erabil dezakegu (goiko adibidean bezala). Identifikatzaile berezi baten ordez 0 zehazten baduzu, hariko mezu guztiak taldearentzat eskuragarri egongo dira.

Orain taldea sortuta, berehala has gaitezke mezuak irakurtzen komandoa erabiliz XREADGROUP. Komando hau oso antzekoa da XIRAKURRI eta aukerako BLOKEA aukera onartzen du. Hala ere, beharrezkoa da TALDE aukera bat, beti bi argumenturekin zehaztu behar dena: taldearen izena eta harpidedunaren izena. COUNT aukera ere onartzen da.

Haria irakurri aurretik, jar ditzagun mezu batzuk bertan:

> 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

Orain saia gaitezen korronte hau taldean irakurtzen:

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

Goiko komandoak hitzez hitz honela irakurtzen du:

"Nik, Alice harpideduna, nire taldeko kidea, nire korronteko mezu bat irakurri nahi dut orain arte inori bidali ez zaiona".

Harpidedun batek talde bati eragiketa bat egiten dion bakoitzean, bere izena eman behar du, taldean bere burua modu esklusiboan identifikatuz. Goiko komandoan xehetasun oso garrantzitsu bat dago: ">" identifikatzaile berezia. Identifikatzaile berezi honek mezuak iragazten ditu, inoiz entregatu ez direnak soilik utziz.

Gainera, kasu berezietan, benetako identifikatzaile bat zehaztu dezakezu, hala nola 0 edo baliozko beste edozein identifikatzaile. Kasu honetan komandoa XREADGROUP "zain" egoera duten mezuen historia itzuliko dizu, zehaztutako harpidedunari (Alice) entregatu zaizkion baina oraindik komandoa erabiliz onartu ez direnak. XACK.

Portaera hori probatu dezakegu berehala ID 0 zehaztuz, aukerarik gabe COUNT. Besterik gabe, zain dagoen mezu bakarra ikusiko dugu, hau da, sagar mezua:

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

Hala ere, mezua behar bezala prozesatu dela baieztatzen badugu, ez da gehiago bistaratuko:

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

Orain Boben txanda da zerbait irakurtzeko:

> 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 nire taldeko kideak bi mezu baino gehiago eskatu zituen. Komandoak bidali gabeko mezuen berri ematen du ">" identifikatzaile berezia dela eta. Ikus dezakezunez, "sagarra" mezua ez da agertuko Aliziari dagoeneko entregatu zaiolako, beraz, Bobek "laranja" eta "marrubia" jasotzen ditu.

Horrela, Alicek, Bobek eta taldeko beste edozein harpidedunek korronte bereko mezu desberdinak irakur ditzakete. Halaber, prozesatu gabeko mezuen historia irakur dezakete edo prozesatu gisa markatu ditzakete mezuak.

Kontuan izan beharreko gauza batzuk daude:

Harpidedunak mezua komandotzat hartzen duen bezain laster XREADGROUP, mezu hau "zain" egoerara doa eta harpidedun zehatz horri esleitzen zaio. Beste taldeko harpidedunek ezin izango dute mezu hau irakurri.
Harpidedunak automatikoki sortzen dira lehenengo aipamenean, ez dago esplizituki sortu beharrik.
With XREADGROUP Hainbat hari ezberdinetako mezuak aldi berean irakur ditzakezu; hala ere, honek funtziona dezan, lehenik eta behin hari bakoitzarentzat izen bereko taldeak sortu behar dituzu erabiliz. XGROUP

Porrot baten ondoren berreskuratzea

Harpidedunak hutsegitetik berreskuratu eta bere mezu-zerrenda berriro irakurri dezake "zain" egoerarekin. Hala ere, mundu errealean, harpidedunek azkenean huts egin dezakete. Zer gertatzen da harpidedun baten mezu itsatsiekin harpideduna ezin bada hutsegite batetik berreskuratu?
Consumer Group-ek horrelako kasuetarako erabiltzen den funtzio bat eskaintzen du, mezuen jabea aldatu behar duzunean.

Egin behar duzun lehenengo gauza komandoari deitzea da XPENDIENDUA, "zain" egoera duten taldeko mezu guztiak bistaratzen dituena. Bere forma sinpleenean, komandoa bi argumenturekin soilik deitzen da: hariaren izena eta taldearen izena:

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

Taldeak prozesatu gabeko mezu kopurua erakutsi zuen talde osoarentzat eta harpidedun bakoitzeko. Bi mezu nabarmenekin bakarrik ditugu Bob, Alicek eskatutako mezu bakarrarekin baieztatu delako XACK.

Informazio gehiago eska dezakegu argudio gehiago erabiliz:

XPENDING {key} {groupname} [{start-id} {end-id} {count} [{consumer-name}]]
{start-id} {end-id} - identifikatzaile sorta (“-” eta “+ erabil ditzakezu”)
{count} — entrega saiakera kopurua
{consumer-name} - taldearen izena

> 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

Orain mezu bakoitzaren xehetasunak ditugu: ID, harpidedunaren izena, inakzio-denbora milisegundotan eta azkenik entrega-saiakera kopurua. Bob-en bi mezu ditugu eta 74170458 milisegundo egon dira inaktibo, 20 ordu inguru.

Kontuan izan inork ez gaituela eragozten mezuaren edukia zer den egiaztatzea besterik gabe erabiliz X SORTEIA.

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

Identifikatzaile bera bi aldiz errepikatu besterik ez dugu egin behar argumentuetan. Ideia bat badugula, Alicek erabaki dezake 20 ordu geldirik egon ondoren, Bob ziurrenik ez dela berreskuratuko, eta mezu horiek kontsultatzeko eta Bobentzat prozesatzen hasteko garaia da. Horretarako komandoa erabiltzen dugu XERREKLAMAZIOA:

XCLAIM {key} {group} {consumer} {min-idle-time} {ID-1} {ID-2} ... {ID-N}
Komando hau erabiliz, oraindik prozesatu ez den "atzerriko" mezu bat jaso dezakegu jabea {consumer} bihurtuz. Hala ere, {min-idle-time} gutxieneko denbora bat ere eman dezakegu. Horrek bi bezero mezu berdinen jabea aldi berean aldatzen saiatzen diren egoera saihesten du:

Client 1: XCLAIM mystream mygroup Alice 3600000 1526569498055-0 Clinet 2: XCLAIM mystream mygroup Lora 3600000 1526569498055-0
Lehen bezeroak geldialdi-denbora berrezarri eta bidalketen kontagailua handituko du. Beraz, bigarren bezeroak ezin izango du eskatu.

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

Mezua behar bezala erreklamatu du Alicek, eta orain mezua prozesatu eta onartu egin dezake.

Goiko adibidetik, eskaera arrakastatsu batek mezuaren edukia bera itzultzen duela ikus dezakezu. Hala ere, hau ez da beharrezkoa. JUSTID aukera mezuen IDak soilik itzultzeko erabil daiteke. Hau erabilgarria da mezuaren xehetasunak interesatzen ez bazaizu eta sistemaren errendimendua areagotu nahi baduzu.

Entrega-kontagailua

Irteeran ikusten duzun kontagailua XPENDIENDUA mezu bakoitzaren bidalketa kopurua da. Horrelako kontagailu bat bi modutan gehitzen da: mezu bat behar bezala eskatzen denean XERREKLAMAZIOA edo dei bat erabiltzen denean XREADGROUP.

Normala da mezu batzuk hainbat aldiz bidaltzea. Gauza nagusia mezu guztiak azkenean prozesatzen direla da. Batzuetan, arazoak sortzen dira mezu bat prozesatzen denean, mezua bera hondatuta dagoelako, edo mezuen prozesamenduak kudeatzailearen kodean errore bat eragiten duelako. Kasu honetan, gerta daiteke inork ezingo duela mezu hau prozesatu. Bidalketa saiakeraren kontagailua dugunez, kontagailu hau erabil dezakegu horrelako egoerak detektatzeko. Hori dela eta, bidalketa-zenbaketa zuk zehazten duzun kopuru altuera iristen denean, seguruenik jakintsuagoa izango litzateke horrelako mezu bat beste hari batean jartzea eta jakinarazpen bat bidaltzea sistemaren administratzaileari.

Hariaren egoera

Team XINFO hari bati eta bere taldeei buruzko hainbat informazio eskatzeko erabiltzen da. Adibidez, oinarrizko komando bat honelakoa da:

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

Goiko komandoak zehaztutako korronteari buruzko informazio orokorra erakusten du. Orain adibide apur bat konplexuagoa:

> 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

Goiko komandoak zehaztutako hariaren talde guztien informazio orokorra erakusten du

> 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

Goiko komandoak zehaztutako korrontearen eta taldearen harpidedun guztien informazioa erakusten du.
Komandoaren sintaxia ahazten baduzu, eskatu laguntza komandoari berari:

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

Korrontearen tamaina muga

Aplikazio askok ez dute betirako korronte batean datuak bildu nahi. Sarritan erabilgarria da hari bakoitzeko gehienezko mezu kopurua baimenduta egotea. Beste kasu batzuetan, komeni da mezu guztiak hari batetik beste biltegi iraunkor batera eramatea zehaztutako hariaren tamainara iristen denean. Korronte baten tamaina muga dezakezu komandoko MAXLEN parametroa erabiliz 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 erabiltzean, erregistro zaharrak automatikoki ezabatzen dira zehaztutako luzerara iristen direnean, beraz korronteak tamaina konstantea du. Hala ere, kasu honetan inausketa ez da modurik eraginkorrenean gertatzen Redis memorian. Honela hobetu dezakezu egoera:

XADD mystream MAXLEN ~ 1000 * ... entry fields here ...
Goiko adibideko ~ argumentuak esan nahi du ez dugula zertan korrontearen luzera balio zehatz batera mugatu behar. Gure adibidean, hau 1000 baino handiagoa edo berdina izan daiteke (adibidez, 1000, 1010 edo 1030). Esplizituki zehaztu dugu gure korronteak gutxienez 1000 erregistro gordetzea nahi dugula. Horrek memoria kudeaketa askoz eraginkorragoa egiten du Redis-en barruan.

Talde bereizi bat ere badago XTRIM, gauza bera egiten duena:

> XTRIM mystream MAXLEN 10

> XTRIM mystream MAXLEN ~ 10

Biltegiratze eta erreplikazio iraunkorrak

Redis Stream modu asinkronoan erreplikatzen da nodo esklaboetan eta AOF (datu guztien argazkia) eta RDB (idazketa-eragiketa guztien erregistroa) bezalako fitxategietan gordetzen da. Kontsumo Taldeen egoera erreplikatzea ere onartzen da. Beraz, mezu bat nodo nagusian "zain" egoeran badago, nodo esklaboetan mezu honek egoera bera izango du.

Korronte batetik elementu indibidualak kentzea

Mezuak ezabatzeko komando berezi bat dago XDEL. Komandoak hariaren izena jasotzen du eta ondoren ezabatu beharreko mezuen IDak:

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

Komando hau erabiltzean, kontuan izan behar duzu benetako memoria ez dela berehala kaleratuko.

Zero luzera errekak

Korronteen eta beste Redis datu-egituren arteko aldea zera da: beste datu-egiturak haien barruan elementurik ez dutenean, albo-ondorio gisa, datu-egitura bera memoriatik kenduko da. Beraz, adibidez, ordenatutako multzoa guztiz kenduko da ZREM deiak azken elementua kentzen duenean. Horren ordez, hariak memorian gera daitezke barruan elementurik izan gabe ere.

Ondorioa

Redis Stream aproposa da mezu-artekariak, mezu-ilarak, erregistro bateratua eta historia mantentzeko txat-sistemak sortzeko.

Behin esan nuen bezala Niklaus Wirth, programak algoritmoak gehi datu-egiturak dira, eta Redis-ek dagoeneko biak ematen dizkizu.

Iturria: www.habr.com

Redis Stream - zure mezularitza sistemen fidagarritasuna eta eskalagarritasuna