Mae Redis Stream yn fath o ddata haniaethol newydd a gyflwynwyd yn Redis gyda fersiwn 5.0
Yn gysyniadol, mae Redis Stream yn Rhestr y gallwch chi ychwanegu cofnodion ati. Mae gan bob cofnod ddynodwr unigryw. Yn ddiofyn, mae'r ID yn cael ei gynhyrchu'n awtomatig ac mae'n cynnwys stamp amser. Felly, gallwch chi ymholi ystodau o gofnodion dros amser, neu dderbyn data newydd wrth iddo gyrraedd y ffrwd, yn debyg iawn i orchymyn Unix "tail -f" yn darllen ffeil log ac yn rhewi wrth aros am ddata newydd. Sylwch y gall cleientiaid lluosog wrando ar edefyn ar yr un pryd, yn union fel y gall llawer o brosesau "tail -f" ddarllen ffeil ar yr un pryd heb wrthdaro â'i gilydd.

Er mwyn deall holl fanteision y math newydd o ddata, gadewch i ni edrych yn gyflym ar y strwythurau Redis sy'n bodoli ers tro sy'n ailadrodd ymarferoldeb Redis Stream yn rhannol.

Redis PUB/SUB

Mae Redis Pub/Sub yn system negeseuon syml sydd eisoes wedi'i chynnwys yn eich storfa gwerth allwedd. Fodd bynnag, daw symlrwydd am gost:

Os bydd y cyhoeddwr yn methu am ryw reswm, yna mae'n colli ei holl danysgrifwyr
Mae angen i'r cyhoeddwr wybod union gyfeiriad ei holl danysgrifwyr
Gall cyhoeddwr orlwytho ei danysgrifwyr â gwaith os cyhoeddir data yn gyflymach nag y caiff ei brosesu
Mae'r neges yn cael ei dileu o glustogfa'r cyhoeddwr yn syth ar ôl ei chyhoeddi, ni waeth faint o danysgrifwyr y'i danfonwyd iddynt a pha mor gyflym yr oeddent yn gallu prosesu'r neges hon.
Bydd pob tanysgrifiwr yn derbyn y neges ar yr un pryd. Rhaid i danysgrifwyr eu hunain rywsut gytuno ymhlith ei gilydd ar drefn prosesu'r un neges.
Nid oes unrhyw fecanwaith adeiledig i gadarnhau bod tanysgrifiwr wedi prosesu neges yn llwyddiannus. Os bydd tanysgrifiwr yn derbyn neges ac yn damwain wrth brosesu, ni fydd y cyhoeddwr yn gwybod amdano.

Rhestr Redis

Mae Redis List yn strwythur data sy'n cefnogi blocio gorchmynion darllen. Gallwch ychwanegu a darllen negeseuon o ddechrau neu ddiwedd y rhestr. Yn seiliedig ar y strwythur hwn, gallwch wneud pentwr neu giw da ar gyfer eich system ddosbarthedig, ac yn y rhan fwyaf o achosion bydd hyn yn ddigon. Y prif wahaniaethau o dafarn/is-dafarn Redis:

Anfonir y neges i un cleient. Bydd y cleient darllen-rwystro cyntaf yn derbyn y data yn gyntaf.
Rhaid i Clint gychwyn y llawdriniaeth darllen ar gyfer pob neges ei hun. Nid yw'r rhestr yn gwybod dim am gleientiaid.
Mae negeseuon yn cael eu storio nes bod rhywun yn eu darllen neu'n eu dileu yn benodol. Os ydych chi'n ffurfweddu'r gweinydd Redis i fflysio data i ddisg, yna mae dibynadwyedd y system yn cynyddu'n ddramatig.

Cyflwyniad i Stream

Ychwanegu cofnod at nant

Tîm XADD yn ychwanegu cofnod newydd i'r ffrwd. Nid llinyn yn unig yw cofnod, mae'n cynnwys un neu fwy o barau gwerth allweddol. Felly, mae pob cofnod eisoes wedi'i strwythuro ac yn debyg i strwythur ffeil CSV.

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

