Redis Pub/Sub کیسے کام کرتا ہے?

Question

Accepted Answer

**Pub/Sub** (Publish/Subscribe) Redis کا میسجنگ پیٹرن ہے جہاں **publishers** **channels** کو پیغامات بھیجتے ہیں اور **subscribers** اُن channels سے پیغامات حاصل کرتے ہیں جن کی وہ رکنیت رکھتے ہیں — بغیر publishers اور subscribers ایک دوسرے کے بارے میں جانے۔ یہ حقیقی وقت میں میسجنگ اور خدمات کے درمیان نتھی شدہ رابطہ فراہم کرتا ہے۔

## Pub/Sub ماڈل

```bash
# Subscriber listens on a channel
SUBSCRIBE news                    # subscribe to the "news" channel

# Publisher sends a message to the channel (in another connection)
PUBLISH news "Breaking story!"    # all subscribers to "news" receive this instantly

# Pattern subscriptions (wildcards)
PSUBSCRIBE news.*                 # subscribe to news.sports, news.tech, etc.
```

Publishers `PUBLISH` کو ایک channel میں کرتے ہیں؛ subscribers `SUBSCRIBE` کو channels میں کرتے ہیں اور حقیقی وقت میں پیغامات حاصل کرتے ہیں۔ وہ **نتھی شدہ** ہوتے ہیں — publisher کو معلوم نہیں ہوتا کہ کون (اگر کوئی ہے تو) سن رہا ہے۔

## استعمال کے معاملات

```text
✓ REAL-TIME notifications — push events to interested services/clients instantly
✓ Chat / messaging — broadcast messages to subscribers
✓ Live updates — dashboards, feeds, multiplayer (broadcast state changes)
✓ Decoupling services — services communicate via channels without direct coupling
✓ Often paired with WebSockets (Redis pub/sub → server → WebSocket → browser)
```

## اہم پابندی: fire-and-forget

```text
⚠️ Redis Pub/Sub is FIRE-AND-FORGET (at-most-once delivery):
  → Messages are delivered ONLY to subscribers connected AT THAT MOMENT.
  → If a subscriber is offline/disconnected, it MISSES the message (no storage/replay).
  → No persistence, no acknowledgment, no delivery guarantee.
→ NOT suitable when you need reliable delivery or message history.
```

## جب آپ کو قابل اعتماد رسائی کی ضرورت ہو: Streams استعمال کریں

```text
For RELIABLE messaging (persistence, replay, consumer groups, acknowledgments):
  → use Redis STREAMS (a durable, log-based structure) instead of Pub/Sub
  → or a dedicated message broker (Kafka, RabbitMQ)
Pub/Sub → simple real-time broadcast where missing messages is acceptable
Streams → when you need durability and delivery guarantees
```

## اس سے کیوں فرق پڑتا ہے

Redis Pub/Sub سمجھنا **حقیقی وقت میں میسجنگ اور نتھی شدہ رابطہ** کے لیے قیمتی ہے، اس لیے یہ مفید علم ہے — لیکن سب سے اہم بات، اس کی پابندیوں کو سمجھنا یکساں اہم ہے تاکہ اسے مناسب طریقے سے استعمال کیا جا سکے۔

Pub/Sub **حقیقی وقت میں میسجنگ** فراہم کرتا ہے جہاں publishers channels کو نشر کرتے ہیں اور subscribers فوری طور پر حاصل کرتے ہیں، جس میں publishers اور subscribers **نتھی شدہ** ہوتے ہیں (ایک دوسرے سے لاتعلق) — حقیقی وقت میں اطلاعات، چیٹ، لائیو ڈیش بورڈ اپڈیٹس، اور نتھی شدہ خدمتی رابطہ (اکثر ویب ساکٹس کے ساتھ براؤزرز کو اپڈیٹس پہنچانے کے لیے) جیسے معاملات کو طاقت دے رہے ہوتے ہیں۔

یہ Redis کو حقیقی وقت میں نشریاتی خصوصیات کے لیے ایک سادہ، تیز اختیار بناتا ہے۔

تاہم، **سب سے اہم نکتہ** Pub/Sub کی **fire-and-forget پابندی** کو سمجھنا ہے: یہ at-most-once ڈیلیوری ہے — پیغامات صرف وہ subscribers تک پہنچتے ہیں جو اس لمحے جڑے ہوئے ہوں، اور آف لائن subscribers **پیغامات کو مستقل طور پر ضائع کر دیتے ہیں** (کوئی استحکام، دوبارہ چلانا، تسلیم، یا ڈیلیوری کی ضمانت نہیں)۔

yہ ایک اہم رکاوٹ ہے: Pub/Sub نامناسب ہے جب قابل اعتماد ڈیلیوری یا پیغام کی تاریخ اہم ہو، اور اس کو نہ سمجھنے سے پیغام کے ضائع ہونے کے نقائص پیدا ہوتے ہیں۔

متبادلات کو جاننا — **Redis Streams** (مستحکم، لاگ پر مبنی، صارف کی گروپس اور تسلیمات کے ساتھ) یا وقف شدہ brokers (Kafka، RabbitMQ) قابل اعتماد میسجنگ کے لیے — اور صرف سادہ حقیقی وقت نشر کے لیے Pub/Sub منتخب کرنا جہاں پیغامات ضائع ہونا قابل قبول ہو درست فیصلہ ظاہر کرتا ہے۔

چونکہ حقیقی وقت میں میسجنگ عام ضرورت ہے، اور Redis Pub/Sub اس کے لیے سادہ حل فراہم کرتا ہے لیکن اہم قابل اعتماد پابندیوں کے ساتھ (جب ضمانتیں ضروری ہوں تو Streams یا broker کی ضرورت)، Pub/Sub کو سمجھنا — یہ کیسے کام کرتا ہے، اس کے معاملات، اور خاص طور پر اس کی fire-and-forget پابندی اور کب Streams استعمال کریں — حقیقی وقت کی خصوصیات کو صحیح طریقے سے لاگو کرنے کے لیے قیمتی، عملی طور پر متعلقہ علم ہے، جہاں پابندی کو سمجھنا صلاحیت کو سمجھنے جتنا ہی اہم ہے۔