రెడిస్ స్ట్రీమ్ అనేది రెడిస్‌లో వెర్షన్ 5.0తో పరిచయం చేయబడిన కొత్త అబ్‌స్ట్రాక్ట్ డేటా రకం
సంభావితంగా, Redis స్ట్రీమ్ అనేది మీరు ఎంట్రీలను జోడించగల జాబితా. ప్రతి ఎంట్రీకి ప్రత్యేకమైన ఐడెంటిఫైయర్ ఉంటుంది. డిఫాల్ట్‌గా, ID స్వయంచాలకంగా రూపొందించబడుతుంది మరియు టైమ్‌స్టాంప్‌ను కలిగి ఉంటుంది. అందువల్ల, మీరు కాలక్రమేణా రికార్డుల శ్రేణులను ప్రశ్నించవచ్చు లేదా స్ట్రీమ్‌లో వచ్చిన కొత్త డేటాను స్వీకరించవచ్చు, Unix "tail -f" కమాండ్ లాగ్ ఫైల్‌ను రీడ్ చేస్తుంది మరియు కొత్త డేటా కోసం వేచి ఉన్నప్పుడు స్తంభింపజేస్తుంది. అనేక క్లయింట్‌లు ఒకే సమయంలో థ్రెడ్‌ను వినగలరని గమనించండి, అనేక "tail -f" ప్రక్రియలు ఒకదానితో ఒకటి వైరుధ్యం లేకుండా ఏకకాలంలో ఫైల్‌ను చదవగలవు.

కొత్త డేటా రకం యొక్క అన్ని ప్రయోజనాలను అర్థం చేసుకోవడానికి, Redis స్ట్రీమ్ యొక్క కార్యాచరణను పాక్షికంగా ప్రతిబింబించే దీర్ఘకాలంగా ఉన్న Redis నిర్మాణాలను త్వరగా పరిశీలిద్దాం.

Redis PUB/SUB

Redis Pub/Sub అనేది మీ కీ-విలువ స్టోర్‌లో ఇప్పటికే నిర్మించబడిన ఒక సాధారణ సందేశ వ్యవస్థ. అయితే, సరళత ఖర్చుతో వస్తుంది:

• కొన్ని కారణాల వల్ల ప్రచురణకర్త విఫలమైతే, అతను తన చందాదారులందరినీ కోల్పోతాడు
• ప్రచురణకర్త దాని చందాదారులందరి ఖచ్చితమైన చిరునామాను తెలుసుకోవాలి
• డేటా ప్రాసెస్ చేయబడిన దానికంటే వేగంగా పబ్లిష్ చేయబడితే, ప్రచురణకర్త తన సబ్‌స్క్రైబర్‌లను పనితో ఓవర్‌లోడ్ చేయవచ్చు
• ఎంత మంది సబ్‌స్క్రైబర్‌లకు డెలివరీ చేయబడింది మరియు ఎంత త్వరగా వారు ఈ సందేశాన్ని ప్రాసెస్ చేయగలిగారు అనే దానితో సంబంధం లేకుండా, ప్రచురణ అయిన వెంటనే ప్రచురణకర్త బఫర్ నుండి సందేశం తొలగించబడుతుంది.
• అందరు సబ్‌స్క్రైబర్‌లు ఒకే సమయంలో సందేశాన్ని అందుకుంటారు. అదే సందేశాన్ని ప్రాసెస్ చేసే క్రమంలో చందాదారులు తమలో తాము ఏదో ఒకవిధంగా అంగీకరించాలి.
• సబ్‌స్క్రైబర్ సందేశాన్ని విజయవంతంగా ప్రాసెస్ చేసినట్లు నిర్ధారించడానికి అంతర్నిర్మిత విధానం లేదు. సబ్‌స్క్రైబర్‌కి మెసేజ్ వచ్చి ప్రాసెస్ చేస్తున్నప్పుడు క్రాష్ అయినట్లయితే, దాని గురించి ప్రచురణకర్తకు తెలియదు.

