كيف يعمل Redis Pub/Sub؟

Question

Accepted Answer

**Pub/Sub** (Publish/Subscribe) هو نمط المراسلة في Redis حيث يرسل **الناشرون** رسائل إلى **القنوات** ويستقبل **المشتركون** الرسائل من القنوات التي اشتركوا فيها — دون أن يعرف الناشرون والمشتركون بعضهم البعض. يمكّن المراسلة في الوقت الفعلي والتواصل المستقل بين الخدمات.

## نموذج 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.
```

ينشر الناشرون باستخدام `PUBLISH` إلى قناة؛ ويشترك المشتركون في القنوات باستخدام `SUBSCRIBE` ويستقبلون الرسائل في الوقت الفعلي. هم **مستقلون** — الناشر لا يعرف من (إن وجد) يستمع.

## حالات الاستخدام

```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)
```

## القيد المهم: إرسال ونسيان

```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 **المراسلة في الوقت الفعلي** حيث يبث الناشرون إلى القنوات ويستقبل المشتركون فوراً، مع كون الناشرين والمشتركين **مستقلين** (غير مدركين لبعضهم البعض) — مما يدعم حالات استخدام مثل الإشعارات في الوقت الفعلي والدردشة وتحديثات لوحة التحكم المباشرة والتواصل بين الخدمات المستقل (غالباً ما يقترن مع WebSockets لدفع التحديثات إلى المتصفحات).

هذا يجعل Redis خياراً بسيطاً وسريعاً لميزات البث في الوقت الفعلي.

ومع ذلك، فإن **النقطة الأهم** هي فهم قيد Pub/Sub في **إرسال ونسيان**: إنها توصيل من مرة واحدة على الأكثر — تصل الرسائل فقط للمشتركين المتصلين في تلك اللحظة، والمشتركون غير المتصلين **يفقدون الرسائل بشكل دائم** (لا توجد مثابرة أو إعادة تشغيل أو إقرار أو ضمان توصيل).

هذا قيد حاسم: Pub/Sub غير مناسب عندما يكون التوصيل الموثوق أو سجل الرسائل مهماً، وعدم فهم هذا يؤدي إلى أخطاء الرسائل المفقودة.

معرفة البدائل — **Redis Streams** (دائم، قائم على السجل، مع مجموعات المستهلكين والإقرارات) أو الوسطاء المخصصين (Kafka، RabbitMQ) للمراسلة الموثوقة — واختيار Pub/Sub فقط للبث في الوقت الفعلي البسيط حيث يكون فقدان الرسائل مقبولاً يعكس حكماً سليماً.

نظراً لأن المراسلة في الوقت الفعلي حاجة شائعة، وبما أن Redis Pub/Sub يوفر حلاً بسيطاً لها لكن مع قيود موثوقية مهمة (يتطلب Streams أو وسيط عندما تكون الضمانات ضرورية)، فإن فهم Pub/Sub — كيف يعمل وحالات استخدامه وبشكل خاص قيد إرساله ونسيانه ومتى تستخدم Streams بدلاً منه — معرفة قيمة وعملية الصلة لتنفيذ ميزات الوقت الفعلي بشكل صحيح، حيث يكون فهم القيد بنفس أهمية فهم القدرة.