Yn yr enghraifft uchod, rydym yn ychwanegu dau faes at y nant gyda'r enw (allweddol) “mystream”: “sensor-id” a “temperature” gyda'r gwerthoedd “1234” a “19.8”, yn y drefn honno. Fel yr ail ddadl, mae'r gorchymyn yn cymryd dynodwr a fydd yn cael ei neilltuo i'r cofnod - mae'r dynodwr hwn yn nodi pob cofnod yn y ffrwd yn unigryw. Fodd bynnag, yn yr achos hwn fe wnaethom basio * oherwydd ein bod am i Redis gynhyrchu ID newydd i ni. Bydd pob ID newydd yn cynyddu. Felly, bydd gan bob cofnod newydd ddynodwr uwch mewn perthynas â chofnodion blaenorol.

Fformat y dynodwr

Yr ID cofnod a ddychwelwyd gan y gorchymyn XADD, yn cynnwys dwy ran:

{millisecondsTime}-{sequenceNumber}
milieiliadauAmser - Amser Unix mewn milieiliadau (amser gweinydd Redis). Fodd bynnag, os yw'r amser presennol yr un peth neu'n llai nag amser y recordiad blaenorol, yna defnyddir stamp amser y recordiad blaenorol. Felly, os yw amser y gweinydd yn mynd yn ôl mewn amser, bydd y dynodwr newydd yn dal i gadw'r eiddo cynyddran.

dilyniantRhif a ddefnyddir ar gyfer cofnodion a grëwyd yn yr un milieiliad. dilyniantRhif yn cael ei gynyddu 1 o gymharu â'r cofnod blaenorol. Gan fod y dilyniantRhif yn 64 did o faint, yna yn ymarferol ni ddylech redeg i mewn i gyfyngiad ar nifer y cofnodion y gellir eu cynhyrchu o fewn un milieiliad.

Gall fformat dynodwyr o'r fath ymddangos yn rhyfedd ar yr olwg gyntaf. Efallai y bydd darllenydd diffygiol yn meddwl tybed pam mae amser yn rhan o'r dynodwr. Y rheswm yw bod ffrydiau Redis yn cefnogi ymholiadau ystod trwy ID. Gan fod y dynodwr yn gysylltiedig â'r amser y cafodd y cofnod ei greu, mae hyn yn ei gwneud hi'n bosibl cwestiynu ystodau amser. Byddwn yn edrych ar enghraifft benodol pan edrychwn ar y gorchymyn XRANGEG.

Os am ryw reswm mae angen i'r defnyddiwr nodi ei ddynodwr ei hun, sydd, er enghraifft, yn gysylltiedig â rhyw system allanol, yna gallwn ei drosglwyddo i'r gorchymyn XADD yn lle * fel y dangosir isod:

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

Sylwch fod yn rhaid i chi fonitro'r cynyddiad ID eich hun yn yr achos hwn. Yn ein hesiampl, y dynodwr lleiaf yw "0-1", felly ni fydd y gorchymyn yn derbyn dynodwr arall sy'n hafal i neu'n llai na "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

Nifer y cofnodion fesul ffrwd

Mae'n bosibl cael nifer y cofnodion mewn ffrwd yn syml trwy ddefnyddio'r gorchymyn XLEN. Er enghraifft, bydd y gorchymyn hwn yn dychwelyd y gwerth canlynol:

> XLEN somestream
(integer) 2

Ymholiadau ystod - XRANGE a XREVRANGE

I ofyn am ddata yn ôl ystod, mae angen i ni nodi dau ddynodwr - dechrau a diwedd yr ystod. Bydd yr ystod a ddychwelwyd yn cynnwys yr holl elfennau, gan gynnwys y ffiniau. Mae yna hefyd ddau ddynodwr arbennig “-” a “+”, yn y drefn honno sy'n golygu'r dynodwr lleiaf (cofnod cyntaf) a mwyaf (cofnod olaf) yn y ffrwd. Bydd yr enghraifft isod yn rhestru'r holl gofnodion ffrwd.

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