రెడిస్ జాబితా

Redis జాబితా అనేది రీడ్ కమాండ్‌లను నిరోధించడాన్ని సపోర్ట్ చేసే డేటా స్ట్రక్చర్. మీరు జాబితా ప్రారంభంలో లేదా చివరి నుండి సందేశాలను జోడించవచ్చు మరియు చదవవచ్చు. ఈ నిర్మాణం ఆధారంగా, మీరు మీ పంపిణీ వ్యవస్థ కోసం మంచి స్టాక్ లేదా క్యూను తయారు చేయవచ్చు మరియు చాలా సందర్భాలలో ఇది సరిపోతుంది. Redis పబ్/సబ్ నుండి ప్రధాన తేడాలు:

• సందేశం ఒక క్లయింట్‌కు పంపిణీ చేయబడుతుంది. మొదటి రీడ్-బ్లాక్ చేయబడిన క్లయింట్ మొదట డేటాను స్వీకరిస్తుంది.
• క్లింట్ తప్పనిసరిగా ప్రతి సందేశానికి రీడ్ ఆపరేషన్‌ను ప్రారంభించాలి. ఖాతాదారుల గురించి జాబితా ఏమీ తెలియదు.
• ఎవరైనా వాటిని చదివే వరకు లేదా స్పష్టంగా తొలగించే వరకు సందేశాలు నిల్వ చేయబడతాయి. మీరు డిస్క్‌కు డేటాను ఫ్లష్ చేయడానికి Redis సర్వర్‌ను కాన్ఫిగర్ చేస్తే, సిస్టమ్ యొక్క విశ్వసనీయత నాటకీయంగా పెరుగుతుంది.

స్ట్రీమ్ పరిచయం

స్ట్రీమ్‌కి ఎంట్రీని జోడిస్తోంది

జట్టు XADD స్ట్రీమ్‌కి కొత్త ఎంట్రీని జోడిస్తుంది. రికార్డ్ అనేది స్ట్రింగ్ మాత్రమే కాదు, ఇది ఒకటి లేదా అంతకంటే ఎక్కువ కీ-విలువ జతలను కలిగి ఉంటుంది. అందువలన, ప్రతి ఎంట్రీ ఇప్పటికే నిర్మాణాత్మకంగా ఉంది మరియు CSV ఫైల్ యొక్క నిర్మాణాన్ని పోలి ఉంటుంది.

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

ఎగువ ఉదాహరణలో, మేము స్ట్రీమ్‌కు రెండు ఫీల్డ్‌లను (కీ) “మైస్ట్రీమ్” పేరుతో జోడిస్తాము: “సెన్సార్-ఐడి” మరియు “ఉష్ణోగ్రత” వరుసగా “1234” మరియు “19.8” విలువలతో. రెండవ వాదన వలె, కమాండ్ ఎంట్రీకి కేటాయించబడే ఐడెంటిఫైయర్‌ను తీసుకుంటుంది - ఈ ఐడెంటిఫైయర్ స్ట్రీమ్‌లోని ప్రతి ఎంట్రీని ప్రత్యేకంగా గుర్తిస్తుంది. అయితే, ఈ సందర్భంలో మేము * పాస్ చేసాము ఎందుకంటే Redis మా కోసం కొత్త IDని రూపొందించాలని మేము కోరుకుంటున్నాము. ప్రతి కొత్త ID పెరుగుతుంది. కాబట్టి, ప్రతి కొత్త ఎంట్రీకి మునుపటి ఎంట్రీలకు సంబంధించి అధిక ఐడెంటిఫైయర్ ఉంటుంది.

ఐడెంటిఫైయర్ ఫార్మాట్

కమాండ్ ద్వారా ఎంట్రీ ID తిరిగి ఇవ్వబడింది XADD, రెండు భాగాలను కలిగి ఉంటుంది:

{millisecondsTime}-{sequenceNumber}

మిల్లీసెకన్ల సమయం — మిల్లీసెకన్లలో Unix సమయం (Redis సర్వర్ సమయం). అయితే, ప్రస్తుత సమయం అదే లేదా మునుపటి రికార్డింగ్ సమయం కంటే తక్కువగా ఉంటే, మునుపటి రికార్డింగ్ టైమ్‌స్టాంప్ ఉపయోగించబడుతుంది. అందువల్ల, సర్వర్ సమయం సమయానికి తిరిగి వెళితే, కొత్త ఐడెంటిఫైయర్ ఇప్పటికీ ఇంక్రిమెంట్ ప్రాపర్టీని కలిగి ఉంటుంది.

క్రమం సంఖ్య అదే మిల్లీసెకన్లలో సృష్టించబడిన రికార్డుల కోసం ఉపయోగించబడుతుంది. క్రమం సంఖ్య మునుపటి ఎంట్రీకి సంబంధించి 1 పెంచబడుతుంది. ఎందుకంటే క్రమం సంఖ్య 64 బిట్‌ల పరిమాణంలో ఉంటుంది, ఆపై ఆచరణలో మీరు ఒక మిల్లీసెకన్‌లో సృష్టించగల రికార్డుల సంఖ్యపై పరిమితిని అమలు చేయకూడదు.

అటువంటి ఐడెంటిఫైయర్ల ఆకృతి మొదటి చూపులో వింతగా అనిపించవచ్చు. ఐడెంటిఫైయర్‌లో సమయం ఎందుకు భాగమని అపనమ్మకం ఉన్న పాఠకుడు ఆశ్చర్యపోవచ్చు. కారణం Redis స్ట్రీమ్‌లు ID ద్వారా శ్రేణి ప్రశ్నలకు మద్దతు ఇస్తాయి. ఐడెంటిఫైయర్ రికార్డ్ సృష్టించబడిన సమయంతో అనుబంధించబడినందున, ఇది సమయ పరిధులను ప్రశ్నించడం సాధ్యం చేస్తుంది. మేము ఆదేశాన్ని చూసినప్పుడు మేము ఒక నిర్దిష్ట ఉదాహరణను పరిశీలిస్తాము XRANGE.

కొన్ని కారణాల వల్ల వినియోగదారు తన స్వంత ఐడెంటిఫైయర్‌ను పేర్కొనవలసి వస్తే, ఉదాహరణకు, కొన్ని బాహ్య సిస్టమ్‌తో అనుబంధించబడినట్లయితే, మేము దానిని ఆదేశానికి పంపవచ్చు. 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"

ప్రతి రిటర్న్ చేసిన రికార్డ్ రెండు మూలకాల శ్రేణి: ఐడెంటిఫైయర్ మరియు కీ-విలువ జతల జాబితా. రికార్డ్ ఐడెంటిఫైయర్‌లు సమయానికి సంబంధించినవని మేము ఇప్పటికే చెప్పాము. కాబట్టి, మేము నిర్దిష్ట కాల వ్యవధిని అభ్యర్థించవచ్చు. అయితే, మేము అభ్యర్థనలో పూర్తి ఐడెంటిఫైయర్‌ను కాకుండా, Unix సమయాన్ని మాత్రమే పేర్కొనవచ్చు, దీనికి సంబంధించిన భాగాన్ని వదిలివేస్తాము క్రమం సంఖ్య. ఐడెంటిఫైయర్ యొక్క విస్మరించబడిన భాగం స్వయంచాలకంగా పరిధి ప్రారంభంలో సున్నాకి మరియు పరిధి చివరిలో సాధ్యమయ్యే గరిష్ట విలువకు సెట్ చేయబడుతుంది. మీరు రెండు మిల్లీసెకన్ల పరిధిని ఎలా అభ్యర్థించవచ్చు అనేదానికి దిగువ ఉదాహరణ.

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

