ProHoster > blog > Utawala > Redis Stream - kuegemea na uzani wa mifumo yako ya utumaji ujumbe

Redis Stream - kuegemea na uzani wa mifumo yako ya utumaji ujumbe

Redis Stream - kuegemea na uzani wa mifumo yako ya utumaji ujumbe

Redis Stream ni aina mpya ya data ya muhtasari iliyoletwa katika Redis na toleo la 5.0
Kwa kweli, Redis Stream ni Orodha ambayo unaweza kuongeza maingizo. Kila ingizo lina kitambulisho cha kipekee. Kwa chaguomsingi, kitambulisho huzalishwa kiotomatiki na inajumuisha muhuri wa muda. Kwa hivyo, unaweza kuuliza masafa ya rekodi kwa wakati, au kupokea data mpya inapofika kwenye mkondo, kama vile amri ya Unix "tail -f" inasoma faili ya kumbukumbu na kugandisha inaposubiri data mpya. Kumbuka kuwa wateja wengi wanaweza kusikiliza mazungumzo kwa wakati mmoja, kama vile michakato mingi ya "tail -f" inaweza kusoma faili kwa wakati mmoja bila kupingana.

Ili kuelewa manufaa yote ya aina mpya ya data, hebu tuangalie kwa haraka miundo ya muda mrefu ya Redis ambayo inaiga utendakazi wa Redis Stream.

Redis PUB/SUB

Redis Pub/Sub ni mfumo rahisi wa kutuma ujumbe ambao tayari umejengwa kwenye duka lako la thamani kuu. Walakini, unyenyekevu huja kwa bei:

  • Ikiwa mchapishaji kwa sababu fulani hushindwa, basi hupoteza wanachama wake wote
  • Mchapishaji anahitaji kujua anwani kamili ya wasajili wake wote
  • Mchapishaji anaweza kupakia wateja wake kazi kupita kiasi ikiwa data itachapishwa haraka kuliko inavyochakatwa
  • Ujumbe hufutwa kutoka kwa bafa ya mchapishaji mara tu baada ya kuchapishwa, bila kujali ni watu wangapi waliojisajili uliwasilishwa na jinsi walivyoweza kuchakata ujumbe huu kwa haraka.
  • Wasajili wote watapokea ujumbe kwa wakati mmoja. Wasajili wenyewe lazima kwa njia fulani wakubaliane kati yao juu ya agizo la usindikaji wa ujumbe huo.
  • Hakuna utaratibu uliojumuishwa wa kuthibitisha kwamba mteja amechakata ujumbe kwa ufanisi. Msajili akipokea ujumbe na kuacha kufanya kazi wakati wa kuchakata, mchapishaji hatajua kuuhusu.

Orodha ya Redis

Orodha ya Redis ni muundo wa data unaounga mkono kuzuia amri za kusoma. Unaweza kuongeza na kusoma ujumbe kutoka mwanzo au mwisho wa orodha. Kulingana na muundo huu, unaweza kufanya stack nzuri au foleni kwa mfumo wako uliosambazwa, na mara nyingi hii itakuwa ya kutosha. Tofauti kuu kutoka kwa Redis Pub/Sub:

  • Ujumbe huwasilishwa kwa mteja mmoja. Mteja wa kwanza aliyezuiwa kusoma atapokea data kwanza.
  • Clint lazima aanzishe shughuli ya kusoma kwa kila ujumbe mwenyewe. Orodha haijui chochote kuhusu wateja.
  • Ujumbe huhifadhiwa hadi mtu aisome au aifute waziwazi. Ikiwa unasanidi seva ya Redis ili kufuta data kwenye diski, basi uaminifu wa mfumo huongezeka kwa kasi.

Utangulizi wa Tiririsha

Inaongeza kiingilio kwenye mkondo

Timu XADD inaongeza ingizo jipya kwenye mkondo. Rekodi sio tu mfuatano, ina jozi moja au zaidi za thamani-msingi. Kwa hivyo, kila ingizo tayari limeundwa na linafanana na muundo wa faili ya CSV.

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

