Redis સ્ટ્રીમ એ એક નવો અમૂર્ત ડેટા પ્રકાર છે જે Redis માં આવૃત્તિ 5.0 સાથે રજૂ કરવામાં આવ્યો છે
વૈચારિક રીતે, રેડિસ સ્ટ્રીમ એ એક સૂચિ છે જેમાં તમે એન્ટ્રી ઉમેરી શકો છો. દરેક એન્ટ્રીમાં અનન્ય ઓળખકર્તા હોય છે. મૂળભૂત રીતે, ID આપમેળે જનરેટ થાય છે અને તેમાં ટાઇમસ્ટેમ્પનો સમાવેશ થાય છે. તેથી, તમે સમયાંતરે રેકોર્ડની રેન્જની ક્વેરી કરી શકો છો અથવા સ્ટ્રીમમાં આવતા જ નવો ડેટા પ્રાપ્ત કરી શકો છો, જેમ કે યુનિક્સ "tail -f" આદેશ લોગ ફાઇલ વાંચે છે અને નવા ડેટાની રાહ જોતી વખતે થીજી જાય છે. નોંધ કરો કે બહુવિધ ક્લાયંટ એક જ સમયે એક થ્રેડને સાંભળી શકે છે, જેમ કે ઘણી "ટેલ ​​-એફ" પ્રક્રિયાઓ એકબીજા સાથે વિરોધાભાસ કર્યા વિના એક સાથે ફાઇલ વાંચી શકે છે.

નવા ડેટા પ્રકારના તમામ ફાયદાઓને સમજવા માટે, ચાલો લાંબા સમયથી અસ્તિત્વમાં રહેલા Redis સ્ટ્રક્ચર્સ પર એક ઝડપી નજર કરીએ જે Redis Stream ની કાર્યક્ષમતાને આંશિક રીતે નકલ કરે છે.

Redis PUB/SUB

Redis Pub/Sub એ તમારા કી-વેલ્યુ સ્ટોરમાં પહેલેથી જ બનેલી એક સરળ મેસેજિંગ સિસ્ટમ છે. જો કે, સરળતા કિંમતે આવે છે:

• જો કોઈ કારણસર પ્રકાશક નિષ્ફળ જાય, તો તે તેના બધા સબ્સ્ક્રાઇબર્સ ગુમાવે છે
• પ્રકાશકને તેના તમામ સબ્સ્ક્રાઇબરનું ચોક્કસ સરનામું જાણવાની જરૂર છે
• એક પ્રકાશક તેના સબ્સ્ક્રાઇબર્સને કામ સાથે ઓવરલોડ કરી શકે છે જો ડેટા તેની પ્રક્રિયા કરતાં વધુ ઝડપથી પ્રકાશિત થાય છે
• પ્રકાશન પછી તરત જ પ્રકાશકના બફરમાંથી સંદેશ કાઢી નાખવામાં આવે છે, પછી ભલે તે કેટલા સબ્સ્ક્રાઇબર્સને વિતરિત કરવામાં આવ્યો હોય અને તેઓ આ સંદેશ પર કેટલી ઝડપથી પ્રક્રિયા કરવામાં સક્ષમ હતા.
• બધા સબ્સ્ક્રાઇબર્સને એક જ સમયે સંદેશ પ્રાપ્ત થશે. સબ્સ્ક્રાઇબર્સે પોતે જ કોઈક રીતે સમાન સંદેશ પર પ્રક્રિયા કરવાના ક્રમ પર એકબીજા સાથે સંમત થવું આવશ્યક છે.
• સબ્સ્ક્રાઇબરે સફળતાપૂર્વક સંદેશ પર પ્રક્રિયા કરી છે તેની પુષ્ટિ કરવા માટે કોઈ બિલ્ટ-ઇન મિકેનિઝમ નથી. જો સબ્સ્ક્રાઇબરને કોઈ સંદેશ પ્રાપ્ત થાય છે અને પ્રક્રિયા દરમિયાન ક્રેશ થાય છે, તો પ્રકાશકને તેના વિશે જાણ થશે નહીં.

Redis યાદી

રેડિસ લિસ્ટ એ ડેટા સ્ટ્રક્ચર છે જે રીડ કમાન્ડ્સને બ્લોક કરવાને સપોર્ટ કરે છે. તમે સૂચિની શરૂઆત અથવા અંતથી સંદેશાઓ ઉમેરી અને વાંચી શકો છો. આ રચનાના આધારે, તમે તમારી વિતરિત સિસ્ટમ માટે સારો સ્ટેક અથવા કતાર બનાવી શકો છો, અને મોટાભાગના કિસ્સાઓમાં આ પૂરતું હશે. રેડિસ પબ/સબમાંથી મુખ્ય તફાવતો:

• સંદેશ એક ગ્રાહકને વિતરિત કરવામાં આવે છે. પ્રથમ રીડ-બ્લોક કરેલ ક્લાયંટ પહેલા ડેટા પ્રાપ્ત કરશે.
• ક્લિન્ટે દરેક સંદેશ માટે વાંચવાની ક્રિયા પોતે જ શરૂ કરવી જોઈએ. લિસ્ટ ગ્રાહકો વિશે કશું જ જાણતું નથી.
• સંદેશાઓ ત્યાં સુધી સંગ્રહિત થાય છે જ્યાં સુધી કોઈ તેને વાંચે નહીં અથવા સ્પષ્ટપણે કાઢી નાખે. જો તમે ડિસ્ક પર ડેટા ફ્લશ કરવા માટે રેડિસ સર્વરને ગોઠવો છો, તો સિસ્ટમની વિશ્વસનીયતા નાટકીય રીતે વધે છે.

પ્રવાહનો પરિચય

સ્ટ્રીમમાં એન્ટ્રી ઉમેરી રહ્યા છીએ

ટીમ XADD સ્ટ્રીમમાં નવી એન્ટ્રી ઉમેરે છે. રેકોર્ડ માત્ર એક શબ્દમાળા નથી, તેમાં એક અથવા વધુ કી-વેલ્યુ જોડીનો સમાવેશ થાય છે. આમ, દરેક એન્ટ્રી પહેલેથી જ સંરચિત છે અને CSV ફાઇલના બંધારણને મળતી આવે છે.

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