మేము ఈ పరిధిలో ఒక ఎంట్రీని మాత్రమే కలిగి ఉన్నాము, అయితే నిజమైన డేటా సెట్‌లలో తిరిగి వచ్చిన ఫలితం భారీగా ఉంటుంది. ఈ కారణంగా XRANGE 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:

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

మరియు అందువలన న. ఎందుకంటే సంక్లిష్టత XRANGE శోధించడానికి O(log(N)) ఆపై M మూలకాలను అందించడానికి O(M), ఆపై ప్రతి పునరావృత దశ వేగంగా ఉంటుంది. అందువలన, ఉపయోగించడం XRANGE స్ట్రీమ్‌లను సమర్థవంతంగా పునరావృతం చేయవచ్చు.

జట్టు XREVRANGE సమానమైనది XRANGE, కానీ మూలకాలను రివర్స్ ఆర్డర్‌లో అందిస్తుంది:

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

ఆదేశం దయచేసి గమనించండి XREVRANGE శ్రేణి ఆర్గ్యుమెంట్‌లను రివర్స్ ఆర్డర్‌లో స్టార్ట్ మరియు స్టాప్ తీసుకుంటుంది.

XREADని ఉపయోగించి కొత్త ఎంట్రీలను చదవడం

స్ట్రీమ్‌కు సభ్యత్వాన్ని పొందడం మరియు కొత్త సందేశాలను మాత్రమే స్వీకరించడం తరచుగా పని. ఈ కాన్సెప్ట్ Redis Pub/Sub లేదా Redis Listని బ్లాక్ చేయడం లాగా అనిపించవచ్చు, కానీ Redis స్ట్రీమ్‌ని ఎలా ఉపయోగించాలో ప్రాథమిక తేడాలు ఉన్నాయి:

1. ప్రతి కొత్త సందేశం డిఫాల్ట్‌గా ప్రతి సబ్‌స్క్రైబర్‌కు డెలివరీ చేయబడుతుంది. ఈ ప్రవర్తన నిరోధించే Redis జాబితా నుండి భిన్నంగా ఉంటుంది, ఇక్కడ కొత్త సందేశాన్ని ఒక చందాదారు మాత్రమే చదవగలరు.
2. Redis పబ్/సబ్‌లో అన్ని సందేశాలు మర్చిపోయి మరియు ఎప్పటికీ కొనసాగవు, స్ట్రీమ్‌లో అన్ని సందేశాలు నిరవధికంగా ఉంచబడతాయి (క్లయింట్ స్పష్టంగా తొలగింపుకు కారణమైతే తప్ప).
3. రెడిస్ స్ట్రీమ్ ఒక స్ట్రీమ్‌లోని సందేశాలకు ప్రాప్యతను వేరు చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. నిర్దిష్ట సబ్‌స్క్రైబర్ వారి వ్యక్తిగత సందేశ చరిత్రను మాత్రమే చూడగలరు.

మీరు థ్రెడ్‌కు సభ్యత్వాన్ని పొందవచ్చు మరియు ఆదేశాన్ని ఉపయోగించి కొత్త సందేశాలను స్వీకరించవచ్చు XREAD. కంటే కొంచెం క్లిష్టంగా ఉంటుంది XRANGE, కాబట్టి మేము ముందుగా సరళమైన ఉదాహరణలతో ప్రారంభిస్తాము.