Katika mfano hapo juu, tunaongeza sehemu mbili kwenye mkondo na jina (ufunguo) "mystream": "kitambulisho cha sensor" na "joto" na maadili "1234" na "19.8", mtawaliwa. Kama hoja ya pili, amri inachukua kitambulisho kitakachopewa ingizo - kitambulisho hiki kinatambulisha kwa kipekee kila ingizo kwenye mkondo. Walakini, katika kesi hii tulipitisha * kwa sababu tunataka Redis itutengenezee kitambulisho kipya. Kila kitambulisho kipya kitaongezeka. Kwa hiyo, kila ingizo jipya litakuwa na kitambulisho cha juu zaidi kuhusiana na maingizo yaliyotangulia.

Umbizo la kitambulisho

Kitambulisho cha kuingia kilirejeshwa kwa amri XADD, lina sehemu mbili:

{millisecondsTime}-{sequenceNumber}

millisecondsTime - Wakati wa Unix katika milisekunde (muda wa seva ya Redis). Hata hivyo, ikiwa muda wa sasa ni sawa au chini ya muda wa kurekodi uliopita, basi muhuri wa muda wa rekodi ya awali hutumiwa. Kwa hivyo, ikiwa muda wa seva unarudi nyuma, kitambulisho kipya bado kitahifadhi sifa ya nyongeza.

mlolongoNambari hutumika kwa rekodi zilizoundwa kwa milisekunde sawa. mlolongoNambari itaongezwa kwa 1 kuhusiana na ingizo la awali. Kwa sababu ya mlolongoNambari ina ukubwa wa biti 64, basi kwa mazoezi hupaswi kukimbia katika kikomo cha idadi ya rekodi ambazo zinaweza kuzalishwa ndani ya millisecond moja.

Umbizo la vitambulisho kama hivyo linaweza kuonekana kuwa la kushangaza kwa mtazamo wa kwanza. Msomaji asiyeamini anaweza kujiuliza kwa nini wakati ni sehemu ya kitambulisho. Sababu ni kwamba mitiririko ya Redis inasaidia maswali mbalimbali kwa kitambulisho. Kwa kuwa kitambulisho kinahusishwa na wakati rekodi iliundwa, hii inafanya uwezekano wa kuuliza masafa. Tutaangalia mfano maalum tunapoangalia amri XRANGE.

Ikiwa kwa sababu fulani mtumiaji anahitaji kutaja kitambulisho chake mwenyewe, ambacho, kwa mfano, kinahusishwa na mfumo fulani wa nje, basi tunaweza kuipitisha kwa amri. XADD badala ya * kama inavyoonyeshwa hapa chini:

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

Tafadhali kumbuka kuwa katika kesi hii lazima ufuatilie ongezeko la kitambulisho mwenyewe. Katika mfano wetu, kitambulisho cha chini zaidi ni "0-1", kwa hivyo amri haitakubali kitambulisho kingine ambacho ni sawa na au chini ya "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

Idadi ya rekodi kwa kila mtiririko

Inawezekana kupata idadi ya rekodi kwenye mkondo kwa kutumia amri XLEN. Kwa mfano wetu, amri hii itarudisha thamani ifuatayo:

> XLEN somestream
(integer) 2

Maswali anuwai - XRANGE na XREVRANGE

Ili kuomba data kwa anuwai, tunahitaji kutaja vitambulisho viwili - mwanzo na mwisho wa safu. Masafa yaliyorejeshwa yatajumuisha vipengele vyote, ikiwa ni pamoja na mipaka. Pia kuna vitambulishi viwili maalum "-" na "+", mtawalia kumaanisha kitambulisho kidogo zaidi (rekodi ya kwanza) na kikubwa zaidi (rekodi ya mwisho) kwenye mkondo. Mfano hapa chini utaorodhesha maingizo yote ya mtiririko.

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