ઉપરના ઉદાહરણમાં, અમે નામ (કી) "mystream" સાથે સ્ટ્રીમમાં બે ફીલ્ડ ઉમેરીએ છીએ: અનુક્રમે "1234" અને "19.8" મૂલ્યો સાથે "સેન્સર-આઈડી" અને "તાપમાન". બીજી દલીલ તરીકે, આદેશ એક ઓળખકર્તા લે છે જે એન્ટ્રીને સોંપવામાં આવશે - આ ઓળખકર્તા સ્ટ્રીમમાં દરેક એન્ટ્રીને અનન્ય રીતે ઓળખે છે. જો કે, આ કિસ્સામાં અમે * પાસ થયા કારણ કે અમે ઇચ્છીએ છીએ કે Redis અમારા માટે એક નવું ID જનરેટ કરે. દરેક નવા આઈડીમાં વધારો થશે. તેથી, દરેક નવી એન્ટ્રીમાં અગાઉની એન્ટ્રીઓના સંબંધમાં ઉચ્ચ ઓળખકર્તા હશે.

ઓળખકર્તા ફોર્મેટ

આદેશ દ્વારા એન્ટ્રી ID પરત કરવામાં આવ્યું XADD, બે ભાગો સમાવે છે:

{millisecondsTime}-{sequenceNumber}

મિલિસેકંડસમય - યુનિક્સ સમય મિલિસેકંડમાં (રેડીસ સર્વર સમય). જો કે, જો વર્તમાન સમય અગાઉના રેકોર્ડિંગના સમય કરતાં સમાન અથવા ઓછો હોય, તો પછી અગાઉના રેકોર્ડિંગના ટાઇમસ્ટેમ્પનો ઉપયોગ કરવામાં આવે છે. તેથી, જો સર્વરનો સમય સમયસર પાછો જાય છે, તો નવા ઓળખકર્તા હજુ પણ ઇન્ક્રીમેન્ટ પ્રોપર્ટી જાળવી રાખશે.

ક્રમ નંબર સમાન મિલિસેકન્ડમાં બનાવેલા રેકોર્ડ્સ માટે વપરાય છે. ક્રમ નંબર અગાઉની એન્ટ્રીની તુલનામાં 1 દ્વારા વધારો કરવામાં આવશે. કારણ કે ક્રમ નંબર 64 બિટ્સનું કદ છે, તો પછી વ્યવહારમાં તમારે રેકોર્ડ્સની સંખ્યાની મર્યાદામાં ન જવું જોઈએ જે એક મિલિસેકન્ડમાં જનરેટ થઈ શકે.

આવા ઓળખકર્તાઓનું ફોર્મેટ પ્રથમ નજરમાં વિચિત્ર લાગી શકે છે. અવિશ્વાસુ વાચક આશ્ચર્ય પામી શકે છે કે શા માટે સમય ઓળખકર્તાનો ભાગ છે. કારણ એ છે કે Redis સ્ટ્રીમ્સ ID દ્વારા શ્રેણી પ્રશ્નોને સમર્થન આપે છે. ઓળખકર્તા રેકોર્ડ બનાવ્યાના સમય સાથે સંકળાયેલો હોવાથી, આ સમય રેન્જની ક્વેરી કરવાનું શક્ય બનાવે છે. જ્યારે આપણે આદેશને જોઈશું ત્યારે આપણે ચોક્કસ ઉદાહરણ જોઈશું એક્સરેન્જ.

જો કોઈ કારણોસર વપરાશકર્તાને તેના પોતાના ઓળખકર્તાને સ્પષ્ટ કરવાની જરૂર હોય, જે, ઉદાહરણ તરીકે, કેટલીક બાહ્ય સિસ્ટમ સાથે સંકળાયેલ છે, તો અમે તેને આદેશમાં મોકલી શકીએ છીએ. XADD નીચે બતાવ્યા પ્રમાણે *ને બદલે:

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

મહેરબાની કરીને નોંધ કરો કે આ કિસ્સામાં તમારે ID વધારાનું જાતે નિરીક્ષણ કરવું આવશ્યક છે. અમારા ઉદાહરણમાં, ન્યૂનતમ ઓળખકર્તા "0-1" છે, તેથી આદેશ અન્ય ઓળખકર્તાને સ્વીકારશે નહીં જે "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

સ્ટ્રીમ દીઠ રેકોર્ડ્સની સંખ્યા

આદેશનો ઉપયોગ કરીને સ્ટ્રીમમાં રેકોર્ડ્સની સંખ્યા મેળવવી શક્ય છે XLEN. અમારા ઉદાહરણ માટે, આ આદેશ નીચેની કિંમત પરત કરશે:

> XLEN somestream
(integer) 2

શ્રેણી પ્રશ્નો - XRANGE અને XREVRANGE

શ્રેણી દ્વારા ડેટાની વિનંતી કરવા માટે, અમારે બે ઓળખકર્તાઓનો ઉલ્લેખ કરવાની જરૂર છે - શ્રેણીની શરૂઆત અને અંત. પરત કરેલ શ્રેણીમાં સીમાઓ સહિત તમામ ઘટકોનો સમાવેશ થશે. સ્ટ્રીમમાં અનુક્રમે સૌથી નાનો (પ્રથમ રેકોર્ડ) અને સૌથી મોટો (છેલ્લો રેકોર્ડ) ઓળખકર્તા એવા બે વિશિષ્ટ ઓળખકર્તાઓ “-” અને “+” પણ છે. નીચેનું ઉદાહરણ તમામ સ્ટ્રીમ એન્ટ્રીઓની યાદી આપશે.

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