Mae pob cofnod a ddychwelir yn gyfres o ddwy elfen: dynodwr a rhestr o barau gwerth allweddol. Dywedasom eisoes fod dynodwyr cofnodion yn gysylltiedig ag amser. Felly, gallwn ofyn am ystod o gyfnod penodol o amser. Fodd bynnag, gallwn nodi yn y cais nid y dynodwr llawn, ond dim ond yr amser Unix, gan hepgor y rhan sy'n ymwneud â dilyniantRhif. Bydd y rhan o'r dynodwr sydd wedi'i hepgor yn cael ei osod yn awtomatig i sero ar ddechrau'r ystod ac i'r gwerth mwyaf posibl ar ddiwedd yr ystod. Isod mae enghraifft o sut y gallwch ofyn am ystod o ddau milieiliad.

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

Dim ond un cofnod sydd gennym yn yr ystod hon, fodd bynnag mewn setiau data gwirioneddol gall y canlyniad a ddychwelir fod yn enfawr. Am y rheswm hwn XRANGEG yn cefnogi'r opsiwn COUNT. Trwy nodi'r swm, gallwn gael y cofnodion N cyntaf. Os bydd angen i ni gael y cofnodion N nesaf (tudaleniad), gallwn ddefnyddio'r ID diwethaf a dderbyniwyd, a'i gynyddu dilyniantRhif gan un a gofyn eto. Gadewch i ni edrych ar hyn yn yr enghraifft ganlynol. Rydym yn dechrau ychwanegu 10 elfen gyda XADD (gan dybio bod mystream eisoes wedi'i lenwi â 10 elfen). I gychwyn yr iteriad yn cael 2 elfen fesul gorchymyn, rydym yn dechrau gyda'r ystod lawn ond gyda COUNT yn hafal i 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"

Er mwyn parhau i ailadrodd y ddwy elfen nesaf, mae angen i ni ddewis yr ID diwethaf a dderbyniwyd, h.y. 1519073279157-0, ac ychwanegu 1 at dilyniantRhif.
Bellach gellir defnyddio'r ID canlyniadol, yn yr achos hwn 1519073279157-1, fel y ddadl cychwyn amrediad newydd ar gyfer yr alwad nesaf XRANGEG:

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

Ac yn y blaen. Oherwydd cymhlethdod XRANGEG yw O(log(N)) i chwilio ac yna O(M) i ddychwelyd elfennau M, yna mae pob cam iteriad yn gyflym. Felly, gan ddefnyddio XRANGEG gellir ailadrodd ffrydiau'n effeithlon.

Tîm XREVRANGE yn cyfateb XRANGEG, ond yn dychwelyd yr elfennau yn y drefn wrthdroi:

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

Sylwch fod y gorchymyn XREVRANGE cymryd dadleuon amrediad cychwyn a stopio yn y drefn arall.

Darllen cofnodion newydd gan ddefnyddio XREAD

Yn aml cyfyd y dasg o danysgrifio i ffrwd a derbyn negeseuon newydd yn unig. Gall y cysyniad hwn ymddangos yn debyg i Redis Pub / Sub neu rwystro Redis List, ond mae gwahaniaethau sylfaenol o ran sut i ddefnyddio Redis Stream:

Anfonir pob neges newydd i bob tanysgrifiwr yn ddiofyn. Mae'r ymddygiad hwn yn wahanol i Redis Redis blocio, lle bydd neges newydd yn cael ei darllen gan un tanysgrifiwr yn unig.
Tra yn Redis Pub/Sub mae pob neges yn cael ei hanghofio a byth yn parhau, yn Stream cedwir pob neges am gyfnod amhenodol (oni bai bod y cleient yn achosi dileu yn benodol).
Mae Redis Stream yn caniatáu ichi wahaniaethu mynediad at negeseuon o fewn un ffrwd. Dim ond hanes ei neges bersonol y gall tanysgrifiwr penodol ei weld.

Gallwch danysgrifio i edefyn a derbyn negeseuon newydd gan ddefnyddio'r gorchymyn XREAD. Mae ychydig yn fwy cymhleth na XRANGEG, felly byddwn yn dechrau gyda'r enghreifftiau symlach yn gyntaf.

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

Mae'r enghraifft uchod yn dangos ffurflen nad yw'n blocio XREAD. Sylwch fod yr opsiwn COUNT yn ddewisol. Mewn gwirionedd, yr unig opsiwn gorchymyn gofynnol yw'r opsiwn STREAMS, sy'n nodi rhestr o ffrydiau ynghyd â'r dynodwr uchafswm cyfatebol. Ysgrifennon ni “STREAMS mystream 0” - rydym am dderbyn pob cofnod o'r ffrwd mystream gyda dynodwr yn fwy na “0-0”. Fel y gwelwch o'r enghraifft, mae'r gorchymyn yn dychwelyd enw'r edefyn oherwydd gallwn danysgrifio i edafedd lluosog ar yr un pryd. Gallem ysgrifennu, er enghraifft, "STREAMS mystream otherstream 0 0". Sylwch, ar ôl yr opsiwn STRYDOEDD, mae angen i ni yn gyntaf ddarparu enwau'r holl ffrydiau gofynnol a dim ond wedyn rhestr o ddynodwyr.

Yn y ffurf syml hon nid yw'r gorchymyn yn gwneud unrhyw beth arbennig o'i gymharu â XRANGEG. Fodd bynnag, y peth diddorol yw y gallwn droi yn hawdd XREAD i orchymyn blocio, gan nodi'r ddadl BLOCK:

> XREAD BLOCK 0 STREAMS mystream $
Yn yr enghraifft uchod, nodir opsiwn BLOCK newydd gyda goramser o 0 milieiliad (mae hyn yn golygu aros am gyfnod amhenodol). Ar ben hynny, yn lle pasio'r dynodwr arferol ar gyfer y ffrwd mystream, pasiwyd dynodwr arbennig $. Mae'r dynodwr arbennig hwn yn golygu hynny XREAD rhaid defnyddio'r dynodwr mwyaf yn mystream fel y dynodwr. Felly dim ond negeseuon newydd y byddwn ni'n eu derbyn o'r eiliad y dechreuon ni wrando. Mewn rhai ffyrdd mae hyn yn debyg i'r gorchymyn Unix "tail -f".

Sylwch, wrth ddefnyddio'r opsiwn BLOCK, nid oes angen i ni o reidrwydd ddefnyddio'r dynodwr arbennig $. Gallwn ddefnyddio unrhyw ddynodwr sy'n bodoli yn y ffrwd. Os gall y tîm wasanaethu ein cais ar unwaith heb rwystro, bydd yn gwneud hynny, fel arall bydd yn rhwystro.

Blocio XREAD hefyd yn gallu gwrando ar edafedd lluosog ar unwaith, does ond angen i chi nodi eu henwau. Yn yr achos hwn, bydd y gorchymyn yn dychwelyd cofnod o'r ffrwd gyntaf a dderbyniodd ddata. Bydd y tanysgrifiwr cyntaf sydd wedi'i rwystro ar gyfer edefyn penodol yn derbyn data yn gyntaf.

Grwpiau Defnyddwyr

Mewn rhai tasgau, rydym am gyfyngu mynediad tanysgrifiwr i negeseuon o fewn un edefyn. Enghraifft lle gallai hyn fod yn ddefnyddiol yw ciw neges gyda gweithwyr a fydd yn derbyn negeseuon gwahanol o edefyn, gan ganiatáu prosesu negeseuon i raddfa.

Os dychmygwn fod gennym dri tanysgrifiwr C1, C2, C3 ac edefyn sy'n cynnwys negeseuon 1, 2, 3, 4, 5, 6, 7, yna bydd y negeseuon yn cael eu gwasanaethu fel yn y diagram isod:

1 -> C1 2 -> C2 3 -> C3 4 -> C1 5 -> C2 6 -> C3 7 -> C1
Er mwyn cyflawni'r effaith hon, mae Redis Stream yn defnyddio cysyniad o'r enw Grŵp Defnyddwyr. Mae'r cysyniad hwn yn debyg i ffug-danysgrifiwr, sy'n derbyn data o ffrwd, ond mewn gwirionedd yn cael ei wasanaethu gan danysgrifwyr lluosog o fewn grŵp, gan ddarparu gwarantau penodol:

Anfonir pob neges i danysgrifiwr gwahanol o fewn y grŵp.
O fewn grŵp, mae tanysgrifwyr yn cael eu hadnabod wrth eu henw, sy'n llinyn sy'n sensitif i achos. Os bydd tanysgrifiwr yn gadael y grŵp dros dro, gellir ei adfer i'r grŵp gan ddefnyddio ei enw unigryw ei hun.
Mae pob Grŵp Defnyddwyr yn dilyn y cysyniad “neges gyntaf heb ei darllen”. Pan fydd tanysgrifiwr yn gofyn am negeseuon newydd, dim ond negeseuon nad ydynt erioed wedi'u dosbarthu o'r blaen i unrhyw danysgrifiwr o fewn y grŵp y gall eu derbyn.
Mae gorchymyn i gadarnhau'n benodol bod y neges wedi'i phrosesu'n llwyddiannus gan y tanysgrifiwr. Hyd nes y gelwir y gorchymyn hwn, bydd y neges y gofynnwyd amdani yn aros yn y statws "yn yr arfaeth".
O fewn y Grŵp Defnyddwyr, gall pob tanysgrifiwr ofyn am hanes o negeseuon a anfonwyd ato, ond nad ydynt wedi'u prosesu eto (yn y statws "yn yr arfaeth")

Mewn un ystyr, gellir mynegi cyflwr y grŵp fel a ganlyn:

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

Nawr mae'n bryd dod yn gyfarwydd â'r prif orchmynion ar gyfer y Grŵp Defnyddwyr, sef:

XGROUP defnyddio i greu, dinistrio a rheoli grwpiau
XREADGROUP defnyddio i ddarllen ffrwd drwodd grŵp
XACK - mae'r gorchymyn hwn yn caniatáu i'r tanysgrifiwr nodi bod y neges wedi'i phrosesu'n llwyddiannus

Creu Grŵp Defnyddwyr

Gadewch i ni dybio bod mystream eisoes yn bodoli. Yna bydd y gorchymyn creu grŵp yn edrych fel:

> XGROUP CREATE mystream mygroup $ OK
Wrth greu grŵp, rhaid i ni basio dynodwr, gan ddechrau y bydd y grŵp yn derbyn negeseuon. Os ydym am dderbyn pob neges newydd yn unig, yna gallwn ddefnyddio'r dynodwr arbennig $ (fel yn ein hesiampl uchod). Os byddwch yn nodi 0 yn lle dynodwr arbennig, yna bydd yr holl negeseuon yn yr edefyn ar gael i'r grŵp.

Nawr bod y grŵp wedi'i greu, gallwn ddechrau darllen negeseuon ar unwaith gan ddefnyddio'r gorchymyn XREADGROUP. Mae'r gorchymyn hwn yn debyg iawn i XREAD ac yn cefnogi'r opsiwn BLOCK dewisol. Fodd bynnag, mae yna opsiwn GRWP gofynnol y mae'n rhaid ei nodi bob amser gyda dwy ddadl: enw'r grŵp ac enw'r tanysgrifiwr. Cefnogir yr opsiwn COUNT hefyd.

Cyn darllen yr edefyn, gadewch i ni roi rhai negeseuon yno:

> 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

Nawr, gadewch i ni geisio darllen y ffrwd hon trwy'r grŵp:

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

Mae'r gorchymyn uchod yn darllen gair am air fel a ganlyn:

“Rwyf i, y tanysgrifiwr Alice, aelod o’r mygroup, eisiau darllen un neges o mystream nad yw erioed wedi’i chyflwyno i unrhyw un o’r blaen.”

Bob tro y bydd tanysgrifiwr yn perfformio gweithrediad ar grŵp, rhaid iddo ddarparu ei enw, gan nodi ei hun yn unigryw o fewn y grŵp. Mae un manylyn pwysig iawn yn y gorchymyn uchod - y dynodwr arbennig">". Mae'r dynodwr arbennig hwn yn hidlo negeseuon, gan adael dim ond y rhai nad ydynt erioed wedi'u dosbarthu o'r blaen.

Hefyd, mewn achosion arbennig, gallwch chi nodi dynodwr go iawn fel 0 neu unrhyw ddynodwr dilys arall. Yn yr achos hwn y gorchymyn XREADGROUP yn dychwelyd hanes negeseuon i chi gyda statws o "arfaeth" a ddanfonwyd i'r tanysgrifiwr penodedig (Alice) ond sydd heb eu cydnabod eto gan ddefnyddio'r gorchymyn XACK.

Gallwn brofi'r ymddygiad hwn trwy nodi'r ID 0 ar unwaith, heb yr opsiwn COUNT. Yn syml, byddwn yn gweld un neges yn yr arfaeth, hynny yw, y neges afal:

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

Fodd bynnag, os byddwn yn cadarnhau bod y neges wedi'i phrosesu'n llwyddiannus, ni fydd yn cael ei harddangos mwyach:

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

Nawr mae'n dro Bob i ddarllen rhywbeth:

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

Gofynnodd Bob, aelod o mygroup, am ddim mwy na dwy neges. Mae'r gorchymyn ond yn adrodd am negeseuon heb eu danfon oherwydd y dynodwr arbennig">". Fel y gwelwch, ni fydd y neges "afal" yn cael ei harddangos gan ei bod eisoes wedi'i chyflwyno i Alice, felly mae Bob yn derbyn "oren" a "mefus".

Fel hyn, gall Alice, Bob, ac unrhyw danysgrifiwr arall i'r grŵp ddarllen gwahanol negeseuon o'r un ffrwd. Gallant hefyd ddarllen eu hanes o negeseuon heb eu prosesu neu farcio negeseuon fel y'u proseswyd.

Mae yna ychydig o bethau i'w cadw mewn cof:

Cyn gynted ag y bydd y tanysgrifiwr yn ystyried y neges yn orchymyn XREADGROUP, mae'r neges hon yn mynd i mewn i'r cyflwr “yn yr arfaeth” ac yn cael ei neilltuo i'r tanysgrifiwr penodol hwnnw. Ni fydd tanysgrifwyr grŵp eraill yn gallu darllen y neges hon.
Mae tanysgrifwyr yn cael eu creu yn awtomatig ar y crybwylliad cyntaf, nid oes angen eu creu yn benodol.
Gyda XREADGROUP gallwch ddarllen negeseuon o sawl trywydd gwahanol ar yr un pryd, fodd bynnag er mwyn i hyn weithio mae angen i chi greu grwpiau gyda'r un enw ar gyfer pob edefyn yn gyntaf gan ddefnyddio XGROUP

Adfer Methiant

Gall y tanysgrifiwr wella o'r methiant ac ailddarllen ei restr o negeseuon gyda'r statws “yn yr arfaeth”. Fodd bynnag, yn y byd go iawn, efallai y bydd tanysgrifwyr yn methu yn y pen draw. Beth sy'n digwydd i negeseuon sownd tanysgrifiwr os na all y tanysgrifiwr adennill o fethiant?
Mae Consumer Group yn cynnig nodwedd a ddefnyddir ar gyfer achosion o'r fath yn unig - pan fydd angen i chi newid perchennog negeseuon.

Y peth cyntaf y mae angen i chi ei wneud yw galw'r gorchymyn XPENDING, sy'n dangos yr holl negeseuon yn y grŵp gyda'r statws “yn yr arfaeth”. Yn ei ffurf symlaf, gelwir y gorchymyn gyda dwy ddadl yn unig: enw'r edefyn ac enw'r grŵp:

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

Dangosodd y tîm nifer y negeseuon heb eu prosesu ar gyfer y grŵp cyfan ac ar gyfer pob tanysgrifiwr. Dim ond gyda Bob dwy neges yn weddill sydd gennym oherwydd cadarnhawyd yr unig neges y gofynnodd Alice amdani XACK.

Gallwn ofyn am ragor o wybodaeth gan ddefnyddio rhagor o ddadleuon:

XPENDING {key} {groupname} [{start-id} {end-id} {count} [{consumer-name}]]
{start-id} {end-id} - ystod o ddynodwyr (gallwch ddefnyddio “-” a “+”)
{cyfrif} — nifer yr ymgeisiau danfon
{defnyddiwr-enw} - enw grŵp

> 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

Nawr mae gennym fanylion ar gyfer pob neges: ID, enw'r tanysgrifiwr, amser segur mewn milieiliadau ac yn olaf nifer yr ymdrechion danfon. Mae gennym ddwy neges gan Bob ac maent wedi bod yn segur am 74170458 milieiliadau, tua 20 awr.

Sylwch nad oes neb yn ein rhwystro rhag gwirio beth oedd cynnwys y neges trwy ei ddefnyddio XRANGEG.

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

Mae'n rhaid i ni ailadrodd yr un dynodwr ddwywaith yn y dadleuon. Nawr bod gennym ni ryw syniad, efallai y bydd Alice yn penderfynu ar ôl 20 awr o amser segur, mae'n debyg na fydd Bob yn gwella, ac mae'n bryd cwestiynu'r negeseuon hynny ac ailddechrau eu prosesu ar gyfer Bob. Ar gyfer hyn rydym yn defnyddio'r gorchymyn XCLAIM:

XCLAIM {key} {group} {consumer} {min-idle-time} {ID-1} {ID-2} ... {ID-N}
Gan ddefnyddio'r gorchymyn hwn, gallwn dderbyn neges "tramor" nad yw wedi'i phrosesu eto trwy newid y perchennog i {defnyddiwr}. Fodd bynnag, gallwn hefyd ddarparu isafswm amser segur {min-idle-time}. Mae hyn yn helpu i osgoi sefyllfa lle mae dau gleient yn ceisio newid perchennog yr un negeseuon ar yr un pryd:

Client 1: XCLAIM mystream mygroup Alice 3600000 1526569498055-0 Clinet 2: XCLAIM mystream mygroup Lora 3600000 1526569498055-0
Bydd y cwsmer cyntaf yn ailosod yr amser segur ac yn cynyddu'r cownter dosbarthu. Felly ni fydd yr ail gleient yn gallu gofyn amdano.

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

Hawliwyd y neges yn llwyddiannus gan Alice, a all nawr brosesu'r neges a'i chydnabod.

O'r enghraifft uchod, gallwch weld bod cais llwyddiannus yn dychwelyd cynnwys y neges ei hun. Fodd bynnag, nid yw hyn yn angenrheidiol. Gellir defnyddio'r opsiwn JUSTID i ddychwelyd IDau neges yn unig. Mae hyn yn ddefnyddiol os nad oes gennych ddiddordeb ym manylion y neges ac eisiau cynyddu perfformiad system.

Cownter dosbarthu

Y cownter a welwch yn yr allbwn XPENDING yw nifer y danfoniadau o bob neges. Cynyddir rhifydd o'r fath mewn dwy ffordd: pan ofynnir yn llwyddiannus am neges trwy XCLAIM neu pan ddefnyddir galwad XREADGROUP.

Mae'n arferol i rai negeseuon gael eu cyflwyno sawl gwaith. Y prif beth yw bod yr holl negeseuon yn cael eu prosesu yn y pen draw. Weithiau mae problemau'n codi wrth brosesu neges oherwydd bod y neges ei hun wedi'i llygru, neu mae prosesu neges yn achosi gwall yn y cod triniwr. Yn yr achos hwn, efallai na fydd neb yn gallu prosesu'r neges hon. Gan fod gennym gownter ymgais danfon, gallwn ddefnyddio'r rhifydd hwn i ganfod sefyllfaoedd o'r fath. Felly, unwaith y bydd y cyfrif dosbarthu yn cyrraedd y nifer uchel a nodir gennych, mae'n debyg y byddai'n ddoethach rhoi neges o'r fath ar edefyn arall ac anfon hysbysiad at weinyddwr y system.

Cyflwr Thread

Tîm XINFO a ddefnyddir i ofyn am wybodaeth amrywiol am edefyn a'i grwpiau. Er enghraifft, mae gorchymyn sylfaenol yn edrych fel hyn:

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

Mae'r gorchymyn uchod yn dangos gwybodaeth gyffredinol am y ffrwd penodedig. Nawr enghraifft ychydig yn fwy cymhleth:

> 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

Mae'r gorchymyn uchod yn dangos gwybodaeth gyffredinol ar gyfer pob grŵp o'r edefyn penodedig

> 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

Mae'r gorchymyn uchod yn dangos gwybodaeth ar gyfer holl danysgrifwyr y ffrwd a'r grŵp penodedig.
Os byddwch chi'n anghofio'r gystrawen gorchymyn, gofynnwch i'r gorchymyn ei hun am 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.

Terfyn Maint y Ffrwd

Nid yw llawer o gymwysiadau eisiau casglu data i mewn i ffrwd am byth. Mae'n aml yn ddefnyddiol cael uchafswm o negeseuon a ganiateir fesul edefyn. Mewn achosion eraill, mae'n ddefnyddiol symud pob neges o edefyn i storfa barhaus arall pan gyrhaeddir y maint edau penodedig. Gallwch gyfyngu ar faint ffrwd gan ddefnyddio'r paramedr MAXLEN yn y gorchymyn 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"

Wrth ddefnyddio MAXLEN, mae hen gofnodion yn cael eu dileu yn awtomatig pan fyddant yn cyrraedd hyd penodol, felly mae gan y ffrwd faint cyson. Fodd bynnag, nid yw tocio yn yr achos hwn yn digwydd yn y ffordd fwyaf effeithlon yng nghof Redis. Gallwch wella'r sefyllfa fel a ganlyn:

XADD mystream MAXLEN ~ 1000 * ... entry fields here ...
Mae'r ddadl ~ yn yr enghraifft uchod yn golygu nad oes angen i ni gyfyngu hyd y ffrwd i werth penodol o reidrwydd. Yn ein hesiampl ni, gallai hyn fod yn unrhyw rif sy’n fwy na neu’n hafal i 1000 (er enghraifft, 1000, 1010, neu 1030). Rydym newydd nodi'n benodol ein bod am i'n ffrwd storio o leiaf 1000 o gofnodion. Mae hyn yn gwneud rheoli cof yn llawer mwy effeithlon y tu mewn i Redis.

Mae tîm ar wahân hefyd XTRIM, sy'n gwneud yr un peth:

> XTRIM mystream MAXLEN 10

> XTRIM mystream MAXLEN ~ 10

Storio ac atgynhyrchu parhaus

Mae Redis Stream yn cael ei ailadrodd yn anghydamserol i nodau caethweision a'i gadw i ffeiliau fel AOF (ciplun o'r holl ddata) ac RDB (log o'r holl weithrediadau ysgrifennu). Cefnogir dyblygu gwladwriaeth Grwpiau Defnyddwyr hefyd. Felly, os yw neges yn y statws “yn yr arfaeth” ar y prif nod, yna ar y nodau caethweision bydd gan y neges hon yr un statws.

Tynnu elfennau unigol o ffrwd

Mae gorchymyn arbennig i ddileu negeseuon XDEL. Mae'r gorchymyn yn cael enw'r edefyn ac yna'r IDau neges i'w dileu:

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

Wrth ddefnyddio'r gorchymyn hwn, mae angen i chi gymryd i ystyriaeth na fydd y cof gwirioneddol yn cael ei ryddhau ar unwaith.

Nentydd hyd sero

Y gwahaniaeth rhwng ffrydiau a strwythurau data Redis eraill yw pan nad oes gan strwythurau data eraill elfennau ynddynt mwyach, fel sgîl-effaith, bydd y strwythur data ei hun yn cael ei dynnu o'r cof. Felly, er enghraifft, bydd y set wedi'i ddidoli yn cael ei dynnu'n llwyr pan fydd galwad ZREM yn dileu'r elfen olaf. Yn lle hynny, caniateir i edafedd aros yn y cof hyd yn oed heb fod ag unrhyw elfennau y tu mewn.

Casgliad

Mae Redis Stream yn ddelfrydol ar gyfer creu broceriaid negeseuon, ciwiau neges, logio unedig, a systemau sgwrsio sy'n cadw hanes.

Fel y dywedais unwaith Niklaus Wirth, mae rhaglenni yn algorithmau ynghyd â strwythurau data, ac mae Redis eisoes yn rhoi'r ddau i chi.

Ffynhonnell: hab.com

Redis Stream - dibynadwyedd a scalability eich systemau negeseuon