Redis Stream is in nij abstrakt gegevenstype yntrodusearre yn Redis mei ferzje 5.0
Konseptueel is Redis Stream in list dêr't jo ynstjoerings kinne tafoegje. Elke yngong hat in unike identifier. Standert wurdt de ID automatysk oanmakke en befettet in tiidstempel. Dêrom kinne jo berikken fan records yn 'e rin fan' e tiid opfreegje, of nije gegevens ûntfange as se yn 'e stream komme, krekt lykas it Unix "tail -f" kommando in lochbestân lêst en befriest wylst jo wachtsje op nije gegevens. Tink derom dat meardere kliïnten tagelyk nei in tried harkje kinne, krekt sa't in protte "tail -f" prosessen in bestân tagelyk lêze kinne sûnder konflikt mei elkoar.
Om alle foardielen fan it nije gegevenstype te begripen, litte wy efkes sjen nei de lang besteande Redis-struktueren dy't de funksjonaliteit fan Redis Stream foar in part replikearje.
Redis PUB/SUB
Redis Pub/Sub is in ienfâldich berjochtensysteem al ynboud yn jo winkel foar kaaiwearden. De ienfâld komt lykwols foar in priis:
- As de útjouwer om ien of oare reden mislearret, dan rekket er al syn abonnees kwyt
- De útjouwer moat it krekte adres fan al syn abonnees witte
- In útjouwer kin syn abonnees oerladen mei wurk as gegevens rapper wurde publisearre dan se wurde ferwurke
- It berjocht wurdt fuort nei publikaasje fuorthelle út de buffer fan de útjouwer, nettsjinsteande hoefolle abonnees it besoarge is en hoe fluch se dit berjocht ferwurkje koenen.
- Alle abonnees krije it berjocht tagelyk. Abonnees sels moatte op ien of oare manier ûnderling iens wurde oer de folchoarder fan it ferwurkjen fan itselde berjocht.
- D'r is gjin ynboude meganisme om te befêstigjen dat in abonnee in berjocht mei súkses hat ferwurke. As in abonnee in berjocht krijt en by it ferwurkjen crasht, sil de útjouwer der net fan witte.
Redis List
Redis List is in gegevensstruktuer dy't blokkearjende lêskommando's stipet. Jo kinne berjochten tafoegje en lêze fanôf it begjin of ein fan 'e list. Op grûn fan dizze struktuer kinne jo in goede stack of wachtrige meitsje foar jo ferspraat systeem, en yn 'e measte gefallen sil dit genôch wêze. De wichtichste ferskillen fan Redis Pub/Sub:
- It berjocht wurdt levere oan ien klant. De earste lêzen-blokkeare kliïnt sil de gegevens earst ûntfange.
- Clint moat de lêsoperaasje foar elk berjocht sels begjinne. List wit neat oer kliïnten.
- Berjochten wurde opslein oant immen se lêst of eksplisyt wisket. As jo de Redis-tsjinner ynstelle om gegevens op skiif te spoelen, dan nimt de betrouberens fan it systeem dramatysk ta.
Yntroduksje ta Stream
In yngong tafoegje oan in stream
team XADD foeget in nije yngong ta oan de stream. In rekord is net allinich in tekenrige, it bestiet út ien of mear kaai-wearde-pearen. Sa is elke yngong al strukturearre en liket op de struktuer fan in CSV-bestân.
> XADD mystream * sensor-id 1234 temperature 19.8
1518951480106-0
Yn it foarbyld hjirboppe foegje wy twa fjilden ta oan de stream mei de namme (kaai) "mystream": "sensor-id" en "temperatuer" mei respektivelik de wearden "1234" en "19.8". As twadde argumint nimt it kommando in identifier dy't sil wurde tawiisd oan de yngong - dizze identifier identifisearret unyk elke yngong yn 'e stream. Yn dit gefal hawwe wy lykwols * trochjûn, om't wy wolle dat Redis in nije ID foar ús genereart. Elke nije ID sil tanimme. Dêrom sil elke nije yngong in hegere identifier hawwe yn relaasje ta eardere yngongen.
Identifikaasjeformaat
De ynfier-ID weromjûn troch it kommando XADD, bestiet út twa dielen:
{millisecondsTime}-{sequenceNumber}
millisekondenTiid - Unix-tiid yn millisekonden (Redis-tsjinnertiid). As de aktuele tiid lykwols itselde of minder is as de tiid fan 'e foarige opname, dan wurdt it tiidstempel fan 'e foarige opname brûkt. Dêrom, as de tsjinner tiid giet werom yn de tiid, de nije identifier sil noch behâlde de increment eigendom.
folchoardernûmer brûkt foar records makke yn deselde millisekonde. folchoardernûmer wurdt ferhege mei 1 relatyf oan de foarige yngong. Fanwege de folchoardernûmer is 64 bits yn grutte, dan yn 'e praktyk moatte jo net rinne yn in limyt op it oantal records dat kin wurde oanmakke binnen ien millisekonde.
It formaat fan sokke identifiers kin op it earste each nuver lykje. In wantrouwende lêzer kin him ôffreegje wêrom't tiid diel is fan 'e identifier. De reden is dat Redis-streamen berikfragen stypje troch ID. Sûnt de identifier is assosjearre mei de tiid dat it record is oanmakke, makket dit it mooglik om tiidbereiken te freegjen. Wy sille nei in spesifyk foarbyld sjen as wy nei it kommando sjogge XRANGE.
As de brûker om ien of oare reden syn eigen identifier moat opjaan, dy't bygelyks ferbûn is mei in eksterne systeem, dan kinne wy it trochjaan oan it kommando XADD ynstee fan * lykas hjirûnder werjûn:
> XADD somestream 0-1 field value
0-1
> XADD somestream 0-2 foo bar
0-2
Tink derom dat jo yn dit gefal it ID-ynkrement sels moatte kontrolearje. Yn ús foarbyld is de minimale identifier "0-1", dus it kommando sil gjin oare identifier akseptearje dy't gelyk is oan of minder as "0-1".
> XADD somestream 0-1 foo bar
(error) ERR The ID specified in XADD is equal or smaller than the target stream top item
Oantal records per stream
It is mooglik om it oantal records yn in stream te krijen gewoan troch it kommando te brûken XLEN. Foar ús foarbyld sil dit kommando de folgjende wearde werombringe:
> XLEN somestream
(integer) 2
Rangfragen - XRANGE en XREVRANGE
Om gegevens per berik oan te freegjen, moatte wy twa identifiers opjaan - it begjin en it ein fan it berik. It weromkommende berik sil alle eleminten befetsje, ynklusyf de grinzen. D'r binne ek twa spesjale identifiers "-" en "+", respektyflik de lytste (earste rekord) en grutste (lêste rekord) identifier yn 'e stream. It foarbyld hjirûnder sil alle streamyngongen listje.
> 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"
Elk weromjûn record is in array fan twa eleminten: in identifier en in list mei kaai-wearde-pearen. Wy hawwe al sein dat record identifiers binne relatearre oan tiid. Dêrom kinne wy in berik fan in spesifike perioade oanfreegje. Wy kinne lykwols yn it fersyk net de folsleine identifier oantsjutte, mar allinich de Unix-tiid, mei it weilitten fan it diel relatearre oan folchoardernûmer. It weilitten diel fan de identifier wurdt automatysk ynsteld op nul oan it begjin fan it berik en op de maksimum mooglike wearde oan 'e ein fan it berik. Hjirûnder is in foarbyld fan hoe't jo in berik fan twa millisekonden kinne oanfreegje.
> XRANGE mystream 1518951480106 1518951480107
1) 1) 1518951480106-0
2) 1) "sensor-id"
2) "1234"
3) "temperature"
4) "19.8"
Wy hawwe mar ien yngong yn dit berik, lykwols yn echte datasets kin it weromjûn resultaat enoarm wêze. Om dizze reden XRANGE stipet de opsje COUNT. Troch de kwantiteit oan te jaan, kinne wy gewoan de earste N-records krije. As wy moatte krije de folgjende N records (paginering), kinne wy brûke de lêste ûntfongen ID, fergrutsje it folchoardernûmer troch ien en freegje nochris. Litte wy dit sjen yn it folgjende foarbyld. Wy begjinne te foegjen 10 eleminten mei XADD (oannommen dat mystream al fol wie mei 10 eleminten). Om de iteraasje te begjinnen mei 2 eleminten per kommando, begjinne wy mei it folsleine berik, mar mei COUNT gelyk oan 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"
Om troch te gean mei iterearjen mei de folgjende twa eleminten, moatte wy de lêste ûntfongen ID selektearje, dus 1519073279157-0, en 1 tafoegje oan folchoardernûmer.
De resultearjende ID, yn dit gefal 1519073279157-1, kin no brûkt wurde as it nije begjin fan berik argumint foar de folgjende oprop 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"
Ensafuorthinne. Omdat kompleksiteit XRANGE is O(log(N)) om te sykjen en dan O(M) om M-eleminten werom te jaan, dan is elke iteraasjestap fluch. Sa, it brûken fan XRANGE streamen kinne effisjint iterearre wurde.
team XREVRANGE is it lykweardich XRANGE, mar jout de eleminten werom yn omkearde folchoarder:
> XREVRANGE mystream + - COUNT 1
1) 1) 1519073287312-0
2) 1) "foo"
2) "value_10"
Tink derom dat it kommando XREVRANGE nimt berik arguminten begjinne en stopje yn omkearde folchoarder.
Nije yngongen lêze mei XREAD
Faak ûntstiet de taak om jo te abonnearjen op in stream en allinich nije berjochten te ûntfangen. Dit konsept kin lykje op Redis Pub/Sub of Redis List blokkearje, mar d'r binne fûnemintele ferskillen yn hoe't jo Redis Stream brûke:
- Elk nij berjocht wurdt standert levere oan elke abonnee. Dit gedrach is oars as in blokkearjende Redis List, wêrby't in nij berjocht mar troch ien abonnee lêzen wurdt.
- Wylst yn Redis Pub/Sub alle berjochten fergetten binne en nea oanhâlde, wurde yn Stream alle berjochten foar ûnbepaalde tiid bewarre (útsein as de kliïnt eksplisyt ferwidering feroarsaket).
- Redis Stream lit jo tagong krije ta berjochten binnen ien stream. In spesifike abonnee kin allinich har persoanlike berjochtskiednis sjen.
Jo kinne jo abonnearje op in thread en nije berjochten ûntfange mei it kommando XREAD. It is in bytsje yngewikkelder dan XRANGE, dus wy sille earst begjinne mei de ienfâldiger foarbylden.
> 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"
It foarbyld hjirboppe lit in net-blokkearjende foarm sjen XREAD. Tink derom dat de opsje COUNT opsjoneel is. Yn feite is de ienige fereaske kommando-opsje de STREAMS-opsje, dy't in list mei streamen spesifisearret tegearre mei de oerienkommende maksimale identifier. Wy hawwe "STREAMS mystream 0" skreaun - wy wolle alle records fan 'e mystream-stream ûntfange mei in identifier grutter dan "0-0". Sa't jo út it foarbyld sjen kinne, jout it kommando de namme fan 'e thread werom, om't wy tagelyk kinne abonnearje op meardere threads. Wy kinne bygelyks skriuwe "STREAMS mystream otherstream 0 0". Tink derom dat wy nei de STREAMS-opsje earst de nammen fan alle fereaske streamen moatte leverje en allinich dan in list mei identifiers.
Yn dizze ienfâldige foarm docht it kommando neat spesjaal yn ferliking mei XRANGE. It nijsgjirrige is lykwols dat wy maklik kinne draaie XREAD nei in blokkearjende kommando, mei it opjaan fan it argumint BLOCK:
> XREAD BLOCK 0 STREAMS mystream $
Yn it foarbyld hjirboppe wurdt in nije BLOCK-opsje oantsjutte mei in time-out fan 0 millisekonden (dit betsjut foar ûnbepaalde tiid wachtsje). Boppedat, ynstee fan it trochjaan fan de gewoane identifier foar de stream mystream, waard in spesjale identifier $ trochjûn. Dizze spesjale identifier betsjut dat XREAD moat de maksimale identifier yn mystream brûke as de identifier. Dat wy sille allinich nije berjochten ûntfange fanôf it momint dat wy begon te harkjen. Op guon manieren is dit gelyk oan it Unix "tail -f" kommando.
Tink derom dat by it brûken fan de BLOCK-opsje wy de spesjale identifier $ net needsaaklik hoege te brûken. Wy kinne elke yn 'e stream besteande identifier brûke. As it team ús fersyk daliks tsjinje kin sûnder blokkearjen, sil it dat dwaan, oars blokkearret it.
Blocking XREAD kin ek harkje nei meardere triedden tagelyk, jo moatte gewoan har nammen opjaan. Yn dit gefal sil it kommando in rekord weromjaan fan 'e earste stream dy't gegevens ûntfongen hat. De earste abonnee blokkearre foar in opjûne thread sil earst gegevens ûntfange.
Konsumintegroepen
Yn bepaalde taken wolle wy abonnee tagong beheine ta berjochten binnen ien thread. In foarbyld wêr't dit nuttich kin wêze is in berjochtwachtrige mei arbeiders dy't ferskate berjochten sille ûntfange fan in thread, wêrtroch berjochtferwurking op skaal kin wurde.
As wy ús foarstelle dat wy trije abonnees C1, C2, C3 hawwe en in tried dy't berjochten 1, 2, 3, 4, 5, 6, 7 befettet, dan wurde de berjochten tsjinne lykas yn it diagram hjirûnder:
1 -> C1
2 -> C2
3 -> C3
4 -> C1
5 -> C2
6 -> C3
7 -> C1
Om dit effekt te berikken, brûkt Redis Stream in konsept neamd Consumer Group. Dit konsept is fergelykber mei in pseudo-abonnee, dy't gegevens ûntfangt fan in stream, mar wurdt eins betsjinne troch meardere abonnees binnen in groep, wat bepaalde garânsjes leveret:
- Elk berjocht wurdt levere oan in oare abonnee binnen de groep.
- Binnen in groep wurde abonnees identifisearre troch har namme, wat in haadlettergefoelige tekenrige is. As in abonnee tydlik út de groep falt, kin hy werombrocht wurde nei de groep mei syn eigen unike namme.
- Elke konsumintgroep folget it konsept "earste net-lêzen berjocht". As in abonnee nije berjochten freget, kin it allinich berjochten ûntfange dy't noch noait earder binne levere oan in abonnee binnen de groep.
- D'r is in kommando om eksplisyt te befestigjen dat it berjocht mei sukses ferwurke is troch de abonnee. Oant dit kommando oproppen wurdt, bliuwt it frege berjocht yn 'e "wachtende" status.
- Binnen de Consumer Group kin elke abonnee in histoarje oanfreegje fan berjochten dy't by him binne levere, mar noch net ferwurke binne (yn 'e "ferwachting" status)
Yn in sin kin de steat fan 'e groep as folget wurde útdrukt:
+----------------------------------------+
| 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)
+----------------------------------------+
No is it tiid om yn 'e kunde te kommen mei de wichtichste kommando's foar de Consumer Group, nammentlik:
- XGROUP brûkt om groepen te meitsjen, te ferneatigjen en te behearjen
- XREADGROUP brûkt om stream troch groep te lêzen
- XACK - dit kommando lit de abonnee it berjocht markearje as suksesfol ferwurke
Oprjochting fan Consumer Group
Lit ús oannimme dat mystream al bestiet. Dan sil it kommando groep oanmeitsjen der útsjen:
> XGROUP CREATE mystream mygroup $
OK
By it oanmeitsjen fan in groep moatte wy in identifier trochjaan, fanôf dêr't de groep berjochten sil ûntfange. As wy gewoan alle nije berjochten ûntfange wolle, dan kinne wy de spesjale identifier $ brûke (lykas yn ús foarbyld hjirboppe). As jo 0 opjaan ynstee fan in spesjale identifier, dan sille alle berjochten yn 'e thread beskikber wêze foar de groep.
No't de groep oanmakke is, kinne wy fuortendaliks begjinne mei it lêzen fan berjochten mei it kommando XREADGROUP. Dit kommando is heul gelyk oan XREAD en stipet de opsjonele opsje BLOCK. D'r is lykwols in fereaske GROUP-opsje dy't altyd moat wurde oantsjutte mei twa arguminten: de groepsnamme en de abonneemamme. De opsje COUNT wurdt ek stipe.
Foardat jo de thread lêze, litte wy dêr wat berjochten pleatse:
> 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
Litte wy no besykje dizze stream troch de groep te lêzen:
> XREADGROUP GROUP mygroup Alice COUNT 1 STREAMS mystream >
1) 1) "mystream"
2) 1) 1) 1526569495631-0
2) 1) "message"
2) "apple"
It boppesteande kommando lêst ferbatim as folget:
"Ik, abonnee Alice, lid fan 'e mygroup, wol ien berjocht fan mystream lêze dat noch noait earder oan ien is besoarge."
Elke kear as in abonnee in operaasje op in groep útfiert, moat hy syn namme opjaan, himsels unyk identifisearje binnen de groep. D'r is noch ien heul wichtich detail yn it boppesteande kommando - de spesjale identifier ">". Dizze spesjale identifier filtert berjochten, en lit allinich de oer dy't noch noait earder binne besoarge.
Ek kinne jo yn spesjale gefallen in echte identifier opjaan lykas 0 of in oare jildige identifier. Yn dit gefal it kommando XREADGROUP sil jo in skiednis fan berjochten weromjaan mei de status fan "ôfwachting" dy't waarden levere oan de opjûne abonnee (Alice) mar noch net erkend binne mei it kommando XACK.
Wy kinne dit gedrach testen troch fuortendaliks de ID 0 op te jaan, sûnder de opsje TELLE. Wy sille gewoan in ienich berjocht sjen, dat is, it appelberjocht:
> XREADGROUP GROUP mygroup Alice STREAMS mystream 0
1) 1) "mystream"
2) 1) 1) 1526569495631-0
2) 1) "message"
2) "apple"
As wy it berjocht lykwols befêstigje as suksesfol ferwurke, dan sil it net mear werjûn wurde:
> XACK mystream mygroup 1526569495631-0
(integer) 1
> XREADGROUP GROUP mygroup Alice STREAMS mystream 0
1) 1) "mystream"
2) (empty list or set)
No is it de beurt fan Bob om wat te lêzen:
> 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, in lid fan mygroup, frege om net mear as twa berjochten. It kommando rapportearret allinich net besoarge berjochten fanwegen de spesjale identifier ">". Sa't jo sjen kinne, sil it berjocht "appel" net werjûn wurde, om't it al oan Alice is levere, sadat Bob "oranje" en "aardbei" krijt.
Op dizze manier kinne Alice, Bob en elke oare abonnee fan 'e groep ferskate berjochten fan deselde stream lêze. Se kinne ek har skiednis fan net ferwurke berjochten lêze of berjochten markearje as ferwurke.
D'r binne in pear dingen om yn gedachten te hâlden:
- Sadree't de abonnee it berjocht beskôget as in kommando XREADGROUP, dit berjocht giet yn 'e "wachtende" steat en wurdt tawiisd oan dy spesifike abonnee. Oare groepsabonnees kinne dit berjocht net lêze.
- Abonnees wurde automatysk oanmakke by earste fermelding, it is net nedich om se eksplisyt oan te meitsjen.
- Mei help fan XREADGROUP jo kinne berjochten fan meardere ferskillende diskusjes tagelyk lêze, mar om dit te wurkjen moatte jo earst groepen meitsje mei deselde namme foar elke thread mei XGROUP
Herstel nei in mislearring
De abonnee kin herstelle fan it mislearjen en syn list mei berjochten opnij lêze mei de status "oanhâldend". Yn 'e echte wrâld kinne abonnees lykwols úteinlik mislearje. Wat bart der mei fêste berjochten fan in abonnee as de abonnee net by steat is om te herstellen fan in mislearring?
Consumer Group biedt in funksje dy't wurdt brûkt foar krekt sokke gefallen - as jo moatte feroarje de eigner fan berjochten.
It earste ding dat jo moatte dwaan is it kommando neame XPENDING, dy't alle berjochten yn 'e groep toant mei de status "oanhingje". Yn syn ienfâldichste foarm wurdt it kommando neamd mei mar twa arguminten: de threadnamme en de groepnamme:
> XPENDING mystream mygroup
1) (integer) 2
2) 1526569498055-0
3) 1526569506935-0
4) 1) 1) "Bob"
2) "2"
It team liet it oantal net-ferwurke berjochten sjen foar de hiele groep en foar elke abonnee. Wy hawwe allinich Bob mei twa treflike berjochten, om't it ienige berjocht dat Alice frege waard befêstige mei XACK.
Wy kinne mear ynformaasje oanfreegje mei mear arguminten:
XPENDING {key} {groupname} [{start-id} {end-id} {count} [{consumer-name}]]
{start-id} {end-id} - berik fan identifiers (jo kinne "-" en "+") brûke)
{count} - oantal leveringspogingen
{consumer-name} - groepsnamme
> 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
No hawwe wy details foar elk berjocht: ID, abonneemamme, idle tiid yn millisekonden en as lêste it oantal leveringspogingen. Wy hawwe twa berjochten fan Bob en se hawwe 74170458 millisekonden idle west, sawat 20 oeren.
Tink derom dat gjinien ús stopet om te kontrolearjen wat de ynhâld fan it berjocht wie gewoan troch te brûken XRANGE.
> XRANGE mystream 1526569498055-0 1526569498055-0
1) 1) 1526569498055-0
2) 1) "message"
2) "orange"
Wy moatte gewoan deselde identifier twa kear werhelje yn 'e arguminten. No't wy wat idee hawwe, kin Alice beslute dat Bob nei 20 oeren fan downtime wierskynlik net herstelt, en it is tiid om dizze berjochten te freegjen en it ferwurkjen fan se foar Bob te hervatten. Hjirfoar brûke wy it kommando XCLAIM:
XCLAIM {key} {group} {consumer} {min-idle-time} {ID-1} {ID-2} ... {ID-N}
Mei dit kommando kinne wy in "bûtenlânsk" berjocht ûntfange dat noch net ferwurke is troch de eigner te feroarjen yn {konsumint}. Wy kinne lykwols ek in minimale idle-tiid {min-idle-time} leverje. Dit helpt in situaasje te foarkommen wêrby't twa kliïnten besykje de eigner fan deselde berjochten tagelyk te feroarjen:
Client 1: XCLAIM mystream mygroup Alice 3600000 1526569498055-0
Clinet 2: XCLAIM mystream mygroup Lora 3600000 1526569498055-0
De earste klant sil de downtime weromsette en de leveringteller ferheegje. Sa kin de twadde klant it net oanfreegje.
> XCLAIM mystream mygroup Alice 3600000 1526569498055-0
1) 1) 1526569498055-0
2) 1) "message"
2) "orange"
It berjocht is mei súkses opeaske troch Alice, dy't it berjocht no kin ferwurkje en erkennen.
Ut it boppesteande foarbyld kinne jo sjen dat in suksesfolle fersyk de ynhâld fan it berjocht sels werombringt. Dit is lykwols net nedich. De JUSTID-opsje kin allinich brûkt wurde om berjocht-ID's werom te jaan. Dit is handich as jo net ynteressearre binne yn 'e details fan it berjocht en wolle de systeemprestaasjes ferheegje.
Levering counter
De teller dy't jo sjogge yn 'e útfier XPENDING is it oantal leveringen fan elk berjocht. Sa'n teller wurdt op twa manieren ferhege: as in berjocht mei súkses oanfrege wurdt fia XCLAIM of as in oprop wurdt brûkt XREADGROUP.
It is normaal dat guon berjochten meardere kearen wurde levere. It wichtichste is dat alle berjochten úteinlik wurde ferwurke. Soms foarkomme problemen by it ferwurkjen fan in berjocht om't it berjocht sels skansearre is, of berjochtferwurking feroarsake in flater yn 'e handlerkoade. Yn dit gefal kin it blike dat nimmen dit berjocht ferwurkje kin. Sûnt wy hawwe in levering poging teller, kinne wy brûke dizze teller foar in detect sokke situaasjes. Dêrom, as it oantal leveringen it hege oantal berikt hat dat jo oantsjutte, soe it wierskynlik wizer wêze om sa'n berjocht op in oare thread te pleatsen en in notifikaasje te stjoeren nei de systeembehearder.
Thread State
team XINFO brûkt om ferskate ynformaasje op te freegjen oer in thread en syn groepen. Bygelyks, in basis kommando sjocht der sa út:
> 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"
It kommando hjirboppe toant algemiene ynformaasje oer de opjûne stream. No in wat komplekser foarbyld:
> 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
It kommando hjirboppe toant algemiene ynformaasje foar alle groepen fan 'e oantsjutte thread
> 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
It kommando hjirboppe toant ynformaasje foar alle abonnees fan de opjûne stream en groep.
As jo de kommando-syntaksis ferjitte, freegje dan gewoan it kommando sels om help:
> 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.
Stream Grutte Limit
In protte applikaasjes wolle net foar altyd gegevens sammelje yn in stream. It is faak nuttich om in maksimum oantal berjochten tastien te hawwen per thread. Yn oare gefallen is it handich om alle berjochten fan in thread nei in oare persistente winkel te ferpleatsen as de opjûne threadgrutte wurdt berikt. Jo kinne de grutte fan in stream beheine mei de parameter MAXLEN yn it kommando 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"
By it brûken fan MAXLEN wurde âlde records automatysk wiske as se in opjûne lingte berikke, sadat de stream in konstante grutte hat. It snoeien komt yn dit gefal lykwols net op 'e meast effisjinte manier foar yn it ûnthâld fan Redis. Jo kinne de situaasje as folgjend ferbetterje:
XADD mystream MAXLEN ~ 1000 * ... entry fields here ...
It argumint ~ yn it foarbyld hjirboppe betsjut dat wy de streamlingte net needsaaklik moatte beheine ta in spesifike wearde. Yn ús foarbyld kin dit elk getal grutter wêze as of gelyk oan 1000 (bygelyks 1000, 1010 of 1030). Wy hawwe krekt eksplisyt spesifisearre dat wy wolle dat ús stream op syn minst 1000 records opslacht. Dit makket ûnthâld behear folle effisjinter binnen Redis.
Der is ek in apart team XTRIM, dy't itselde docht:
> XTRIM mystream MAXLEN 10
> XTRIM mystream MAXLEN ~ 10
Persistente opslach en replikaasje
Redis Stream wurdt asynchronysk replikearre nei slaveknooppunten en bewarre yn bestannen lykas AOF (snapshot fan alle gegevens) en RDB (log fan alle skriuwoperaasjes). Replikaasje fan steat fan Consumer Groups wurdt ek stipe. Dêrom, as in berjocht yn 'e "wachtende" status is op 'e masterknooppunt, dan sil dit berjocht op 'e slaveknooppunten deselde status hawwe.
It fuortsmiten fan yndividuele eleminten út in stream
D'r is in spesjaal kommando om berjochten te wiskjen XDEL. It kommando krijt de namme fan 'e thread folge troch de berjocht-ID's dy't moatte wurde wiske:
> 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"
By it brûken fan dit kommando moatte jo der rekken mei hâlde dat it eigentlike ûnthâld net daliks frijjûn wurdt.
Nul lingte streams
It ferskil tusken streamen en oare Redis-gegevensstruktueren is dat as oare gegevensstruktueren gjin eleminten mear yn har hawwe, as by-effekt, sil de gegevensstruktuer sels út it ûnthâld fuortsmiten wurde. Sa sil bygelyks de sortearre set folslein fuortsmiten wurde as de ZREM-oprop it lêste elemint ferwideret. Ynstee dêrfan meie triedden yn it ûnthâld bliuwe, sels sûnder eleminten binnen te hawwen.
konklúzje
Redis Stream is ideaal foar it meitsjen fan berjochtmakelaars, berjochtwachtrijen, ferienige logging, en petearsystemen foar skiednisbehâld.
Sa't ik ris sei , Programma's binne algoritmen plus gegevensstruktueren, en Redis jout jo al beide.
Boarne: www.habr.com