Kila rekodi iliyorejeshwa ni safu ya vipengele viwili: kitambulisho na orodha ya jozi za thamani-msingi. Tayari tulisema kwamba vitambulishi vya rekodi vinahusiana na wakati. Kwa hivyo, tunaweza kuomba anuwai ya kipindi maalum cha wakati. Walakini, tunaweza kutaja katika ombi sio kitambulisho kamili, lakini tu wakati wa Unix, tukiacha sehemu inayohusiana na mlolongoNambari. Sehemu iliyoachwa ya kitambulisho itawekwa kiotomatiki hadi sufuri mwanzoni mwa masafa na hadi thamani ya juu iwezekanayo mwishoni mwa masafa. Ufuatao ni mfano wa jinsi unavyoweza kuomba anuwai ya milisekunde mbili.

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

Tuna ingizo moja tu katika safu hii, hata hivyo katika seti halisi za data matokeo yanayorejeshwa yanaweza kuwa makubwa. Kwa sababu hii XRANGE inasaidia chaguo COUNT. Kwa kubainisha idadi, tunaweza kupata rekodi za kwanza za N. Ikiwa tunahitaji kupata rekodi za N zinazofuata (pagination), tunaweza kutumia kitambulisho cha mwisho kilichopokelewa, tukiongeze mlolongoNambari moja na kuuliza tena. Hebu tuangalie hili katika mfano ufuatao. Tunaanza kuongeza vipengele 10 na XADD (ikizingatiwa mkondo wangu ulikuwa tayari umejaa vitu 10). Ili kuanza kurudia kupata vipengele 2 kwa kila amri, tunaanza na safu kamili lakini kwa COUNT sawa na 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"

Ili kuendelea kurudia vipengele viwili vinavyofuata, tunahitaji kuchagua kitambulisho cha mwisho kilichopokelewa, yaani 1519073279157-0, na kuongeza 1 kwa mlolongoNambari.
Kitambulisho kinachotokana, katika kesi hii 1519073279157-1, sasa kinaweza kutumika kama mwanzo mpya wa hoja mbalimbali kwa simu inayofuata. 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"

Nakadhalika. Kwa sababu utata XRANGE ni O(logi(N)) kutafuta na kisha O(M) kurudisha vitu vya M, basi kila hatua ya kurudia ni haraka. Kwa hivyo, kwa kutumia XRANGE mitiririko inaweza kurudiwa kwa ufanisi.

Timu XREVRANGE ni sawa XRANGE, lakini inarudisha vitu kwa mpangilio wa nyuma:

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

Tafadhali kumbuka kuwa amri XREVRANGE inachukua mabishano ya masafa kuanza na kuacha kwa mpangilio wa nyuma.

Kusoma maingizo mapya kwa kutumia XREAD

Mara nyingi kazi hutokea kwa kujiandikisha kwenye mkondo na kupokea ujumbe mpya tu. Wazo hili linaweza kuonekana sawa na Redis Pub/Sub au kuzuia Orodha ya Redis, lakini kuna tofauti za kimsingi katika jinsi ya kutumia Redis Stream:

  1. Kila ujumbe mpya huwasilishwa kwa kila mteja kwa chaguomsingi. Tabia hii ni tofauti na kuzuia Orodha ya Redis, ambapo ujumbe mpya utasomwa tu na mteja mmoja.
  2. Ukiwa katika Redis Pub/Sub barua pepe zote husahauliwa na haziendelei kamwe, katika Tiririsha ujumbe wote huhifadhiwa kwa muda usiojulikana (isipokuwa mteja atasababisha kufutwa).
  3. Redis Stream hukuruhusu kutofautisha ufikiaji wa ujumbe ndani ya mkondo mmoja. Msajili mahususi anaweza tu kuona historia ya ujumbe wake wa kibinafsi.