> 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 ఎంపిక ఐచ్ఛికమని గమనించండి. వాస్తవానికి, STREAMS ఎంపిక మాత్రమే అవసరమైన కమాండ్ ఎంపిక, ఇది సంబంధిత గరిష్ట ఐడెంటిఫైయర్‌తో పాటు స్ట్రీమ్‌ల జాబితాను నిర్దేశిస్తుంది. మేము “స్ట్రీమ్స్ మైస్ట్రీమ్ 0” అని వ్రాసాము - మేము మైస్ట్రీమ్ స్ట్రీమ్ యొక్క అన్ని రికార్డులను “0-0” కంటే ఎక్కువ ఐడెంటిఫైయర్‌తో స్వీకరించాలనుకుంటున్నాము. మీరు ఉదాహరణ నుండి చూడగలిగినట్లుగా, కమాండ్ థ్రెడ్ పేరును అందిస్తుంది ఎందుకంటే మనం ఒకే సమయంలో బహుళ థ్రెడ్‌లకు సభ్యత్వాన్ని పొందవచ్చు. మేము ఉదాహరణకు, "స్ట్రీమ్స్ మైస్ట్రీమ్ ఇతర స్ట్రీమ్ 0 0" అని వ్రాయవచ్చు. STREAMS ఎంపిక తర్వాత మేము ముందుగా అవసరమైన అన్ని స్ట్రీమ్‌ల పేర్లను అందించాలని మరియు ఆ తర్వాత మాత్రమే ఐడెంటిఫైయర్‌ల జాబితాను అందించాలని దయచేసి గమనించండి.

ఈ సరళమైన రూపంలో కమాండ్‌తో పోలిస్తే ప్రత్యేకంగా ఏమీ చేయదు XRANGE. అయితే, ఆసక్తికరమైన విషయం ఏమిటంటే, మనం సులభంగా తిరగవచ్చు XREAD BLOCK ఆర్గ్యుమెంట్‌ని పేర్కొంటూ, నిరోధించే ఆదేశానికి:

> XREAD BLOCK 0 STREAMS mystream $

ఎగువ ఉదాహరణలో, 0 మిల్లీసెకన్ల గడువుతో కొత్త BLOCK ఎంపిక పేర్కొనబడింది (దీని అర్థం నిరవధికంగా వేచి ఉండటం). అంతేకాకుండా, స్ట్రీమ్ మైస్ట్రీమ్ కోసం సాధారణ ఐడెంటిఫైయర్‌ను పాస్ చేయడానికి బదులుగా, ఒక ప్రత్యేక ఐడెంటిఫైయర్ $ పాస్ చేయబడింది. ఈ ప్రత్యేక ఐడెంటిఫైయర్ అంటే XREAD మైస్ట్రీమ్‌లోని గరిష్ట ఐడెంటిఫైయర్‌ను తప్పనిసరిగా ఐడెంటిఫైయర్‌గా ఉపయోగించాలి. కాబట్టి మనం వినడం ప్రారంభించిన క్షణం నుండి మాత్రమే కొత్త సందేశాలను అందుకుంటాము. కొన్ని మార్గాల్లో ఇది Unix "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

ఈ ప్రభావాన్ని సాధించడానికి, Redis స్ట్రీమ్ కన్స్యూమర్ గ్రూప్ అనే భావనను ఉపయోగిస్తుంది. ఈ భావన ఒక నకిలీ-చందాదారుని పోలి ఉంటుంది, ఇది స్ట్రీమ్ నుండి డేటాను స్వీకరిస్తుంది, కానీ వాస్తవానికి సమూహంలోని బహుళ చందాదారులచే అందించబడుతుంది, ఇది నిర్దిష్ట హామీలను అందిస్తుంది:

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 మరియు ఐచ్ఛిక BLOCK ఎంపికకు మద్దతు ఇస్తుంది. అయినప్పటికీ, అవసరమైన 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 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.

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

