ريڊس اسٽريم ھڪڙو نئون خلاصو ڊيٽا جو قسم آھي جيڪو Redis ۾ ورزن 5.0 سان متعارف ڪرايو ويو آھي
تصوراتي طور تي، ريڊس اسٽريم هڪ فهرست آهي جنهن ۾ توهان شامل ڪري سگهو ٿا. هر داخلا هڪ منفرد سڃاڻپ ڪندڙ آهي. ڊفالٽ طور، ID خود بخود ٺاهي وئي آهي ۽ ٽائم اسٽيمپ شامل آهي. تنهن ڪري، توهان وقت جي حوالي سان رڪارڊ جي حدن جي پڇا ڳاڇا ڪري سگهو ٿا، يا نئين ڊيٽا حاصل ڪري سگهو ٿا جيئن اهو وهڪرو ۾ اچي ٿو، گهڻو ڪري يونڪس "tail -f" حڪم هڪ لاگ فائل پڙهي ٿو ۽ نئين ڊيٽا جي انتظار ۾ منجهيل آهي. نوٽ ڪريو ته گھڻا گراهڪ ھڪ ئي وقت ھڪڙي سلسلي کي ٻڌي سگھن ٿا، جھڙيءَ طرح ڪيترائي ”tail-f“ عمل ھڪ ٻئي سان ٽڪراءَ کان سواءِ ھڪڙي فائل کي پڙھي سگھن ٿا.
نئين ڊيٽا جي قسم جي سڀني فائدن کي سمجهڻ لاءِ، اچو ته هڪ تڪڙي نظر وجهون ڊگھي موجوده ريڊيس اڏاوتن تي جيڪي جزوي طور تي ريڊيس اسٽريم جي ڪارڪردگيءَ کي نقل ڪن ٿيون.
Redis PUB/SUB
Redis Pub/Sub هڪ سادي ميسيجنگ سسٽم آهي جيڪو اڳ ۾ ئي توهان جي اهم-ويل اسٽور ۾ ٺهيل آهي. بهرحال، سادگي قيمت تي اچي ٿي:
- جيڪڏهن پبلشر ڪجهه سببن لاء ناڪام ٿي، پوء هو پنهنجي سڀني رڪنن کي وڃائي ٿو
- پبلشر کي ان جي سڀني رڪنن جو صحيح پتو ڄاڻڻ جي ضرورت آهي
- هڪ پبلشر شايد پنهنجي رڪنن کي ڪم سان اوورلوڊ ڪري سگهي ٿو جيڪڏهن ڊيٽا کي پروسيس ٿيڻ کان تيزيءَ سان شايع ڪيو وڃي
- پيغام شايع ٿيڻ کان پوءِ فوري طور تي پبلشر جي بفر مان حذف ڪيو ويندو آهي، قطع نظر ان جي ڪيترين ئي رڪنن تائين پهچايو ويو هو ۽ اهي ڪيترا ئي جلدي هن پيغام تي عمل ڪرڻ جي قابل هئا.
- سڀني رڪنن کي ساڳئي وقت پيغام ملي ويندا. سبسڪرائبرن کي پاڻ ۾ ڪنهن نه ڪنهن طرح متفق ٿيڻ گهرجي ساڳي پيغام کي پروسيس ڪرڻ جي حڪم تي.
- تصديق ڪرڻ لاءِ ڪو به ٺهيل ميڪانيزم ناهي ته هڪ سبسڪرائبر ڪاميابيءَ سان هڪ پيغام تي عمل ڪيو آهي. جيڪڏهن هڪ سبسڪرائبر هڪ پيغام وصول ڪري ٿو ۽ پروسيسنگ دوران حادثو، پبلشر ان جي باري ۾ نه ڄاڻندو.
Redis لسٽ
Redis List هڪ ڊيٽا جي جوڙجڪ آهي جيڪا مدد ڪري ٿي بلاڪ پڙهڻ واري حڪمن کي. توھان شامل ڪري سگھوٿا ۽ لسٽ جي شروعات يا آخر کان پيغام پڙھي سگھو ٿا. هن ڍانچي جي بنياد تي، توهان پنهنجي ورهايل سسٽم لاء سٺو اسٽيڪ يا قطار ٺاهي سگهو ٿا، ۽ اڪثر ڪيسن ۾ اهو ڪافي هوندو. Redis Pub/Sub کان مکيه فرق:
- پيغام هڪ ڪلائنٽ ڏانهن پهچايو ويو آهي. پهريون پڙهيل بند ٿيل ڪلائنٽ پهريون ڀيرو ڊيٽا حاصل ڪندو.
- ڪلنٽ کي لازمي طور تي هر پيغام لاءِ پڙهڻ وارو عمل پاڻ شروع ڪرڻ گهرجي. لسٽ گراهڪن جي باري ۾ ڪجھ به نه ڄاڻندو آھي.
- پيغام محفوظ ڪيا ويندا آهن جيستائين ڪو ماڻهو انهن کي پڙهي يا واضح طور تي حذف ڪري. جيڪڏهن توهان ريڊيس سرور کي ترتيب ڏيو ته ڊيٽا کي ڊسڪ ۾ فلش ڪرڻ لاءِ، پوءِ سسٽم جي اعتبار کي ڊرامائي طور تي وڌي ٿو.
اسٽريم جو تعارف
نديءَ ۾ داخل ٿيڻ
ٽيم XADD نديءَ ۾ نئين داخلا شامل ڪري ٿي. رڪارڊ صرف هڪ تار نه آهي، اهو هڪ يا وڌيڪ اهم-قدر جوڑوں تي مشتمل آهي. اهڙيء طرح، هر داخلا اڳ ۾ ئي ٺهيل آهي ۽ هڪ CSV فائل جي جوڙجڪ وانگر آهي.
> XADD mystream * sensor-id 1234 temperature 19.8
1518951480106-0
مٿي ڏنل مثال ۾، اسان نالي سان اسٽريم ۾ ٻه فيلڊ شامل ڪندا آهيون (key) "mystream": "sensor-id" ۽ "temperature" جي قدرن سان "1234" ۽ "19.8"، ترتيب سان. ٻئي دليل جي طور تي، حڪم هڪ سڃاڻپ ڪندڙ وٺندو آهي جيڪو داخل ٿيڻ لاء مقرر ڪيو ويندو - هي سڃاڻپ ڪندڙ منفرد طور تي هر داخل ٿيڻ جي سڃاڻپ ڪندو آهي وهڪرو ۾. جڏهن ته، هن معاملي ۾ اسان * پاس ڪيو آهي ڇاڪاڻ ته اسان چاهيون ٿا ته Redis اسان لاء هڪ نئين ID ٺاهي. هر نئين ID وڌائي ويندي. تنهن ڪري، هر نئين داخلا کي پوئين داخلن جي حوالي سان هڪ اعلي سڃاڻپ ڪندڙ هوندو.
سڃاڻپ ڪندڙ فارميٽ
داخل ٿيل ID حڪم سان واپس آيو XADD، ٻن حصن تي مشتمل آهي:
{millisecondsTime}-{sequenceNumber}
ملي سيڪنڊ وقت - يونڪس ٽائيم مليس سيڪنڊن ۾ (ريڊيس سرور جو وقت). بهرحال، جيڪڏهن موجوده وقت ساڳيو يا اڳئين رڪارڊنگ جي وقت کان گهٽ آهي، ته پوئين رڪارڊنگ جو ٽائم اسٽيمپ استعمال ڪيو ويندو آهي. تنهن ڪري، جيڪڏهن سرور جو وقت وقت ۾ واپس وڃي ٿو، نئين سڃاڻپ ڪندڙ اڃا تائين وڌندڙ ملڪيت برقرار رکندو.
تسلسل نمبر ساڳئي مليس سيڪنڊ ۾ ٺاهيل رڪارڊ لاءِ استعمال ڪيو ويو. تسلسل نمبر اڳئين داخلا جي نسبت 1 وڌائي ويندي. ڇاڪاڻ ته تسلسل نمبر سائيز ۾ 64 بٽ آهي، پوء عملي طور تي توهان کي رڪارڊ جي تعداد تي حد تائين نه هلڻ گهرجي جيڪي هڪ ملي سيڪنڊ اندر ٺاهي سگھجن ٿيون.
اهڙي سڃاڻپ ڪندڙ جي شڪل پهرين نظر ۾ عجيب لڳي سگهي ٿي. هڪ بي اعتمادي پڙهندڙ شايد حيران ٿي سگهي ٿو ته وقت سڃاڻپ ڪندڙ جو حصو آهي. ان جو سبب اهو آهي ته ريڊس اسٽريم سپورٽ رينج سوالن کي 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"
هر واپسي رڪارڊ ٻن عناصر جو هڪ صف آهي: هڪ سڃاڻپ ڪندڙ ۽ اهم-قدر جوڑوں جي هڪ فهرست. اسان اڳ ۾ ئي چيو آهي ته رڪارڊ جي سڃاڻپ ڪندڙ وقت سان لاڳاپيل آهن. تنهن ڪري، اسان وقت جي مخصوص مدت جي حد تائين درخواست ڪري سگهون ٿا. تنهن هوندي، اسان درخواست ۾ وضاحت ڪري سگھون ٿا مڪمل سڃاڻپ ڪندڙ نه، پر صرف يونڪس وقت، لاڳاپيل حصو کي ختم ڪندي. تسلسل نمبر. سڃاڻپ ڪندڙ جو ختم ٿيل حصو خودڪار طور تي رينج جي شروعات ۾ صفر تي مقرر ڪيو ويندو ۽ حد جي آخر ۾ وڌ ۾ وڌ ممڪن قدر تائين. هيٺ ڏنل هڪ مثال آهي ته توهان ٻه ملي سيڪنڊن جي حد جي درخواست ڪيئن ڪري سگهو ٿا.
> XRANGE mystream 1518951480106 1518951480107
1) 1) 1518951480106-0
2) 1) "sensor-id"
2) "1234"
3) "temperature"
4) "19.8"
اسان وٽ هن حد ۾ صرف هڪ داخلا آهي، جڏهن ته حقيقي ڊيٽا سيٽن ۾ واپسي جو نتيجو تمام وڏو ٿي سگهي ٿو. ان لاءِ XRANGE COUNT آپشن کي سپورٽ ڪري ٿو. مقدار جي وضاحت ڪندي، اسان صرف حاصل ڪري سگھون ٿا پهريون N ريڪارڊ. جيڪڏهن اسان کي ايندڙ اين رڪارڊز (صفحو) حاصل ڪرڻ جي ضرورت آهي، اسان آخري حاصل ڪيل ID استعمال ڪري سگهون ٿا، ان کي وڌايو تسلسل نمبر هڪ طرف ۽ ٻيهر پڇو. اچو ته ان کي هيٺين مثال ۾ ڏسو. اسان 10 عناصر شامل ڪرڻ شروع ڪندا آهيون XADD (فرض ڪيو ته منهنجو وهڪرو اڳ ۾ ئي 10 عناصر سان ڀريل هو). هر ڪمانڊ ۾ 2 عناصر حاصل ڪرڻ لاءِ ٻيهر شروع ڪرڻ لاءِ، اسان مڪمل حد سان شروع ڪريون ٿا پر COUNT برابر 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"
ايندڙ ٻن عنصرن سان ٻيهر ورجائڻ جاري رکڻ لاءِ، اسان کي حاصل ڪيل آخري 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)) ڳولھڻ لاءِ ۽ پوءِ O(M) آھي 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 لسٽ کان مختلف آهي، جتي هڪ نئون پيغام صرف هڪ سبسڪرائيبر طرفان پڙهيو ويندو.
- جڏهن ته ريڊس پب/سب ۾ سڀئي پيغام وساريا ويندا آهن ۽ ڪڏهن به جاري نه هوندا آهن، اسٽريم ۾ سڀئي پيغام اڻڄاتل طور تي برقرار رکيا ويندا آهن (جيستائين ڪلائنٽ واضح طور تي حذف ڪرڻ جو سبب نه هجي).
- ريڊس اسٽريم توهان کي اجازت ڏئي ٿو ته مختلف پيغامن تائين رسائي هڪ اسٽريم اندر. هڪ مخصوص رڪن صرف پنهنجي ذاتي پيغام جي تاريخ ڏسي سگهي ٿو.
توھان ھڪڙي سلسلي جي رڪنيت حاصل ڪري سگھو ٿا ۽ حڪم استعمال ڪندي نوان پيغام وصول ڪري سگھو ٿا 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 اختياري آھي. حقيقت ۾، صرف گهربل ڪمانڊ آپشن اسٽريمس آپشن آهي، جيڪو بيان ڪري ٿو سلسلو جي هڪ فهرست سان گڏ لاڳاپيل وڌ ۾ وڌ سڃاڻپ ڪندڙ. اسان لکيو آهي ”اسٽريمز مائي اسٽريم 0“ - اسان چاهيون ٿا ته منهنجي اسٽريم اسٽريم جا سڀ رڪارڊ هڪ سڃاڻپ ڪندڙ سان گڏ حاصل ڪرڻ چاهيون ٿا ”0-0“ کان وڌيڪ. جيئن ته توهان مثال مان ڏسي سگهو ٿا، حڪم ٿريڊ جو نالو ڏئي ٿو ڇو ته اسان هڪ ئي وقت ڪيترن ئي موضوعن جي رڪنيت حاصل ڪري سگهون ٿا. اسان لکي سگهون ٿا، مثال طور، "اسٽريمز mystream otherstream 0 0". مهرباني ڪري نوٽ ڪريو ته اسٽريمز آپشن کان پوءِ اسان کي پهريان سڀني گهربل اسٽريمز جا نالا مهيا ڪرڻ گهرجن ۽ صرف پوءِ سڃاڻپ ڪندڙن جي هڪ فهرست.
هن سادي فارم ۾ حڪم جي مقابلي ۾ ڪجهه خاص نه ڪندو آهي XRANGE. بهرحال، دلچسپ ڳالهه اها آهي ته اسان آساني سان ڦري سگهون ٿا XREAD بلاڪ ڪرڻ واري حڪم تي، BLOCK دليل بيان ڪندي:
> XREAD BLOCK 0 STREAMS mystream $
مٿي ڏنل مثال ۾، هڪ نئون بلاڪ اختيار بيان ڪيو ويو آهي 0 مليسيڪن جي ٽائم آئوٽ سان (هن جو مطلب آهي اڻڄاتل انتظار). ان کان علاوه، اسٽريم mystream لاءِ معمولي سڃاڻپ ڪندڙ پاس ڪرڻ بدران، هڪ خاص سڃاڻپ ڪندڙ $ پاس ڪيو ويو. هن خاص سڃاڻپ ڪندڙ جو مطلب آهي XREAD منهنجي اسٽريم ۾ وڌ ۾ وڌ سڃاڻپ ڪندڙ کي سڃاڻپ ڪندڙ طور استعمال ڪرڻ گهرجي. تنهن ڪري اسان صرف نوان پيغام وصول ڪنداسين جڏهن کان اسان ٻڌڻ شروع ڪيو. ڪجھ طريقن ۾ اھو ساڳيو آھي يونڪس "tail -f" حڪم.
نوٽ ڪريو ته BLOCK آپشن استعمال ڪرڻ وقت اسان کي خاص سڃاڻپ ڪندڙ $ استعمال ڪرڻ جي ضرورت ناھي. اسان وهڪرو ۾ موجود ڪنهن به سڃاڻپ ڪندڙ کي استعمال ڪري سگهون ٿا. جيڪڏهن ٽيم اسان جي درخواست کي فوري طور تي بغير بلاڪ ڪرڻ جي خدمت ڪري سگهي ٿي، اهو ائين ڪندي، ٻي صورت ۾ اهو بلاڪ ڪيو ويندو.
بلاڪ ڪرڻ XREAD هڪ ئي وقت ڪيترن ئي موضوعن کي پڻ ٻڌي سگهو ٿا، توهان کي صرف انهن جا نالا بيان ڪرڻ گهرجن. انهي حالت ۾، حڪم واپس آڻيندو پهريون وهڪرو جو رڪارڊ جيڪو ڊيٽا حاصل ڪيو. ڏنل سلسلي لاءِ بلاڪ ڪيل پهريون سبسڪرائبر پهريون ڀيرو ڊيٽا وصول ڪندو.
صارفين جا گروپ
ڪجھ ڪمن ۾، اسان ھڪڙي سلسلي ۾ پيغامن تائين رڪنيت جي رسائي کي محدود ڪرڻ چاھيون ٿا. ھڪڙو مثال جتي اھو ڪارائتو ٿي سگھي ٿو ھڪڙي پيغام جي قطار آھي ڪارڪنن سان جيڪا ھڪڙي سلسلي مان مختلف پيغام وصول ڪندي، پيغام جي پروسيسنگ کي ماپ ڪرڻ جي اجازت ڏئي ٿي.
جيڪڏهن اسان تصور ڪريون ٿا ته اسان وٽ ٽي سبسڪرائبر آهن C1، C2، C3 ۽ هڪ ٿريڊ جنهن ۾ 1، 2، 3، 4، 5، 6، 7، XNUMX، XNUMX، XNUMX پيغام آهن، ته پوءِ اهي نياپا ڏنا ويندا جيئن هيٺ ڏنل ڊراگرام ۾:
1 -> C1
2 -> C2
3 -> C3
4 -> C1
5 -> C2
6 -> C3
7 -> C1
ھن اثر کي حاصل ڪرڻ لاءِ، ريڊس اسٽريم استعمال ڪري ٿو ھڪڙي تصور کي ڪنزيومر گروپ. اهو تصور هڪ pseudo-subscriber سان ملندڙ جلندڙ آهي، جيڪو هڪ وهڪرو مان ڊيٽا حاصل ڪري ٿو، پر اصل ۾ هڪ گروپ جي اندر ڪيترن ئي سبسڪرائبرن جي طرفان خدمت ڪئي وئي آهي، ڪجهه ضمانتون مهيا ڪندي:
- هر پيغام گروپ جي اندر مختلف رڪنن تائين پهچايو ويندو آهي.
- هڪ گروپ جي اندر، رڪنن کي انهن جي نالي سان سڃاتو وڃي ٿو، جيڪو هڪ ڪيس-حساس اسٽرنگ آهي. جيڪڏهن ڪو رڪن عارضي طور تي گروپ مان خارج ٿي وڃي ٿو، ته هو پنهنجي منفرد نالو استعمال ڪندي گروپ ۾ بحال ٿي سگهي ٿو.
- هر صارف گروپ "پهرين اڻ پڙهيل پيغام" جي تصور جي پيروي ڪري ٿو. جڏهن هڪ سبسڪرائبر نون پيغامن جي درخواست ڪري ٿو، اهو صرف اهي پيغام وصول ڪري سگهي ٿو جيڪي اڳ ڪڏهن به گروپ جي اندر ڪنهن به سبسڪرائبر کي نه پهچايو ويو آهي.
- واضح طور تي تصديق ڪرڻ لاء هڪ حڪم آهي ته پيغام ڪاميابيء سان عمل ڪيو ويو سبسڪربر طرفان. جيستائين هن حڪم کي سڏيو ويندو آهي، درخواست ٿيل پيغام "منتقل" جي حيثيت ۾ رهندو.
- صارفين جي گروپ جي اندر، هر سبسڪرائبر پيغامن جي تاريخ جي درخواست ڪري سگهي ٿو جيڪي هن کي پهچايو ويو آهي، پر اڃا تائين عمل نه ڪيو ويو آهي ("منتقل" حالت ۾)
هڪ لحاظ کان، گروپ جي حالت هن ريت بيان ڪري سگهجي ٿي:
+----------------------------------------+
| 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)
+----------------------------------------+
هاڻي اهو وقت آهي صارف جي گروپ جي مکيه حڪمن سان واقف ٿيڻ جو، يعني:
- ايڪس گروپ گروپ ٺاهڻ، تباهه ۽ منظم ڪرڻ لاء استعمال ڪيو ويو
- XREADGROUP گروپ ذريعي وهڪرو پڙهڻ لاء استعمال ڪيو ويو
- XACK - ھي حڪم سبسڪرائبر کي پيغام کي نشان ھڻڻ جي اجازت ڏئي ٿو جيئن ڪاميابي سان پروسيس ٿيل آھي
صارفين جي گروپ جي ٺهڻ
اچو ته فرض ڪريو ته منهنجو وهڪرو اڳ ۾ ئي موجود آهي. پوءِ گروپ ٺاھڻ جو حڪم نظر ايندو:
> XGROUP CREATE mystream mygroup $
OK
جڏهن هڪ گروپ ٺاهيو، اسان کي هڪ سڃاڻپ ڪندڙ پاس ڪرڻ گهرجي، جنهن کان شروع ٿئي ٿو گروپ پيغام وصول ڪندو. جيڪڏهن اسان چاهيون ٿا ته سڀ نوان نياپا وصول ڪن، ته پوءِ اسان استعمال ڪري سگهون ٿا خاص سڃاڻپ ڪندڙ $ (جيئن اسان جي مٿين مثال ۾). جيڪڏهن توهان هڪ خاص سڃاڻپ ڪندڙ جي بدران 0 بيان ڪريو ٿا، ته پوءِ ٿريڊ ۾ موجود سڀئي نياپا گروپ ۾ موجود هوندا.
ھاڻي اھو گروپ ٺاھيو ويو آھي، اسان فوري طور تي حڪم استعمال ڪندي پيغام پڙھڻ شروع ڪري سگھون ٿا XREADGROUP. هي حڪم بلڪل ساڳيو آهي XREAD ۽ اختياري بلاڪ اختيار کي سپورٽ ڪري ٿو. بهرحال، اتي هڪ گهربل گروپ اختيار آهي جيڪو هميشه ٻن دليلن سان بيان ڪيو وڃي: گروپ جو نالو ۽ رڪن جو نالو. 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 توهان هڪ ئي وقت ڪيترن ئي مختلف موضوعن مان نياپا پڙهي سگهو ٿا، جڏهن ته اهو ڪم ڪرڻ لاءِ توهان کي پهريان هر ٿريڊ لاءِ ساڳي نالي سان گروپ ٺاهڻ گهرجن ايڪس گروپ
هڪ ناڪامي کان پوء بحالي
رڪنيت حاصل ڪري سگهي ٿو ناڪامي کان ۽ ٻيهر پڙهي سگهي ٿو پنهنجي پيغامن جي لسٽ کي "منتقل" حيثيت سان. جڏهن ته، حقيقي دنيا ۾، رڪنيت آخرڪار ناڪام ٿي سگهي ٿي. سبسڪرائبر جي پڪي پيغامن کي ڇا ٿيندو جيڪڏهن سبسڪرائبر ناڪاميءَ کان بحال نه ٿي سگهي؟
ڪنزيومر گروپ هڪ خصوصيت پيش ڪري ٿو جيڪا صرف اهڙن ڪيسن لاءِ استعمال ٿئي ٿي - جڏهن توهان کي پيغامن جي مالڪ کي تبديل ڪرڻ جي ضرورت آهي.
پهرين شيء توهان کي ڪرڻ جي ضرورت آهي حڪم ڪال ڪريو 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} — ترسيل ڪوششن جو تعداد
{صارف جو نالو} - گروپ جو نالو
> 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 {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 اختيار صرف پيغام جي IDs کي واپس ڪرڻ لاء استعمال ڪري سگھجي ٿو. اهو مفيد آهي جيڪڏهن توهان پيغام جي تفصيل ۾ دلچسپي نه ٿا رکون ۽ سسٽم جي ڪارڪردگي کي وڌائڻ چاهيو ٿا.
ترسيل ڪائونٽر
ڪائونٽر جيڪو توهان آئوٽ ۾ ڏسندا XPENDING هر پيغام جي ترسيل جو تعداد آهي. اهڙي قسم جي انسداد کي ٻن طريقن سان وڌايو ويندو آهي: جڏهن هڪ پيغام ڪاميابيء سان درخواست ڪئي وئي آهي ايڪس ڪليم يا جڏهن ڪال استعمال ٿئي ٿي 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 استعمال ڪرڻ وقت، پراڻا رڪارڊ خود بخود ڊهي ويندا آهن جڏهن اهي هڪ مخصوص ڊگھائي تائين پهچي ويندا آهن، تنهن ڪري وهڪرو هڪ مستقل سائيز آهي. تنهن هوندي به، هن معاملي ۾ pruning سڀ کان وڌيڪ موثر انداز ۾ Redis ياداشت ۾ نه ٿئي. توھان ھيٺ ڏنل صورتحال کي بهتر ڪري سگھو ٿا:
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