ما هي Redis Streams؟

Question

Accepted Answer

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

## سجل مضاف فقط من الرسائل

```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 عبارة عن **سجل مضاف فقط**: تتم إضافة الإدخالات باستخدام `XADD` (كل منها برقم معرّف فريد مرتب زمنياً) وتستمر في البث — على عكس Pub/Sub، لا تُفقد الرسائل؛ يتم تخزينها وإعادة قراءتها.

## مجموعات المستهلكين — المعالجة الموثوقة والقابلة للتوسع

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

**مجموعات المستهلكين** توزع الرسائل على مستهلكين متعددين (معالجة التوسع)، مع توجيه كل رسالة إلى مستهلك واحد، **الإقرارات** (`XACK`) التي تؤكد المعالجة، و**الرسائل المعلقة/المطالبة** (`XPENDING`/`XCLAIM`) التي تضمن عدم فقدان الرسائل إذا تعطل المستهلك — توصيل موثوق وعلى الأقل مرة واحدة.

## 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 قيّم لـ **المراسلة الموثوقة ومعالجة الأحداث** ضمن Redis، لذا فهو معرفة مفيدة — خاصة لأن Streams تعالج القيود الرئيسية لـ Pub/Sub.

بينما Pub/Sub بسيط لكنه "أرسل وتجاهل" (المشتركون غير المتصلين يفقدون الرسائل بشكل دائم، بدون استمرار)، **توفر Streams مراسلة موثوقة**: **سجل دائم مضاف فقط** حيث يتم تخزين الرسائل (بدون فقدان) وإعادة قراءتها/تشغيلها، بالإضافة إلى **مجموعات المستهلكين** التي توزع الرسائل على مستهلكين متعددين لمعالجة قابلة للتوسع، **الإقرارات** (`XACK`) لتأكيد المعالجة، و**المطالبة برسائل معلقة** (`XPENDING`/`XCLAIM`) بحيث لا تُفقد الرسائل عندما يتعطل المستهلك — توصيل موثوق وقابل للتوسع ومرة واحدة على الأقل.

فهم **Streams مقابل Pub/Sub** (Streams للتوصيل الموثوق والسجل والمستهلكين القابلين للتوسع؛ Pub/Sub للبث الحقيقي البسيط حيث يكون الفقدان مقبولاً) مهم لاختيار البدائل الصحيحة لـ Redis للمراسلة.

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

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