Unaweza kujiandikisha kwa mazungumzo na kupokea ujumbe mpya kwa kutumia amri XREAD. Ni ngumu kidogo kuliko XRANGE, kwa hivyo tutaanza na mifano rahisi kwanza.

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

Mfano hapo juu unaonyesha fomu isiyo ya kuzuia XREAD. Kumbuka kuwa chaguo COUNT ni hiari. Kwa kweli, chaguo pekee la amri linalohitajika ni chaguo la STREAMS, ambalo linabainisha orodha ya mitiririko pamoja na kitambulisho cha juu kinacholingana. Tuliandika "STREAMS mystream 0" - tunataka kupokea rekodi zote za mkondo wangu kwa kitambulisho kikubwa kuliko "0-0". Kama unaweza kuona kutoka kwa mfano, amri inarudisha jina la uzi kwa sababu tunaweza kujiandikisha kwa nyuzi nyingi kwa wakati mmoja. Tunaweza kuandika, kwa mfano, "STREAMS mystream otherstream 0 0". Tafadhali kumbuka kuwa baada ya chaguo la STREAMS tunahitaji kwanza kutoa majina ya mitiririko yote inayohitajika na kisha tu orodha ya vitambulishi.

Katika fomu hii rahisi amri haifanyi chochote maalum ikilinganishwa na XRANGE. Hata hivyo, jambo la kuvutia ni kwamba tunaweza kugeuka kwa urahisi XREAD kwa amri ya kuzuia, ikibainisha hoja ya BLOCK:

> XREAD BLOCK 0 STREAMS mystream $

Katika mfano ulio hapo juu, chaguo jipya la BLOCK limebainishwa kwa kuisha kwa milisekunde 0 (hii ina maana ya kusubiri kwa muda usiojulikana). Kwa kuongezea, badala ya kupitisha kitambulisho cha kawaida cha mkondo wa mystream, kitambulisho maalum $ kilipitishwa. Kitambulisho hiki maalum kinamaanisha hivyo XREAD lazima utumie kitambulisho cha juu zaidi katika mkondo wangu kama kitambulisho. Kwa hivyo tutapokea ujumbe mpya pekee kuanzia tulipoanza kusikiliza. Kwa njia zingine hii ni sawa na amri ya Unix "tail -f".

Kumbuka kwamba wakati wa kutumia chaguo la BLOCK hatuhitaji kutumia kitambulisho maalum $. Tunaweza kutumia kitambulisho chochote kilichopo kwenye mkondo. Ikiwa timu inaweza kuhudumia ombi letu mara moja bila kuzuia, itafanya hivyo, vinginevyo itazuia.

Kuzuia XREAD unaweza pia kusikiliza nyuzi nyingi mara moja, unahitaji tu kutaja majina yao. Katika kesi hii, amri itarudisha rekodi ya mkondo wa kwanza uliopokea data. Msajili wa kwanza aliyezuiwa kwa mazungumzo fulani atapokea data kwanza.

Vikundi vya Watumiaji

Katika baadhi ya majukumu, tunataka kuwawekea kikomo ufikiaji wa ujumbe ndani ya mazungumzo moja. Mfano ambapo hii inaweza kuwa na manufaa ni foleni ya ujumbe na wafanyakazi ambayo itapokea ujumbe tofauti kutoka kwa mazungumzo, kuruhusu usindikaji wa ujumbe kwa ukubwa.

Ikiwa tunafikiria kuwa tuna watu watatu waliojisajili C1, C2, C3 na uzi ambao una ujumbe 1, 2, 3, 4, 5, 6, 7, basi ujumbe utatumwa kama kwenye mchoro hapa chini:

1 -> C1
2 -> C2
3 -> C3
4 -> C1
5 -> C2
6 -> C3
7 -> C1