દરેક પરત કરેલ રેકોર્ડ એ બે ઘટકોની શ્રેણી છે: એક ઓળખકર્તા અને કી-વેલ્યુ જોડીની સૂચિ. અમે પહેલેથી જ કહ્યું છે કે રેકોર્ડ ઓળખકર્તા સમય સાથે સંબંધિત છે. તેથી, અમે ચોક્કસ સમયગાળાની શ્રેણીની વિનંતી કરી શકીએ છીએ. જો કે, અમે વિનંતિમાં સંપૂર્ણ ઓળખકર્તા નહીં, પરંતુ માત્ર યુનિક્સ સમયનો ઉલ્લેખ કરી શકીએ છીએ, તેનાથી સંબંધિત ભાગને બાદ કરતાં ક્રમ નંબર. ઓળખકર્તાનો અવગણવામાં આવેલ ભાગ આપમેળે શ્રેણીની શરૂઆતમાં શૂન્ય પર અને શ્રેણીના અંતે મહત્તમ શક્ય મૂલ્ય પર સેટ થઈ જશે. નીચે તમે કેવી રીતે બે મિલીસેકન્ડની શ્રેણીની વિનંતી કરી શકો છો તેનું ઉદાહરણ છે.

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

અમારી પાસે આ શ્રેણીમાં માત્ર એક જ એન્ટ્રી છે, જો કે વાસ્તવિક ડેટા સેટમાં પરત કરવામાં આવેલ પરિણામ વિશાળ હોઈ શકે છે. આ કારણ થી એક્સરેન્જ COUNT વિકલ્પને સપોર્ટ કરે છે. જથ્થાને સ્પષ્ટ કરીને, અમે ફક્ત પ્રથમ N રેકોર્ડ્સ મેળવી શકીએ છીએ. જો અમને આગામી N રેકોર્ડ્સ (પૃષ્ઠ ક્રમાંકન) મેળવવાની જરૂર હોય, તો અમે છેલ્લી પ્રાપ્ત ID નો ઉપયોગ કરી શકીએ છીએ, તેને વધારી શકીએ છીએ ક્રમ નંબર એક દ્વારા અને ફરીથી પૂછો. ચાલો આને નીચેના ઉદાહરણમાં જોઈએ. અમે સાથે 10 તત્વો ઉમેરવાનું શરૂ કરીએ છીએ XADD (ધારી રહ્યા છીએ કે માયસ્ટ્રીમ પહેલેથી જ 10 તત્વોથી ભરેલું હતું). આદેશ દીઠ 2 તત્વો મેળવવાની પુનરાવૃત્તિ શરૂ કરવા માટે, અમે સંપૂર્ણ શ્રેણી સાથે શરૂ કરીએ છીએ પરંતુ 2 ની બરાબર COUNT સાથે.

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

આગામી બે ઘટકો સાથે પુનરાવર્તન ચાલુ રાખવા માટે, અમારે પ્રાપ્ત થયેલ છેલ્લું ID પસંદ કરવાની જરૂર છે, એટલે કે 1519073279157-0, અને તેમાં 1 ઉમેરો ક્રમ નંબર.
પરિણામી ID, આ કિસ્સામાં 1519073279157-1, હવે પછીના કૉલ માટે શ્રેણી દલીલની નવી શરૂઆત તરીકે ઉપયોગ કરી શકાય છે. એક્સરેન્જ:

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

અને તેથી વધુ. કારણ કે જટિલતા એક્સરેન્જ શોધવા માટે O(log(N)) છે અને પછી O(M) એ M તત્વો પરત કરવા માટે છે, તો દરેક પુનરાવર્તન પગલું ઝડપી છે. આમ, મદદથી એક્સરેન્જ સ્ટ્રીમ્સને અસરકારક રીતે પુનરાવર્તિત કરી શકાય છે.

ટીમ XREVRANGE સમકક્ષ છે એક્સરેન્જ, પરંતુ તત્વોને વિપરીત ક્રમમાં પરત કરે છે:

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

મહેરબાની કરીને નોંધ કરો કે આદેશ XREVRANGE શ્રેણીની દલીલો વિપરીત ક્રમમાં શરૂ અને બંધ લે છે.

XREAD નો ઉપયોગ કરીને નવી એન્ટ્રીઓ વાંચવી

ઘણીવાર કાર્ય સ્ટ્રીમ પર સબ્સ્ક્રાઇબ કરવાનું અને ફક્ત નવા સંદેશા પ્રાપ્ત કરવાનું ઉદ્ભવે છે. આ વિભાવના Redis Pub/Sub અથવા Redis સૂચિને અવરોધિત કરવા જેવી લાગે છે, પરંતુ Redis સ્ટ્રીમનો ઉપયોગ કેવી રીતે કરવો તેમાં મૂળભૂત તફાવતો છે:

1. દરેક નવો સંદેશ દરેક સબ્સ્ક્રાઇબરને ડિફોલ્ટ રૂપે વિતરિત કરવામાં આવે છે. આ વર્તણૂક અવરોધિત Redis સૂચિથી અલગ છે, જ્યાં નવો સંદેશ ફક્ત એક સબ્સ્ક્રાઇબર દ્વારા વાંચવામાં આવશે.
2. જ્યારે Redis Pub/Sub માં બધા સંદેશાઓ ભૂલી જાય છે અને ક્યારેય ચાલુ રહેતા નથી, સ્ટ્રીમમાં બધા સંદેશાઓ અનિશ્ચિત સમય માટે જાળવી રાખવામાં આવે છે (સિવાય કે ક્લાયન્ટ સ્પષ્ટપણે કાઢી નાખવાનું કારણ બને).
3. રેડિસ સ્ટ્રીમ તમને એક સ્ટ્રીમમાં સંદેશાઓની ઍક્સેસને અલગ કરવાની મંજૂરી આપે છે. ચોક્કસ સબ્સ્ક્રાઇબર ફક્ત તેમનો વ્યક્તિગત સંદેશ ઇતિહાસ જોઈ શકે છે.

તમે થ્રેડ પર સબ્સ્ક્રાઇબ કરી શકો છો અને આદેશનો ઉપયોગ કરીને નવા સંદેશા પ્રાપ્ત કરી શકો છો XREAD. તે કરતાં થોડી વધુ જટિલ છે એક્સરેન્જ, તેથી અમે પહેલા સરળ ઉદાહરણો સાથે પ્રારંભ કરીશું.

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