ఈ ఆదేశాన్ని ఉపయోగించి, యజమానిని {consumer}గా మార్చడం ద్వారా ఇంకా ప్రాసెస్ చేయని “విదేశీ” సందేశాన్ని మనం అందుకోవచ్చు. అయితే, మేము కనీస నిష్క్రియ సమయాన్ని {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లను మాత్రమే తిరిగి ఇవ్వడానికి ఉపయోగించవచ్చు. సందేశం యొక్క వివరాలపై మీకు ఆసక్తి లేకుంటే మరియు సిస్టమ్ పనితీరును పెంచాలనుకుంటే ఇది ఉపయోగకరంగా ఉంటుంది.

డెలివరీ కౌంటర్

మీరు అవుట్‌పుట్‌లో చూసే కౌంటర్ ఎక్స్పెండింగ్ ప్రతి సందేశం యొక్క డెలివరీల సంఖ్య. అటువంటి కౌంటర్ రెండు విధాలుగా పెంచబడుతుంది: సందేశం ద్వారా విజయవంతంగా అభ్యర్థించబడినప్పుడు 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ని ఉపయోగిస్తున్నప్పుడు, పాత రికార్డ్‌లు నిర్దిష్ట పొడవును చేరుకున్నప్పుడు స్వయంచాలకంగా తొలగించబడతాయి, కాబట్టి స్ట్రీమ్ స్థిరమైన పరిమాణాన్ని కలిగి ఉంటుంది. అయినప్పటికీ, ఈ సందర్భంలో కత్తిరింపు అనేది Redis మెమరీలో అత్యంత సమర్థవంతమైన మార్గంలో జరగదు. మీరు ఈ క్రింది విధంగా పరిస్థితిని మెరుగుపరచవచ్చు:

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

ఎగువ ఉదాహరణలోని ~ వాదన అంటే మనం స్ట్రీమ్ పొడవును నిర్దిష్ట విలువకు పరిమితం చేయాల్సిన అవసరం లేదు. మా ఉదాహరణలో, ఇది 1000 కంటే ఎక్కువ లేదా సమానమైన సంఖ్య కావచ్చు (ఉదాహరణకు, 1000, 1010 లేదా 1030). మా స్ట్రీమ్ కనీసం 1000 రికార్డ్‌లను నిల్వ చేయాలని మేము స్పష్టంగా పేర్కొన్నాము. ఇది Redis లోపల మెమరీ నిర్వహణను మరింత సమర్థవంతంగా చేస్తుంది.

ప్రత్యేక బృందం కూడా ఉంది 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"

ఈ ఆదేశాన్ని ఉపయోగిస్తున్నప్పుడు, అసలు మెమరీ వెంటనే విడుదల చేయబడదని మీరు పరిగణనలోకి తీసుకోవాలి.

సున్నా పొడవు ప్రవాహాలు

స్ట్రీమ్‌లు మరియు ఇతర Redis డేటా స్ట్రక్చర్‌ల మధ్య వ్యత్యాసం ఏమిటంటే, ఇతర డేటా స్ట్రక్చర్‌లు ఇకపై వాటిలో ఎలిమెంట్‌లను కలిగి లేనప్పుడు, ఒక సైడ్ ఎఫెక్ట్‌గా, డేటా స్ట్రక్చర్ మెమరీ నుండి తీసివేయబడుతుంది. కాబట్టి, ఉదాహరణకు, ZREM కాల్ చివరి మూలకాన్ని తీసివేసినప్పుడు క్రమబద్ధీకరించబడిన సెట్ పూర్తిగా తీసివేయబడుతుంది. బదులుగా, థ్రెడ్‌లు లోపల ఎటువంటి మూలకాలు లేకుండా కూడా మెమరీలో ఉండటానికి అనుమతించబడతాయి.

తీర్మానం

మెసేజ్ బ్రోకర్లు, మెసేజ్ క్యూలు, ఏకీకృత లాగింగ్ మరియు హిస్టరీ కీపింగ్ చాట్ సిస్టమ్‌లను రూపొందించడానికి రెడిస్ స్ట్రీమ్ అనువైనది.

నేను ఒకసారి చెప్పాను నిక్లాస్ విర్త్, ప్రోగ్రామ్‌లు అల్గారిథమ్‌లు ప్లస్ డేటా స్ట్రక్చర్‌లు, మరియు Redis ఇప్పటికే మీకు రెండింటినీ అందిస్తుంది.

మూలం: www.habr.com