Ili kufikia athari hii, Redis Stream hutumia dhana inayoitwa Consumer Group. Dhana hii ni sawa na mteja wa uwongo, ambaye hupokea data kutoka kwa mkondo, lakini kwa kweli huhudumiwa na waliojisajili wengi ndani ya kikundi, kutoa dhamana fulani:

  1. Kila ujumbe huwasilishwa kwa mteja tofauti ndani ya kikundi.
  2. Ndani ya kikundi, waliojisajili wanatambulika kwa majina yao, ambayo ni mfuatano ambao ni nyeti sana. Msajili akiondoka kwenye kikundi kwa muda, anaweza kurejeshwa kwenye kikundi kwa kutumia jina lake la kipekee.
  3. Kila Kikundi cha Watumiaji hufuata dhana ya "ujumbe wa kwanza ambao haujasomwa". Wakati mteja anaomba ujumbe mpya, anaweza tu kupokea ujumbe ambao haujawahi kuwasilishwa kwa mteja yeyote ndani ya kikundi.
  4. Kuna amri ya kuthibitisha kwa uwazi kwamba ujumbe ulichakatwa kwa ufanisi na mteja. Hadi amri hii iitwe, ujumbe ulioombwa utabaki katika hali ya "inasubiri".
  5. Ndani ya Kikundi cha Watumiaji, kila mteja anaweza kuomba historia ya jumbe ambazo alitumwa kwake, lakini bado hazijachakatwa (katika hali ya "inasubiri")

Kwa maana fulani, hali ya kikundi inaweza kuonyeshwa kama ifuatavyo:

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

Sasa ni wakati wa kufahamiana na amri kuu za Kikundi cha Watumiaji, ambazo ni:

  • XGROUP kutumika kuunda, kuharibu na kusimamia vikundi
  • XREADGROUP kutumika kusoma mkondo kupitia kikundi
  • XACK - amri hii inaruhusu mteja kutia alama kuwa ujumbe umechakatwa kwa ufanisi

Uundaji wa Kikundi cha Watumiaji

Wacha tuchukue kuwa mkondo wangu tayari upo. Kisha amri ya uundaji wa kikundi itaonekana kama:

> XGROUP CREATE mystream mygroup $
OK

Wakati wa kuunda kikundi, lazima tupitishe kitambulisho, kuanzia ambayo kikundi kitapokea ujumbe. Ikiwa tunataka tu kupokea jumbe zote mpya, basi tunaweza kutumia kitambulisho maalum $ (kama katika mfano wetu hapo juu). Ukitaja 0 badala ya kitambulisho maalum, basi ujumbe wote kwenye thread utapatikana kwa kikundi.

Sasa kwa kuwa kikundi kimeundwa, tunaweza kuanza mara moja kusoma ujumbe kwa kutumia amri XREADGROUP. Amri hii inafanana sana na XREAD na inasaidia chaguo la hiari la KUZUIA. Hata hivyo, kuna chaguo la GROUP linalohitajika ambalo lazima kila wakati libainishwe kwa hoja mbili: jina la kikundi na jina la mteja. Chaguo COUNT pia linatumika.

Kabla ya kusoma thread, hebu tuweke baadhi ya ujumbe hapo:

> 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

Sasa hebu tujaribu kusoma mkondo huu kupitia kikundi:

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

Amri hapo juu inasoma neno kwa neno kama ifuatavyo:

"Mimi, mteja Alice, mwanachama wa kikundi changu, nataka kusoma ujumbe mmoja kutoka kwa mkondo wangu ambao haujawahi kuwasilishwa kwa mtu yeyote hapo awali."

Kila wakati mteja anafanya operesheni kwenye kikundi, lazima atoe jina lake, akijitambulisha kipekee ndani ya kikundi. Kuna maelezo moja muhimu zaidi katika amri iliyo hapo juu - kitambulisho maalum ">". Kitambulishi hiki maalum huchuja ujumbe, na kuacha tu zile ambazo hazijawahi kuwasilishwa hapo awali.