ઉપરનું ઉદાહરણ બિન-અવરોધિત સ્વરૂપ બતાવે છે XREAD. નોંધ કરો કે COUNT વિકલ્પ વૈકલ્પિક છે. હકીકતમાં, એકમાત્ર આવશ્યક આદેશ વિકલ્પ સ્ટ્રીમ્સ વિકલ્પ છે, જે અનુરૂપ મહત્તમ ઓળખકર્તા સાથે સ્ટ્રીમ્સની સૂચિનો ઉલ્લેખ કરે છે. અમે "સ્ટ્રીમ્સ માયસ્ટ્રીમ 0" લખ્યું છે - અમે માયસ્ટ્રીમ સ્ટ્રીમના તમામ રેકોર્ડ્સ "0-0" કરતા વધુ ઓળખકર્તા સાથે પ્રાપ્ત કરવા માંગીએ છીએ. જેમ તમે ઉદાહરણ પરથી જોઈ શકો છો, આદેશ થ્રેડનું નામ પરત કરે છે કારણ કે અમે એક જ સમયે બહુવિધ થ્રેડો પર સબ્સ્ક્રાઇબ કરી શકીએ છીએ. ઉદાહરણ તરીકે, આપણે લખી શકીએ છીએ, "STREAMS mystream otherstream 0 0". મહેરબાની કરીને નોંધ કરો કે સ્ટ્રીમ્સ વિકલ્પ પછી અમારે પહેલા તમામ જરૂરી સ્ટ્રીમના નામ અને પછી જ ઓળખકર્તાઓની સૂચિ પ્રદાન કરવાની જરૂર છે.

આ સરળ સ્વરૂપમાં કમાન્ડ તેની સરખામણીમાં કંઈ ખાસ કરતું નથી એક્સરેન્જ. જો કે, રસપ્રદ વાત એ છે કે આપણે સરળતાથી વળાંક આપી શકીએ છીએ XREAD બ્લોકીંગ કમાન્ડ માટે, BLOCK દલીલનો ઉલ્લેખ કરીને:

> XREAD BLOCK 0 STREAMS mystream $

ઉપરના ઉદાહરણમાં, એક નવો બ્લોક વિકલ્પ 0 મિલિસેકન્ડના સમયસમાપ્તિ સાથે સ્પષ્ટ થયેલ છે (આનો અર્થ છે અનિશ્ચિત સમય સુધી રાહ જોવી). વધુમાં, માયસ્ટ્રીમ સ્ટ્રીમ માટે સામાન્ય ઓળખકર્તા પસાર કરવાને બદલે, એક વિશિષ્ટ ઓળખકર્તા $ પસાર કરવામાં આવ્યો હતો. આ વિશિષ્ટ ઓળખકર્તા એટલે કે XREAD ઓળખકર્તા તરીકે mystream માં મહત્તમ ઓળખકર્તાનો ઉપયોગ કરવો આવશ્યક છે. તેથી અમે સાંભળવાનું શરૂ કર્યું ત્યારથી જ નવા સંદેશા પ્રાપ્ત કરીશું. કેટલીક રીતે આ યુનિક્સ "tail -f" આદેશ જેવું જ છે.

નોંધ કરો કે BLOCK વિકલ્પનો ઉપયોગ કરતી વખતે આપણે ખાસ ઓળખકર્તા $ નો ઉપયોગ કરવાની જરૂર નથી. અમે સ્ટ્રીમમાં હાજર કોઈપણ ઓળખકર્તાનો ઉપયોગ કરી શકીએ છીએ. જો ટીમ અમારી વિનંતીને અવરોધિત કર્યા વિના તરત જ સેવા આપી શકે છે, તો તે આમ કરશે, નહીં તો તે અવરોધિત કરશે.

બ્લોકીંગ XREAD એક સાથે બહુવિધ થ્રેડો પણ સાંભળી શકે છે, તમારે ફક્ત તેમના નામો સ્પષ્ટ કરવાની જરૂર છે. આ કિસ્સામાં, આદેશ ડેટા પ્રાપ્ત કરનાર પ્રથમ સ્ટ્રીમનો રેકોર્ડ આપશે. આપેલ થ્રેડ માટે બ્લોક કરેલ પ્રથમ સબ્સ્ક્રાઇબર પ્રથમ ડેટા પ્રાપ્ત કરશે.

ઉપભોક્તા જૂથો

અમુક કાર્યોમાં, અમે એક થ્રેડની અંદરના સંદેશાઓની સબ્સ્ક્રાઇબર ઍક્સેસને મર્યાદિત કરવા માંગીએ છીએ. એક ઉદાહરણ જ્યાં આ ઉપયોગી થઈ શકે છે તે કામદારો સાથેની સંદેશ કતાર છે જે એક થ્રેડમાંથી વિવિધ સંદેશા પ્રાપ્ત કરશે, જે સંદેશની પ્રક્રિયાને સ્કેલ કરવાની મંજૂરી આપશે.

જો આપણે કલ્પના કરીએ કે અમારી પાસે ત્રણ સબ્સ્ક્રાઇબર્સ C1, C2, C3 અને એક થ્રેડ છે જેમાં સંદેશા 1, 2, 3, 4, 5, 6, 7 છે, તો સંદેશાઓ નીચેની રેખાકૃતિની જેમ આપવામાં આવશે:

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

આ અસર હાંસલ કરવા માટે, રેડિસ સ્ટ્રીમ કન્ઝ્યુમર ગ્રુપ નામના કોન્સેપ્ટનો ઉપયોગ કરે છે. આ ખ્યાલ સ્યુડો-સબ્સ્ક્રાઇબર જેવો જ છે, જે સ્ટ્રીમમાંથી ડેટા મેળવે છે, પરંતુ વાસ્તવમાં જૂથમાં બહુવિધ સબ્સ્ક્રાઇબર્સ દ્વારા સેવા આપવામાં આવે છે, જે ચોક્કસ ગેરંટી પૂરી પાડે છે:

1. દરેક સંદેશ જૂથમાં અલગ સબસ્ક્રાઇબરને વિતરિત કરવામાં આવે છે.
2. જૂથની અંદર, સબ્સ્ક્રાઇબર્સને તેમના નામથી ઓળખવામાં આવે છે, જે કેસ-સંવેદનશીલ સ્ટ્રિંગ છે. જો સબ્સ્ક્રાઇબર અસ્થાયી રૂપે જૂથમાંથી બહાર નીકળી જાય છે, તો તેને તેના પોતાના અનન્ય નામનો ઉપયોગ કરીને જૂથમાં પુનઃસ્થાપિત કરી શકાય છે.
3. દરેક ઉપભોક્તા જૂથ "પ્રથમ ન વાંચેલા સંદેશ" ખ્યાલને અનુસરે છે. જ્યારે સબ્સ્ક્રાઇબર નવા સંદેશાઓની વિનંતી કરે છે, ત્યારે તે ફક્ત તે જ સંદેશા પ્રાપ્ત કરી શકે છે જે અગાઉ ક્યારેય જૂથમાંના કોઈપણ સબ્સ્ક્રાઇબરને વિતરિત કરવામાં આવ્યા ન હોય.
4. સ્પષ્ટપણે પુષ્ટિ કરવા માટે એક આદેશ છે કે સબ્સ્ક્રાઇબર દ્વારા સંદેશની સફળતાપૂર્વક પ્રક્રિયા કરવામાં આવી હતી. જ્યાં સુધી આ આદેશને બોલાવવામાં ન આવે ત્યાં સુધી, વિનંતી કરેલ સંદેશ "બાકી" સ્થિતિમાં રહેશે.
5. ઉપભોક્તા જૂથની અંદર, દરેક સબ્સ્ક્રાઇબર તેને વિતરિત કરવામાં આવેલા સંદેશાઓના ઇતિહાસની વિનંતી કરી શકે છે, પરંતુ હજી સુધી પ્રક્રિયા કરવામાં આવી નથી ("બાકી" સ્થિતિમાં)

એક અર્થમાં, જૂથની સ્થિતિ નીચે પ્રમાણે વ્યક્ત કરી શકાય છે:

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

હવે ગ્રાહક જૂથ માટેના મુખ્ય આદેશોથી પરિચિત થવાનો સમય છે, એટલે કે:

• XGROUP જૂથો બનાવવા, નાશ કરવા અને મેનેજ કરવા માટે વપરાય છે
• XREADGROUP જૂથ દ્વારા સ્ટ્રીમ વાંચવા માટે વપરાય છે
• XACK - આ આદેશ સબ્સ્ક્રાઇબરને સંદેશને સફળતાપૂર્વક પ્રક્રિયા કરેલ તરીકે ચિહ્નિત કરવાની મંજૂરી આપે છે

ગ્રાહક જૂથની રચના

ચાલો ધારીએ કે માયસ્ટ્રીમ પહેલેથી જ અસ્તિત્વમાં છે. પછી જૂથ બનાવટ આદેશ આના જેવો દેખાશે:

> XGROUP CREATE mystream mygroup $
OK

જૂથ બનાવતી વખતે, આપણે એક ઓળખકર્તા પાસ કરવું આવશ્યક છે, જેમાંથી જૂથ સંદેશા પ્રાપ્ત કરશે. જો આપણે ફક્ત બધા નવા સંદેશાઓ પ્રાપ્ત કરવા માંગીએ છીએ, તો અમે વિશિષ્ટ ઓળખકર્તા $ નો ઉપયોગ કરી શકીએ છીએ (ઉપરના અમારા ઉદાહરણમાં). જો તમે વિશિષ્ટ ઓળખકર્તાને બદલે 0 નો ઉલ્લેખ કરો છો, તો થ્રેડમાંના બધા સંદેશાઓ જૂથને ઉપલબ્ધ થશે.

હવે જ્યારે જૂથ બનાવવામાં આવ્યું છે, અમે આદેશનો ઉપયોગ કરીને તરત જ સંદેશા વાંચવાનું શરૂ કરી શકીએ છીએ XREADGROUP. આ આદેશ ખૂબ સમાન છે XREAD અને વૈકલ્પિક બ્લોક વિકલ્પને સપોર્ટ કરે છે. જો કે, ત્યાં એક આવશ્યક GROUP વિકલ્પ છે જે હંમેશા બે દલીલો સાથે સ્પષ્ટ થયેલ હોવો જોઈએ: જૂથનું નામ અને ગ્રાહકનું નામ. COUNT વિકલ્પ પણ સમર્થિત છે.

થ્રેડ વાંચતા પહેલા, ચાલો ત્યાં કેટલાક સંદેશાઓ મૂકીએ:

> 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

હવે આ સ્ટ્રીમને ગ્રુપ દ્વારા વાંચવાનો પ્રયાસ કરીએ:

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

ઉપરોક્ત આદેશ નીચે પ્રમાણે શબ્દશઃ વાંચે છે:

"હું, સબ્સ્ક્રાઇબર એલિસ, માયગ્રુપના સભ્ય, માયસ્ટ્રીમમાંથી એક સંદેશ વાંચવા માંગુ છું જે અગાઉ ક્યારેય કોઈને વિતરિત કરવામાં આવ્યો નથી."

દરેક વખતે જ્યારે સબ્સ્ક્રાઇબર જૂથ પર ઑપરેશન કરે છે, ત્યારે તેણે તેનું નામ પ્રદાન કરવું આવશ્યક છે, જૂથમાં પોતાની જાતને વિશિષ્ટ રીતે ઓળખી કાઢે છે. ઉપરોક્ત આદેશમાં એક વધુ મહત્વપૂર્ણ વિગત છે - વિશેષ ઓળખકર્તા ">". આ વિશિષ્ટ ઓળખકર્તા સંદેશાઓને ફિલ્ટર કરે છે, ફક્ત તે જ છોડી દે છે જે પહેલાં ક્યારેય વિતરિત થયા નથી.

