Redis Streams کیا ہیں؟

Question

Accepted Answer

**Redis Streams** ایک append-only log ڈیٹا سٹرکچر ہے — جیسے ایک durable message queue یا event log — جو **consumer groups**، message persistence، acknowledgments، اور replay کو سپورٹ کرتا ہے۔ یہ Redis کا قابل اعتماد messaging کا جواب ہے، Pub/Sub سے زیادہ مضبوط (جو fire-and-forget ہے)۔

## پیغامات کا Append-only log

```bash
# add entries to a stream (each gets an auto ID: timestamp-sequence)
XADD events * type "signup" user "ann"     # * = auto-generate ID; returns e.g. 1700000000-0
XADD events * type "login" user "bob"

XLEN events                                 # number of entries
XRANGE events - +                           # read all entries (- to +)
XREAD COUNT 10 STREAMS events 0             # read entries (from ID 0)
```

Streams ایک **append-only log** ہے: entries `XADD` کے ساتھ شامل کی جاتی ہیں (ہر ایک کے ساتھ منفرد، time-ordered ID) اور stream میں persistent ہوتی ہیں — Pub/Sub کے برعکس، پیغامات ضائع نہیں ہوتے؛ وہ محفوظ ہیں اور دوبارہ پڑھے جا سکتے ہیں۔

## Consumer groups — قابل اعتماد، scalable processing

```bash
# create a consumer group to process the stream
XGROUP CREATE events workers 0

# consumers read messages (each message goes to ONE consumer in the group)
XREADGROUP GROUP workers consumer1 COUNT 1 STREAMS events >

# acknowledge a processed message (so it's not redelivered)
XACK events workers 1700000000-0
# unacknowledged messages can be reclaimed (XPENDING/XCLAIM) → no message lost on crash
```

**Consumer groups** پیغامات کو متعدد consumers میں تقسیم کرتے ہیں (processing کو scale کرتے ہوئے)، ہر پیغام ایک consumer کو جاتا ہے، **acknowledgments** (`XACK`) processing کی تصدیق کرتے ہیں، اور **pending/reclaim** (`XPENDING`/`XCLAIM`) یقینی بناتے ہیں کہ اگر consumer کریش ہو تو پیغامات ضائع نہ ہوں — قابل اعتماد، at-least-once delivery۔

## Streams بمقابلہ Pub/Sub

```text
PUB/SUB  → fire-and-forget; offline subscribers MISS messages; no persistence/replay
STREAMS  → PERSISTENT log; messages stored; consumer groups; acknowledgments; replay
  → Streams = when you need RELIABLE delivery, message history, and scalable consumers
  → Pub/Sub = simple real-time broadcast where missing messages is OK
Streams are similar to a lightweight Kafka (log + consumer groups).
```

## اس کا اہم مطلب

Redis Streams کو سمجھنا **قابل اعتماد messaging اور event processing** کے لیے Redis میں قیمتی ہے، تو یہ مفید علم ہے — خاص طور پر کیونکہ Streams Pub/Sub کی اہم محدودیت کو حل کرتے ہیں۔

جب کہ Pub/Sub سادہ لیکن fire-and-forget ہے (آف لائن subscribers مستقل طور پر پیغامات miss کرتے ہیں، کوئی persistence نہیں)، **Streams قابل اعتماد messaging فراہم کرتے ہیں**: ایک **append-only persistent log** جہاں پیغامات محفوظ ہیں (ضائع نہیں ہوتے) اور دوبارہ پڑھے/replay کیے جا سکتے ہیں، اضافی طور پر **consumer groups** جو پیغامات کو متعدد consumers میں تقسیم کرتے ہیں scalable processing کے لیے، **acknowledgments** (`XACK`) processing کی تصدیق کے لیے، اور **pending-message reclaim** (`XPENDING`/`XCLAIM`) تاکہ جب consumer کریش ہو تو پیغامات ضائع نہ ہوں — at-least-once، قابل اعتماد، scalable message processing فراہم کرتے ہیں۔

**Streams بمقابلہ Pub/Sub** کو سمجھنا (Streams قابل اعتماد delivery، history، اور scalable consumers کے لیے؛ Pub/Sub سادہ real-time broadcast کے لیے جہاں loss قابل قبول ہے) Redis messaging primitive کا انتخاب کرنے کے لیے اہم ہے۔

یہ پہچاننا کہ Streams **lightweight Kafka کی طرح** ہیں (log-based consumer groups کے ساتھ) ان کے کردار کو frame کرنے میں مدد دیتا ہے — Redis میں event-streaming/message-queue صلاحیتیں فراہم کرتے ہوئے الگ broker کے بغیر اعتدال پسند ضروریات کے لیے، جب کہ dedicated brokers (Kafka، RabbitMQ) بڑے پیمانے پر یا زیادہ مطالبہ کرنے والی messaging کے لیے مناسب رہتے ہیں۔

چونکہ قابل اعتماد messaging اور event processing عام ضروریات ہیں، اور چونکہ Redis Streams ایک مضبوط، persistent، consumer-group-based حل فراہم کرتے ہیں (Pub/Sub کی fire-and-forget محدودیت کو ختم کرتے ہوئے) Redis میں، Redis Streams کو سمجھنا — append-only log، consumer groups acknowledgments اور reclaim کے ساتھ، اور Pub/Sub اور Kafka کے ساتھ کیسے موازنہ ہوتا ہے — قیمتی، عملی علم ہے Redis کے ساتھ قابل اعتماد messaging اور event-driven features بنانے کے لیے، صحیح انتخاب جب آپ کو delivery guarantees اور message history کی ضرورت ہو جو Pub/Sub فراہم نہیں کر سکتے۔