Pia, katika hali maalum, unaweza kubainisha kitambulisho halisi kama vile 0 au kitambulisho kingine chochote halali. Katika kesi hii, amri XREADGROUP itakurudishia historia ya jumbe zenye hali ya "inasubiri" ambazo ziliwasilishwa kwa mteja aliyebainishwa (Alice) lakini bado hazijakubaliwa kwa kutumia amri. XACK.

Tunaweza kujaribu tabia hii kwa kubainisha mara moja kitambulisho 0, bila chaguo COUNT. Tutaona ujumbe mmoja unaosubiri, yaani, ujumbe wa apple:

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

Hata hivyo, ikiwa tutathibitisha ujumbe kama umechakatwa kwa ufanisi, basi hautaonyeshwa tena:

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

Sasa ni zamu ya Bob kusoma kitu:

> 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, mwanachama wa kikundi changu, aliomba si zaidi ya jumbe mbili. Amri huripoti tu ujumbe ambao haujawasilishwa kwa sababu ya kitambulisho maalum ">". Kama unavyoona, ujumbe "apple" hautaonyeshwa kwa vile tayari umeshawasilishwa kwa Alice, hivyo Bob anapokea "machungwa" na "strawberry".

Kwa njia hii, Alice, Bob, na mteja mwingine yeyote kwenye kikundi anaweza kusoma jumbe tofauti kutoka kwa mtiririko huo. Wanaweza pia kusoma historia yao ya ujumbe ambao haujachakatwa au kutia alama kuwa ujumbe umechakatwa.

Kuna mambo machache ya kukumbuka:

  • Mara tu mteja anapozingatia ujumbe kuwa amri XREADGROUP, ujumbe huu huingia katika hali ya "inasubiri" na hukabidhiwa kwa mteja huyo mahususi. Wasajili wengine wa kikundi hawataweza kusoma ujumbe huu.
  • Wasajili huundwa kiotomatiki wanapotajwa mara ya kwanza, hakuna haja ya kuwaunda waziwazi.
  • Pamoja na XREADGROUP unaweza kusoma ujumbe kutoka kwa nyuzi nyingi tofauti kwa wakati mmoja, hata hivyo ili hili lifanye kazi unahitaji kwanza kuunda vikundi vyenye jina sawa kwa kila uzi ukitumia. XGROUP

Ahueni baada ya kushindwa

Msajili anaweza kupata nafuu kutokana na kutofaulu na kusoma tena orodha yake ya ujumbe na hali ya "inasubiri". Walakini, katika ulimwengu wa kweli, waliojiandikisha wanaweza hatimaye kushindwa. Je, ni nini hufanyika kwa ujumbe uliokwama wa mteja ikiwa mteja hawezi kurejesha hali ya kutofaulu?
Kikundi cha Wateja hutoa kipengele ambacho kinatumika kwa matukio kama hayo - wakati unahitaji kubadilisha mmiliki wa ujumbe.

Jambo la kwanza unahitaji kufanya ni kupiga amri XPENDING, ambayo inaonyesha ujumbe wote kwenye kikundi na hali "inasubiri". Kwa njia rahisi zaidi, amri inaitwa kwa hoja mbili tu: jina la thread na jina la kikundi:

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

Timu ilionyesha idadi ya ujumbe ambao haujachakatwa kwa kikundi kizima na kwa kila mteja. Tunaye Bob aliye na jumbe mbili pekee kwa sababu ujumbe pekee ambao Alice aliomba ulithibitishwa XACK.

Tunaweza kuomba maelezo zaidi kwa kutumia hoja zaidi:

XPENDING {key} {groupname} [{start-id} {end-id} {count} [{consumer-name}]]
{start-id} {end-id} - anuwai ya vitambulishi (unaweza kutumia "-" na "+")
{count} - idadi ya majaribio ya kuwasilisha
{consumer-name} - jina la kikundi

> 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

Sasa tuna maelezo kwa kila ujumbe: Kitambulisho, jina la mteja, muda wa kutofanya kitu katika milisekunde na hatimaye idadi ya majaribio ya kuwasilisha. Tuna jumbe mbili kutoka kwa Bob na zimekuwa bila kufanya kazi kwa milisekunde 74170458, kama saa 20.