ઉપરાંત, ખાસ કિસ્સાઓમાં, તમે વાસ્તવિક ઓળખકર્તાનો ઉલ્લેખ કરી શકો છો જેમ કે 0 અથવા કોઈપણ અન્ય માન્ય ઓળખકર્તા. આ કિસ્સામાં આદેશ XREADGROUP તમને "બાકી" ની સ્થિતિ સાથેના સંદેશાઓનો ઇતિહાસ પરત કરશે જે ઉલ્લેખિત સબ્સ્ક્રાઇબર (એલિસ)ને વિતરિત કરવામાં આવ્યા હતા પરંતુ આદેશનો ઉપયોગ કરીને હજુ સુધી સ્વીકારવામાં આવ્યા નથી. XACK.

અમે વિકલ્પ વિના તરત જ ID 0 નો ઉલ્લેખ કરીને આ વર્તનને ચકાસી શકીએ છીએ COUNT. આપણે ફક્ત એક જ પેન્ડિંગ મેસેજ જોશું, એટલે કે એપલ મેસેજ:

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

જો કે, જો અમે સંદેશને સફળતાપૂર્વક પ્રક્રિયા કર્યાની પુષ્ટિ કરીએ છીએ, તો તે હવે પ્રદર્શિત થશે નહીં:

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

હવે કંઈક વાંચવાનો વારો બોબનો છે:

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

બોબે, માયગ્રુપના સભ્ય, બે કરતાં વધુ સંદેશાઓ માટે પૂછ્યું નહીં. આદેશ ફક્ત વિશિષ્ટ ઓળખકર્તા ">" ને કારણે અવિતરિત સંદેશાઓની જાણ કરે છે. જેમ તમે જોઈ શકો છો, "સફરજન" સંદેશ પ્રદર્શિત થશે નહીં કારણ કે તે એલિસને પહેલેથી જ વિતરિત કરવામાં આવ્યો છે, તેથી બોબને "નારંગી" અને "સ્ટ્રોબેરી" પ્રાપ્ત થાય છે.

આ રીતે, એલિસ, બોબ અને જૂથના કોઈપણ અન્ય સબ્સ્ક્રાઇબર એક જ સ્ટ્રીમમાંથી વિવિધ સંદેશા વાંચી શકે છે. તેઓ તેમના બિનપ્રક્રિયા કરેલા સંદેશાઓનો ઇતિહાસ પણ વાંચી શકે છે અથવા સંદેશાઓને પ્રક્રિયા કરેલા તરીકે ચિહ્નિત કરી શકે છે.

ધ્યાનમાં રાખવા જેવી કેટલીક બાબતો છે:

• જલદી ગ્રાહક સંદેશને આદેશ માને છે XREADGROUP, આ સંદેશ "બાકી" સ્થિતિમાં જાય છે અને તે ચોક્કસ સબ્સ્ક્રાઇબરને સોંપવામાં આવે છે. અન્ય જૂથ સબ્સ્ક્રાઇબર્સ આ સંદેશ વાંચી શકશે નહીં.
• પ્રથમ ઉલ્લેખ પર સબ્સ્ક્રાઇબર્સ આપમેળે બનાવવામાં આવે છે, તેમને સ્પષ્ટપણે બનાવવાની જરૂર નથી.
• ની મદદ સાથે XREADGROUP તમે એક જ સમયે બહુવિધ વિવિધ થ્રેડોના સંદેશાઓ વાંચી શકો છો, જો કે આ કામ કરવા માટે તમારે પહેલા દરેક થ્રેડ માટે સમાન નામ સાથે જૂથો બનાવવાની જરૂર છે XGROUP

નિષ્ફળતા પછી પુનઃપ્રાપ્તિ

સબ્સ્ક્રાઇબર નિષ્ફળતામાંથી પુનઃપ્રાપ્ત થઈ શકે છે અને "બાકી" સ્થિતિ સાથે તેના સંદેશાઓની સૂચિ ફરીથી વાંચી શકે છે. જો કે, વાસ્તવિક દુનિયામાં, સબ્સ્ક્રાઇબર્સ આખરે નિષ્ફળ થઈ શકે છે. જો સબ્સ્ક્રાઇબર નિષ્ફળતામાંથી પુનઃપ્રાપ્ત કરવામાં અસમર્થ હોય તો સબ્સ્ક્રાઇબરના અટકેલા સંદેશાઓનું શું થાય છે?
કન્ઝ્યુમર ગ્રૂપ એક સુવિધા આપે છે જેનો ઉપયોગ ફક્ત આવા કિસ્સાઓમાં થાય છે - જ્યારે તમારે સંદેશાઓના માલિકને બદલવાની જરૂર હોય.

તમારે જે પ્રથમ વસ્તુ કરવાની જરૂર છે તે આદેશને કૉલ કરો XPENDING, જે જૂથના તમામ સંદેશાઓને "બાકી" સ્થિતિ સાથે દર્શાવે છે. તેના સરળ સ્વરૂપમાં, આદેશને માત્ર બે દલીલો સાથે બોલાવવામાં આવે છે: થ્રેડનું નામ અને જૂથનું નામ:

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

ટીમે સમગ્ર જૂથ માટે અને દરેક સબ્સ્ક્રાઇબર માટે બિનપ્રક્રિયા ન કરેલા સંદેશાઓની સંખ્યા પ્રદર્શિત કરી. અમારી પાસે ફક્ત બે બાકી સંદેશાઓ સાથે બોબ છે કારણ કે એલિસ દ્વારા વિનંતી કરાયેલ એકમાત્ર સંદેશની પુષ્ટિ કરવામાં આવી હતી XACK.

અમે વધુ દલીલોનો ઉપયોગ કરીને વધુ માહિતીની વિનંતી કરી શકીએ છીએ:

XPENDING {key} {groupname} [{start-id} {end-id} {count} [{consumer-name}]]
{start-id} {end-id} - ઓળખકર્તાઓની શ્રેણી (તમે “-” અને “+” નો ઉપયોગ કરી શકો છો)
{count} — વિતરણ પ્રયાસોની સંખ્યા
{consumer-name} - જૂથનું નામ

> 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

હવે અમારી પાસે દરેક સંદેશાની વિગતો છે: ID, સબ્સ્ક્રાઇબરનું નામ, નિષ્ક્રિય સમય મિલિસેકન્ડમાં અને અંતે ડિલિવરી પ્રયાસોની સંખ્યા. અમારી પાસે બોબના બે સંદેશા છે અને તે લગભગ 74170458 કલાક, 20 મિલિસેકન્ડ માટે નિષ્ક્રિય છે.

