Redis Stream ایک نئی تجریدی ڈیٹا کی قسم ہے جسے Redis میں ورژن 5.0 کے ساتھ متعارف کرایا گیا ہے۔
تصوراتی طور پر، Redis Stream ایک فہرست ہے جس میں آپ اندراجات شامل کر سکتے ہیں۔ ہر اندراج کا ایک منفرد شناخت کنندہ ہوتا ہے۔ پہلے سے طے شدہ طور پر، ID خود بخود تیار ہوتی ہے اور اس میں ٹائم اسٹیمپ شامل ہوتا ہے۔ اس لیے، آپ وقت کے ساتھ ریکارڈز کی رینجز سے استفسار کر سکتے ہیں، یا اسٹریم میں آتے ہی نیا ڈیٹا وصول کر سکتے ہیں، بالکل اسی طرح جیسے یونکس "tail -f" کمانڈ لاگ فائل کو پڑھتی ہے اور نئے ڈیٹا کا انتظار کرتے ہوئے جم جاتی ہے۔ نوٹ کریں کہ ایک سے زیادہ کلائنٹ ایک ہی وقت میں ایک تھریڈ کو سن سکتے ہیں، بالکل اسی طرح جیسے بہت سے "tail -f" عمل ایک دوسرے سے متصادم ہوئے بغیر ایک فائل کو بیک وقت پڑھ سکتے ہیں۔

نئی ڈیٹا کی قسم کے تمام فوائد کو سمجھنے کے لیے، آئیے ایک سرسری نظر ڈالتے ہیں Redis کے طویل ڈھانچے جو جزوی طور پر Redis Stream کی فعالیت کو نقل کرتے ہیں۔

Redis PUB/SUB

Redis Pub/Sub ایک سادہ پیغام رسانی کا نظام ہے جو آپ کے کلیدی قدر والے اسٹور میں پہلے سے بنایا گیا ہے۔ تاہم، سادگی ایک قیمت پر آتی ہے:

اگر پبلشر کسی وجہ سے ناکام ہو جاتا ہے، تو وہ اپنے تمام سبسکرائبرز کو کھو دیتا ہے۔
پبلشر کو اپنے تمام سبسکرائبرز کا صحیح پتہ جاننے کی ضرورت ہے۔
ایک ناشر اپنے سبسکرائبرز کو کام کے ساتھ اوورلوڈ کر سکتا ہے اگر ڈیٹا اس پر کارروائی سے زیادہ تیزی سے شائع ہوتا ہے۔
اس پیغام کو اشاعت کے فوراً بعد ناشر کے بفر سے حذف کر دیا جاتا ہے، قطع نظر اس کے کہ کتنے سبسکرائبرز کو یہ ڈیلیور کیا گیا تھا اور وہ کتنی جلدی اس پیغام پر کارروائی کرنے کے قابل تھے۔
تمام صارفین کو ایک ہی وقت میں پیغام موصول ہوگا۔ سبسکرائبرز کو خود کسی نہ کسی طرح ایک ہی پیغام پر کارروائی کرنے کے حکم پر آپس میں متفق ہونا چاہیے۔
اس بات کی تصدیق کرنے کے لیے کوئی بلٹ ان میکانزم نہیں ہے کہ سبسکرائبر نے کامیابی کے ساتھ کسی پیغام پر کارروائی کی ہے۔ اگر کسی سبسکرائبر کو کوئی پیغام موصول ہوتا ہے اور کارروائی کے دوران کریش ہو جاتا ہے، تو پبلشر کو اس کے بارے میں علم نہیں ہوگا۔

ریڈیس لسٹ

Redis List ایک ڈیٹا ڈھانچہ ہے جو پڑھنے کے حکموں کو مسدود کرنے کی حمایت کرتا ہے۔ آپ فہرست کے شروع یا آخر سے پیغامات شامل اور پڑھ سکتے ہیں۔ اس ڈھانچے کی بنیاد پر، آپ اپنے تقسیم شدہ نظام کے لیے ایک اچھا اسٹیک یا قطار بنا سکتے ہیں، اور زیادہ تر صورتوں میں یہ کافی ہوگا۔ Redis Pub/Sub سے اہم فرق:

پیغام ایک کلائنٹ کو پہنچایا جاتا ہے۔ سب سے پہلے پڑھے جانے والے کلائنٹ کو پہلے ڈیٹا موصول ہوگا۔
کلینٹ کو ہر پیغام کے لیے خود سے پڑھنے کا عمل شروع کرنا چاہیے۔ فہرست گاہکوں کے بارے میں کچھ نہیں جانتی ہے۔
پیغامات اس وقت تک محفوظ کیے جاتے ہیں جب تک کہ کوئی انہیں پڑھ نہ لے یا واضح طور پر حذف نہ کر دے۔ اگر آپ ریڈیس سرور کو ڈسک پر ڈیٹا فلش کرنے کے لیے تشکیل دیتے ہیں، تو سسٹم کی وشوسنییتا ڈرامائی طور پر بڑھ جاتی ہے۔

اسٹریم کا تعارف

ندی میں اندراج شامل کرنا

ٹیم XADD ندی میں ایک نئی اندراج شامل کرتا ہے۔ ریکارڈ صرف ایک تار نہیں ہوتا، یہ ایک یا زیادہ کلیدی قدر کے جوڑوں پر مشتمل ہوتا ہے۔ اس طرح، ہر اندراج پہلے سے ساختہ ہے اور CSV فائل کی ساخت سے مشابہ ہے۔

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

اوپر کی مثال میں، ہم نام (کلیدی) "mystream" کے ساتھ سٹریم میں دو فیلڈز شامل کرتے ہیں: "sensor-id" اور "درجہ حرارت" بالترتیب "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 List کو مسدود کرنے سے ملتا جلتا معلوم ہو سکتا ہے، لیکن Redis Stream کو استعمال کرنے کے طریقے میں بنیادی اختلافات ہیں:

ہر نیا پیغام ہر سبسکرائبر کو بطور ڈیفالٹ پہنچایا جاتا ہے۔ یہ رویہ بلاک کرنے والی Redis لسٹ سے مختلف ہے، جہاں ایک نیا پیغام صرف ایک سبسکرائبر پڑھے گا۔
جبکہ Redis Pub/Sub میں تمام پیغامات بھول جاتے ہیں اور کبھی برقرار نہیں رہتے ہیں، سٹریم میں تمام پیغامات غیر معینہ مدت تک برقرار رکھے جاتے ہیں (جب تک کہ کلائنٹ واضح طور پر حذف کرنے کا سبب نہ بنے)۔
Redis Stream آپ کو ایک سلسلہ میں پیغامات تک رسائی میں فرق کرنے کی اجازت دیتا ہے۔ ایک مخصوص سبسکرائبر صرف اپنے ذاتی پیغام کی سرگزشت دیکھ سکتا ہے۔

آپ ایک تھریڈ کو سبسکرائب کر سکتے ہیں اور کمانڈ کا استعمال کرتے ہوئے نئے پیغامات وصول کر سکتے ہیں۔ 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 اختیار اختیاری ہے۔ درحقیقت، صرف مطلوبہ کمانڈ آپشن STREAMS آپشن ہے، جو متعلقہ زیادہ سے زیادہ شناخت کنندہ کے ساتھ اسٹریمز کی فہرست بھی بتاتا ہے۔ ہم نے "اسٹریمز مائی اسٹریم 0" لکھا ہے - ہم "0-0" سے زیادہ شناخت کنندہ کے ساتھ مائی اسٹریم اسٹریم کے تمام ریکارڈ وصول کرنا چاہتے ہیں۔ جیسا کہ آپ مثال سے دیکھ سکتے ہیں، کمانڈ تھریڈ کا نام لوٹاتی ہے کیونکہ ہم ایک ہی وقت میں متعدد تھریڈز کو سبسکرائب کر سکتے ہیں۔ ہم لکھ سکتے ہیں، مثال کے طور پر، "STREAMS mystream otherstream 0 0"۔ براہ کرم نوٹ کریں کہ STREAMS آپشن کے بعد ہمیں پہلے تمام مطلوبہ اسٹریمز کے نام اور اس کے بعد ہی شناخت کنندگان کی فہرست فراہم کرنے کی ضرورت ہے۔

اس سادہ شکل میں کمانڈ اس کے مقابلے میں کچھ خاص نہیں کرتی ہے۔ ایکس رینج. تاہم، دلچسپ بات یہ ہے کہ ہم آسانی سے مڑ سکتے ہیں۔ XREAD بلاک آرگیومینٹ کی وضاحت کرتے ہوئے بلاکنگ کمانڈ پر:

> XREAD BLOCK 0 STREAMS mystream $
اوپر کی مثال میں، 0 ملی سیکنڈ کے ٹائم آؤٹ کے ساتھ ایک نیا بلاک آپشن بیان کیا گیا ہے (اس کا مطلب ہے غیر معینہ مدت تک انتظار کرنا)۔ مزید برآں، اسٹریم mystream کے لیے معمول کے شناخت کنندہ کو پاس کرنے کے بجائے، ایک خاص شناخت کنندہ $ پاس کیا گیا۔ اس خصوصی شناخت کنندہ کا مطلب یہ ہے۔ XREAD mystream میں زیادہ سے زیادہ شناخت کنندہ کو بطور شناخت کنندہ استعمال کرنا چاہیے۔ لہذا ہمیں صرف اس وقت سے نئے پیغامات موصول ہوں گے جب ہم نے سننا شروع کیا تھا۔ کچھ طریقوں سے یہ یونکس "tail -f" کمانڈ کی طرح ہے۔

نوٹ کریں کہ بلاک آپشن استعمال کرتے وقت ہمیں خصوصی شناخت کنندہ $ استعمال کرنے کی ضرورت نہیں ہے۔ ہم سٹریم میں موجود کسی بھی شناخت کنندہ کو استعمال کر سکتے ہیں۔ اگر ٹیم بلاک کیے بغیر ہماری درخواست کو فوری طور پر پورا کر سکتی ہے، تو وہ ایسا کرے گی، ورنہ بلاک کر دے گی۔

بلاک کرنا 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 Stream Consumer Group نامی ایک تصور استعمال کرتا ہے۔ یہ تصور چھدم سبسکرائبر کی طرح ہے، جو ایک سٹریم سے ڈیٹا وصول کرتا ہے، لیکن اصل میں ایک گروپ کے اندر ایک سے زیادہ سبسکرائبرز کی طرف سے پیش کیا جاتا ہے، کچھ ضمانتیں فراہم کرتے ہیں:

ہر پیغام گروپ کے اندر ایک مختلف سبسکرائبر کو پہنچایا جاتا ہے۔
ایک گروپ کے اندر، سبسکرائبرز کو ان کے نام سے پہچانا جاتا ہے، جو ایک کیس حساس سٹرنگ ہے۔ اگر کوئی سبسکرائبر عارضی طور پر گروپ سے باہر ہو جاتا ہے، تو اسے اپنا منفرد نام استعمال کر کے گروپ میں بحال کیا جا سکتا ہے۔
ہر صارف گروپ "پہلے بغیر پڑھے ہوئے پیغام" کے تصور کی پیروی کرتا ہے۔ جب کوئی سبسکرائبر نئے پیغامات کی درخواست کرتا ہے، تو وہ صرف وہ پیغامات وصول کر سکتا ہے جو پہلے کبھی گروپ کے اندر کسی سبسکرائبر کو نہیں پہنچائے گئے ہوں۔
واضح طور پر اس بات کی تصدیق کرنے کے لیے ایک کمانڈ موجود ہے کہ سبسکرائبر کے ذریعے پیغام پر کامیابی کے ساتھ کارروائی ہوئی ہے۔ جب تک اس کمانڈ کو کال نہیں کیا جاتا، درخواست کردہ پیغام "پینڈنگ" اسٹیٹس میں رہے گا۔
کنزیومر گروپ کے اندر، ہر سبسکرائبر ان پیغامات کی سرگزشت کی درخواست کر سکتا ہے جو اسے پہنچائے گئے تھے، لیکن ابھی تک اس پر کارروائی نہیں ہوئی ہے ("زیر التواء" حالت میں)

ایک لحاظ سے، گروپ کی حالت کا اظہار اس طرح کیا جا سکتا ہے:

+----------------------------------------+
| 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 اور اختیاری بلاک آپشن کی حمایت کرتا ہے۔ تاہم، ایک مطلوبہ 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 آپ ایک ہی وقت میں متعدد مختلف تھریڈز سے پیغامات پڑھ سکتے ہیں، تاہم اس کے کام کرنے کے لیے آپ کو پہلے ہر تھریڈ کے لیے ایک ہی نام کے گروپس بنانے ہوں گے۔ ایکس گروپ

ناکامی کے بعد بحالی

سبسکرائبر ناکامی سے باز آسکتا ہے اور اپنے پیغامات کی فہرست کو "پینڈنگ" اسٹیٹس کے ساتھ دوبارہ پڑھ سکتا ہے۔ تاہم، حقیقی دنیا میں، سبسکرائبرز بالآخر ناکام ہو سکتے ہیں۔ سبسکرائبر کے پھنسے ہوئے پیغامات کا کیا ہوتا ہے اگر سبسکرائبر ناکامی سے باز نہ آ سکے؟
کنزیومر گروپ ایک خصوصیت پیش کرتا ہے جو صرف ایسے ہی معاملات کے لیے استعمال ہوتا ہے - جب آپ کو پیغامات کے مالک کو تبدیل کرنے کی ضرورت ہوتی ہے۔