Tafadhali kumbuka kuwa hakuna mtu anayetuzuia kuangalia maudhui ya ujumbe yalikuwa nini kwa kutumia tu XRANGE.

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

Tunapaswa tu kurudia kitambulisho sawa mara mbili katika hoja. Kwa kuwa sasa tuna wazo fulani, Alice anaweza kuamua kwamba baada ya saa 20 za muda wa kupumzika, Bob hatapona, na ni wakati wa kuuliza barua pepe hizo na kuanza kuzichakata kwa ajili ya Bob. Kwa hili tunatumia amri XCLAIM:

XCLAIM {key} {group} {consumer} {min-idle-time} {ID-1} {ID-2} ... {ID-N}

Kwa kutumia amri hii, tunaweza kupokea ujumbe wa "kigeni" ambao bado haujachakatwa kwa kubadilisha mmiliki hadi {consumer}. Hata hivyo, tunaweza pia kutoa muda wa chini wa kutofanya kitu {min-idle-time}. Hii husaidia kuzuia hali ambapo wateja wawili hujaribu kubadilisha wakati huo huo mmiliki wa ujumbe sawa:

Client 1: XCLAIM mystream mygroup Alice 3600000 1526569498055-0
Clinet 2: XCLAIM mystream mygroup Lora 3600000 1526569498055-0

Mteja wa kwanza ataweka upya muda wa kupungua na kuongeza kihesabu cha uwasilishaji. Kwa hivyo mteja wa pili hataweza kuiomba.

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

Ujumbe huo ulidaiwa na Alice, ambaye sasa anaweza kuchakata ujumbe huo na kuukubali.

Kutoka kwa mfano hapo juu, unaweza kuona kwamba ombi la mafanikio linarudisha yaliyomo ya ujumbe yenyewe. Hata hivyo, hii si lazima. Chaguo la JUSTID linaweza kutumika kurejesha vitambulisho vya ujumbe pekee. Hii ni muhimu ikiwa huna nia ya maelezo ya ujumbe na unataka kuongeza utendaji wa mfumo.

Kaunta ya utoaji

Kaunta unayoona kwenye pato XPENDING ni idadi ya uwasilishaji wa kila ujumbe. Kaunta kama hiyo inaongezwa kwa njia mbili: wakati ujumbe umeombwa kwa mafanikio kupitia XCLAIM au simu inapotumika XREADGROUP.

Ni kawaida kwa baadhi ya ujumbe kuwasilishwa mara nyingi. Jambo kuu ni kwamba ujumbe wote hatimaye kusindika. Wakati mwingine matatizo hutokea wakati wa kuchakata ujumbe kwa sababu ujumbe wenyewe umeharibiwa, au usindikaji wa ujumbe husababisha hitilafu katika msimbo wa kidhibiti. Katika kesi hii, inaweza kugeuka kuwa hakuna mtu atakayeweza kushughulikia ujumbe huu. Kwa kuwa tuna kihesabu cha majaribio ya kuwasilisha, tunaweza kutumia kaunta hii kugundua hali kama hizi. Kwa hivyo, mara tu hesabu ya uwasilishaji inapofikia nambari ya juu unayotaja, labda itakuwa busara zaidi kuweka ujumbe kama huo kwenye uzi mwingine na kutuma arifa kwa msimamizi wa mfumo.

Jimbo la Thread

Timu XINFO kutumika kuomba taarifa mbalimbali kuhusu thread na makundi yake. Kwa mfano, amri ya msingi inaonekana kama hii:

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

Amri iliyo hapo juu inaonyesha maelezo ya jumla kuhusu mtiririko uliobainishwa. Sasa mfano ngumu zaidi:

> 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

Amri iliyo hapo juu inaonyesha habari ya jumla kwa vikundi vyote vya uzi maalum