મહેરબાની કરીને નોંધ કરો કે ફક્ત ઉપયોગ કરીને સંદેશની સામગ્રી શું હતી તે તપાસવાથી અમને કોઈ રોકતું નથી એક્સરેન્જ.

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

આપણે ફક્ત દલીલોમાં સમાન ઓળખકર્તાને બે વાર પુનરાવર્તન કરવું પડશે. હવે અમને થોડો ખ્યાલ આવી ગયો છે, એલિસ નક્કી કરી શકે છે કે 20 કલાકના ડાઉનટાઇમ પછી, બોબ કદાચ પુનઃપ્રાપ્ત થશે નહીં, અને તે સંદેશાઓની પૂછપરછ કરવાનો અને બોબ માટે તેની પ્રક્રિયા ફરી શરૂ કરવાનો સમય છે. આ માટે આપણે આદેશનો ઉપયોગ કરીએ છીએ XCLAIM:

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

આ આદેશનો ઉપયોગ કરીને, અમે એક "વિદેશી" સંદેશ પ્રાપ્ત કરી શકીએ છીએ જે માલિકને {ગ્રાહક}માં બદલીને હજુ સુધી પ્રક્રિયા કરવામાં આવી નથી. જો કે, અમે ન્યૂનતમ નિષ્ક્રિય સમય {min-idle-time} પણ આપી શકીએ છીએ. આ એવી પરિસ્થિતિને ટાળવામાં મદદ કરે છે કે જ્યાં બે ક્લાયન્ટ્સ એકસાથે સમાન સંદેશાના માલિકને બદલવાનો પ્રયાસ કરે છે:

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

પ્રથમ ગ્રાહક ડાઉનટાઇમ રીસેટ કરશે અને ડિલિવરી કાઉન્ટર વધારશે. તેથી બીજો ક્લાયંટ તેની વિનંતી કરી શકશે નહીં.

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

એલિસ દ્વારા સંદેશનો સફળતાપૂર્વક દાવો કરવામાં આવ્યો હતો, જે હવે સંદેશ પર પ્રક્રિયા કરી શકે છે અને તેને સ્વીકારી શકે છે.

ઉપરોક્ત ઉદાહરણમાંથી, તમે જોઈ શકો છો કે સફળ વિનંતી સંદેશની સામગ્રીઓ પરત કરે છે. જો કે, આ જરૂરી નથી. JUSTID વિકલ્પનો ઉપયોગ ફક્ત મેસેજ ID પરત કરવા માટે થઈ શકે છે. જો તમને સંદેશની વિગતોમાં રસ ન હોય અને સિસ્ટમની કામગીરી વધારવા માંગતા હોવ તો આ ઉપયોગી છે.

ડિલિવરી કાઉન્ટર

તમે આઉટપુટમાં જે કાઉન્ટર જુઓ છો XPENDING દરેક સંદેશના વિતરણની સંખ્યા છે. આવા કાઉન્ટરને બે રીતે વધારવામાં આવે છે: જ્યારે સંદેશ દ્વારા સફળતાપૂર્વક વિનંતી કરવામાં આવે છે XCLAIM અથવા જ્યારે કૉલનો ઉપયોગ કરવામાં આવે છે XREADGROUP.

કેટલાક સંદેશાઓ ઘણી વખત વિતરિત થાય તે સામાન્ય છે. મુખ્ય વસ્તુ એ છે કે બધા સંદેશાઓ આખરે પ્રક્રિયા કરવામાં આવે છે. સંદેશની પ્રક્રિયા કરતી વખતે કેટલીકવાર સમસ્યાઓ થાય છે કારણ કે સંદેશ પોતે જ દૂષિત છે, અથવા સંદેશની પ્રક્રિયા હેન્ડલર કોડમાં ભૂલનું કારણ બને છે. આ કિસ્સામાં, તે ચાલુ થઈ શકે છે કે કોઈ પણ આ સંદેશ પર પ્રક્રિયા કરી શકશે નહીં. અમારી પાસે ડિલિવરી પ્રયાસ કાઉન્ટર હોવાથી, અમે આવી પરિસ્થિતિઓને શોધવા માટે આ કાઉન્ટરનો ઉપયોગ કરી શકીએ છીએ. તેથી, એકવાર ડિલિવરી કાઉન્ટ તમારા ઉલ્લેખિત ઉચ્ચ નંબર પર પહોંચી જાય, પછી આવા સંદેશને બીજા થ્રેડ પર મૂકવો અને સિસ્ટમ એડમિનિસ્ટ્રેટરને સૂચના મોકલવી તે કદાચ વધુ સમજદાર રહેશે.

થ્રેડ રાજ્ય

ટીમ XINFO થ્રેડ અને તેના જૂથો વિશે વિવિધ માહિતીની વિનંતી કરવા માટે વપરાય છે. ઉદાહરણ તરીકે, મૂળભૂત આદેશ આના જેવો દેખાય છે:

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

ઉપરનો આદેશ ઉલ્લેખિત સ્ટ્રીમ વિશે સામાન્ય માહિતી દર્શાવે છે. હવે થોડું વધુ જટિલ ઉદાહરણ:

> 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

ઉપરનો આદેશ ઉલ્લેખિત થ્રેડના તમામ જૂથો માટે સામાન્ય માહિતી દર્શાવે છે

> 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

ઉપરનો આદેશ ઉલ્લેખિત સ્ટ્રીમ અને જૂથના તમામ સબ્સ્ક્રાઇબર્સ માટેની માહિતી દર્શાવે છે.
જો તમે આદેશ વાક્યરચના ભૂલી જાઓ છો, તો ફક્ત આદેશને જ મદદ માટે પૂછો:

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

સ્ટ્રીમ કદ મર્યાદા