پہلی چیز جو آپ کو کرنے کی ضرورت ہے وہ ہے کمانڈ کو کال کریں۔ 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

اب ہمارے پاس ہر پیغام کی تفصیلات ہیں: آئی ڈی، سبسکرائبر کا نام، ملی سیکنڈ میں بیکار وقت اور آخر میں ترسیل کی کوششوں کی تعداد۔ ہمارے پاس باب کی طرف سے دو پیغامات ہیں اور وہ 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}
اس کمانڈ کا استعمال کرتے ہوئے، ہم ایک "غیر ملکی" پیغام وصول کر سکتے ہیں جس پر ابھی تک مالک کو تبدیل کرکے {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 آپشن صرف میسج آئی ڈی واپس کرنے کے لیے استعمال کیا جا سکتا ہے۔ اگر آپ پیغام کی تفصیلات میں دلچسپی نہیں رکھتے اور سسٹم کی کارکردگی کو بڑھانا چاہتے ہیں تو یہ مفید ہے۔

ڈلیوری کاؤنٹر

کاؤنٹر جو آپ آؤٹ پٹ میں دیکھتے ہیں۔ 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 استعمال کرتے وقت، پرانے ریکارڈز خود بخود حذف ہو جاتے ہیں جب وہ ایک مخصوص طوالت تک پہنچ جاتے ہیں، اس لیے ندی کا سائز مستقل رہتا ہے۔ تاہم، اس معاملے میں کٹائی Redis میموری میں سب سے زیادہ موثر طریقے سے نہیں ہوتی ہے۔ آپ مندرجہ ذیل صورت حال کو بہتر بنا سکتے ہیں:

XADD mystream MAXLEN ~ 1000 * ... entry fields here ...
اوپر دی گئی مثال میں ~ دلیل کا مطلب یہ ہے کہ ضروری نہیں کہ ہمیں ندی کی لمبائی کو کسی خاص قدر تک محدود کرنے کی ضرورت ہے۔ ہماری مثال میں، یہ 1000 سے بڑا یا اس کے برابر کوئی بھی نمبر ہو سکتا ہے (مثال کے طور پر، 1000، 1010، یا 1030)۔ ہم نے ابھی واضح طور پر بتایا ہے کہ ہم چاہتے ہیں کہ ہمارا سلسلہ کم از کم 1000 ریکارڈز کو محفوظ کرے۔ یہ Redis کے اندر میموری کا انتظام بہت زیادہ موثر بناتا ہے۔

ایک الگ ٹیم بھی ہے۔ XTRIM، جو ایک ہی کام کرتا ہے:

> XTRIM mystream MAXLEN 10

> XTRIM mystream MAXLEN ~ 10

مستقل اسٹوریج اور نقل

Redis Stream کو غیر مطابقت پذیر طور پر غلام نوڈس پر نقل کیا جاتا ہے اور فائلوں میں محفوظ کیا جاتا ہے جیسے AOF (تمام ڈیٹا کا سنیپ شاٹ) اور RDB (تمام تحریری کارروائیوں کا لاگ)۔ کنزیومر گروپس اسٹیٹ کی نقل بھی معاون ہے۔ لہذا، اگر کوئی پیغام ماسٹر نوڈ پر "پینڈنگ" اسٹیٹس میں ہے، تو غلام نوڈس پر اس پیغام کی وہی حیثیت ہوگی۔

ندی سے انفرادی عناصر کو ہٹانا

پیغامات کو حذف کرنے کے لیے ایک خاص حکم ہے۔ XDEL. کمانڈ کو تھریڈ کا نام ملتا ہے جس کے بعد میسج آئی ڈیز کو حذف کیا جانا ہے:

> 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 Stream پیغام بروکرز، پیغام کی قطار، متحد لاگنگ، اور ہسٹری کیپنگ چیٹ سسٹم بنانے کے لیے مثالی ہے۔

جیسا کہ میں نے ایک بار کہا تھا۔ نکلوس ورتھ، پروگرام الگورتھم کے علاوہ ڈیٹا ڈھانچے ہیں، اور Redis پہلے ہی آپ کو دونوں دیتا ہے۔

ماخذ: www.habr.com

Redis Stream - آپ کے پیغام رسانی کے نظام کی وشوسنییتا اور اسکیل ایبلٹی