> 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

Amri iliyo hapo juu inaonyesha habari kwa waliojisajili wote wa mtiririko na kikundi maalum.
Ukisahau syntax ya amri, uliza tu amri yenyewe kwa usaidizi:

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

Kikomo cha Ukubwa wa Mtiririko

Programu nyingi hazitaki kukusanya data kwenye mtiririko milele. Mara nyingi ni muhimu kuwa na idadi ya juu zaidi ya ujumbe unaoruhusiwa kwa kila thread. Katika hali zingine, ni muhimu kuhamisha ujumbe wote kutoka kwa uzi hadi duka lingine linaloendelea wakati saizi maalum ya nyuzi imefikiwa. Unaweza kupunguza ukubwa wa mtiririko kwa kutumia kigezo cha MAXLEN katika amri 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"

Unapotumia MAXLEN, rekodi za zamani hufutwa kiotomatiki zinapofikia urefu maalum, kwa hivyo mkondo una saizi isiyobadilika. Hata hivyo, kupogoa katika kesi hii haitokei kwa njia ya ufanisi zaidi katika kumbukumbu ya Redis. Unaweza kuboresha hali kama ifuatavyo:

XADD mystream MAXLEN ~ 1000 * ... entry fields here ...

The ~ argument katika mfano hapo juu ina maana kwamba si lazima tuweke kikomo urefu wa mtiririko kwa thamani maalum. Katika mfano wetu, hii inaweza kuwa nambari yoyote kubwa kuliko au sawa na 1000 (kwa mfano, 1000, 1010, au 1030). Tumebainisha kwa uwazi kwamba tunataka mtiririko wetu uhifadhi angalau rekodi 1000. Hii inafanya usimamizi wa kumbukumbu kuwa mzuri zaidi ndani ya Redis.

Pia kuna timu tofauti XTRIM, ambayo hufanya vivyo hivyo:

> XTRIM mystream MAXLEN 10

> XTRIM mystream MAXLEN ~ 10

Uhifadhi unaoendelea na urudufishaji

Redis Stream inanakiliwa kwa usawa kwa nodi za watumwa na kuhifadhiwa kwa faili kama AOF (picha ya data yote) na RDB (logi ya shughuli zote za uandishi). Uigaji wa hali ya Vikundi vya Watumiaji pia unatumika. Kwa hiyo, ikiwa ujumbe uko katika hali ya "inasubiri" kwenye node ya bwana, basi kwenye nodes za watumwa ujumbe huu utakuwa na hali sawa.

Kuondoa vipengele vya kibinafsi kutoka kwa mtiririko

Kuna amri maalum ya kufuta ujumbe XDEL. Amri hupata jina la nyuzi ikifuatiwa na vitambulisho vya ujumbe kufutwa:

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

Unapotumia amri hii, unahitaji kuzingatia kwamba kumbukumbu halisi haitatolewa mara moja.

Mitiririko ya urefu wa sifuri

Tofauti kati ya mitiririko na miundo mingine ya data ya Redis ni kwamba wakati miundo mingine ya data haina vipengee ndani yake, kama athari ya upande, muundo wa data yenyewe utaondolewa kwenye kumbukumbu. Kwa hiyo, kwa mfano, seti iliyopangwa itaondolewa kabisa wakati simu ya ZREM itaondoa kipengele cha mwisho. Badala yake, nyuzi zinaruhusiwa kubaki kwenye kumbukumbu hata bila kuwa na vitu vyovyote ndani.

Hitimisho

Redis Stream ni bora kwa kuunda madalali wa ujumbe, foleni za ujumbe, ukataji wa kumbukumbu kwa umoja, na mifumo ya gumzo ya kuhifadhi historia.

Kama nilivyowahi kusema Niklaus Wirth, programu ni algoriti pamoja na miundo ya data, na Redis tayari inakupa zote mbili.

Chanzo: mapenzi.com

Kuongeza maoni