ઘણી એપ્લિકેશનો કાયમ માટે સ્ટ્રીમમાં ડેટા એકત્રિત કરવા માંગતી નથી. દરેક થ્રેડ દીઠ મહત્તમ સંખ્યામાં સંદેશાઓને મંજૂરી આપવી તે ઘણીવાર ઉપયોગી છે. અન્ય કિસ્સાઓમાં, જ્યારે નિર્દિષ્ટ થ્રેડનું કદ પહોંચી જાય ત્યારે તમામ સંદેશાઓને થ્રેડમાંથી બીજા પર્સિસ્ટન્ટ સ્ટોરમાં ખસેડવા તે ઉપયોગી છે. તમે આદેશમાં MAXLEN પેરામીટરનો ઉપયોગ કરીને સ્ટ્રીમના કદને મર્યાદિત કરી શકો છો XADD:

> XADD mystream MAXLEN 2 * value 1
1526654998691-0
> XADD mystream MAXLEN 2 * value 2
1526654999635-0
> XADD mystream MAXLEN 2 * value 3
1526655000369-0
> XLEN mystream
(integer) 2
> XRANGE mystream - +
1) 1) 1526654999635-0
   2) 1) "value"
      2) "2"
2) 1) 1526655000369-0
   2) 1) "value"
      2) "3"

MAXLEN નો ઉપયોગ કરતી વખતે, જૂના રેકોર્ડ્સ જ્યારે નિર્દિષ્ટ લંબાઈ સુધી પહોંચે છે ત્યારે તે આપમેળે કાઢી નાખવામાં આવે છે, તેથી સ્ટ્રીમનું કદ સતત હોય છે. જો કે, આ કિસ્સામાં કાપણી રેડિસ મેમરીમાં સૌથી અસરકારક રીતે થતી નથી. તમે નીચેની રીતે પરિસ્થિતિ સુધારી શકો છો:

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

ઉપરના ઉદાહરણમાં ~ દલીલનો અર્થ એ છે કે આપણે સ્ટ્રીમની લંબાઈને ચોક્કસ મૂલ્ય સુધી મર્યાદિત કરવાની જરૂર નથી. અમારા ઉદાહરણમાં, આ 1000 (ઉદાહરણ તરીકે, 1000, 1010, અથવા 1030) કરતાં મોટી અથવા તેની સમાન કોઈપણ સંખ્યા હોઈ શકે છે. અમે હમણાં જ સ્પષ્ટપણે ઉલ્લેખ કર્યો છે કે અમે ઇચ્છીએ છીએ કે અમારી સ્ટ્રીમ ઓછામાં ઓછા 1000 રેકોર્ડ સ્ટોર કરે. આ રેડિસની અંદર મેમરી મેનેજમેન્ટને વધુ કાર્યક્ષમ બનાવે છે.

એક અલગ ટીમ પણ છે XTRIM, જે સમાન કાર્ય કરે છે:

> XTRIM mystream MAXLEN 10

> XTRIM mystream MAXLEN ~ 10


સતત સંગ્રહ અને નકલ

રેડિસ સ્ટ્રીમ અસુમેળ રીતે સ્લેવ નોડ્સ પર નકલ કરવામાં આવે છે અને AOF (બધા ડેટાનો સ્નેપશોટ) અને RDB (બધા લેખન કામગીરીનો લોગ) જેવી ફાઇલોમાં સાચવવામાં આવે છે. ઉપભોક્તા જૂથોની રાજ્યની નકલ પણ સમર્થિત છે. તેથી, જો કોઈ સંદેશ માસ્ટર નોડ પર "બાકી" સ્થિતિમાં હોય, તો પછી સ્લેવ નોડ પર આ સંદેશ સમાન સ્થિતિ ધરાવે છે.

સ્ટ્રીમમાંથી વ્યક્તિગત ઘટકોને દૂર કરી રહ્યાં છીએ

સંદેશાઓ કાઢી નાખવા માટે એક ખાસ આદેશ છે XDEL. આદેશને થ્રેડનું નામ મળે છે જેના પછી મેસેજ ID કાઢી નાખવામાં આવે છે:

> XRANGE mystream - + COUNT 2
1) 1) 1526654999635-0
   2) 1) "value"
      2) "2"
2) 1) 1526655000369-0
   2) 1) "value"
      2) "3"
> XDEL mystream 1526654999635-0
(integer) 1
> XRANGE mystream - + COUNT 2
1) 1) 1526655000369-0
   2) 1) "value"
      2) "3"

આ આદેશનો ઉપયોગ કરતી વખતે, તમારે ધ્યાનમાં લેવાની જરૂર છે કે વાસ્તવિક મેમરી તરત જ રિલીઝ થશે નહીં.

શૂન્ય લંબાઈ સ્ટ્રીમ્સ

સ્ટ્રીમ્સ અને અન્ય રેડિસ ડેટા સ્ટ્રક્ચર્સ વચ્ચેનો તફાવત એ છે કે જ્યારે અન્ય ડેટા સ્ટ્રક્ચર્સમાં હવે ઘટકો નથી, તો આડ અસર તરીકે, ડેટા સ્ટ્રક્ચર પોતે મેમરીમાંથી દૂર થઈ જશે. તેથી, ઉદાહરણ તરીકે, જ્યારે ZREM કૉલ છેલ્લા ઘટકને દૂર કરશે ત્યારે સૉર્ટ કરેલ સેટ સંપૂર્ણપણે દૂર કરવામાં આવશે. તેના બદલે, થ્રેડોને અંદર કોઈપણ ઘટકો વિના પણ મેમરીમાં રહેવાની મંજૂરી છે.

નિષ્કર્ષ

રેડિસ સ્ટ્રીમ મેસેજ બ્રોકર્સ, મેસેજ ક્યુ, યુનિફાઈડ લોગિંગ અને હિસ્ટ્રી-કીપિંગ ચેટ સિસ્ટમ્સ બનાવવા માટે આદર્શ છે.

જેમ મેં એકવાર કહ્યું હતું નિક્લસ વિર્થ, પ્રોગ્રામ્સ એલ્ગોરિધમ્સ વત્તા ડેટા સ્ટ્રક્ચર્સ છે, અને Redis પહેલેથી જ તમને બંને આપે છે.

સોર્સ: www.habr.com