Redis Streams म्हणजे काय?

Question

Accepted Answer

**Redis Streams** हे append-only log डेटा स्ट्रक्चर आहेत — टिकाऊ मेसेज क्यू किंवा इव्हेंट लॉग सारखे — **consumer groups**, मेसेज persistence, acknowledgments, आणि replay यांना समर्थन देतात. हे विश्वसनीय messaging साठी Redis चे उत्तर आहे, 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` सह जोडली जातात (प्रत्येकाचा unique, time-ordered ID असतो) आणि stream मध्ये persist होतात — Pub/Sub असल्याच्या विपरीत, मेसेज हरवत नाहीत; ते संचयित होतात आणि पुन्हा वाचले जाऊ शकतात.

## Consumer groups — विश्वसनीय, स्केलेबल प्रोसेसिंग

```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 (प्रोसेसिंग स्केल करून) मध्ये मेसेज वितरित करतात, प्रत्येक मेसेज एका consumer ला जातो, **acknowledgments** (`XACK`) प्रोसेसिंग पुष्टी करतात, आणि **pending/reclaim** (`XPENDING`/`XCLAIM`) सुनिश्चित करतात की consumer क्रॅश झाल्यास मेसेज हरवत नाहीत — विश्वसनीय, at-least-once delivery.

## Streams vs 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 आहे (offline subscribers कायमचे मेसेज मिस करतात, कोणतीही persistence नाही), तर **Streams विश्वसनीय messaging प्रदान करतात**: एक **append-only persistent log** जेथे मेसेज संचयित होतात (हरवत नाहीत) आणि पुन्हा वाचले/replayed केले जाऊ शकतात, अधिक **consumer groups** जे अनेक consumers मध्ये मेसेज वितरित करतात स्केलेबल प्रोसेसिंगसाठी, **acknowledgments** (`XACK`) प्रोसेसिंग पुष्टी करण्यासाठी, आणि **pending-message reclaim** (`XPENDING`/`XCLAIM`) जेणेकरून consumer क्रॅश झाल्यास मेसेज हरवत नाहीत — at-least-once, विश्वसनीय, स्केलेबल मेसेज प्रोसेसिंग प्रदान करतात.

**Streams vs Pub/Sub** समजणे (विश्वसनीय delivery, history, आणि स्केलेबल consumers साठी Streams; साधे real-time broadcast साठी Pub/Sub जेथे loss स्वीकार्य आहे) सही Redis messaging primitive निवडण्यासाठी महत्वाचे आहे.

Osservare करणे की Streams **lightweight Kafka सारखे** आहेत (log-based consumer groups सह) त्यांची भूमिका समजून घेण्यास मदत करते — moderate गरजांसाठी Redis मध्ये event-streaming/message-queue क्षमता प्रदान करते, वेगळ्या broker शिवाय, तर dedicated brokers (Kafka, RabbitMQ) मोठ्या-स्केल किंवा अधिक demanding messaging साठी योग्य राहतात.

विश्वसनीय messaging आणि event processing हे सामान्य गरजा असल्याने, आणि Redis Streams robust, persistent, consumer-group-based solution (Pub/Sub च्या fire-and-forget मर्यादा दूर करून) प्रदान करत असल्याने Redis मध्ये, Redis Streams समजणे — append-only log, consumer groups with acknowledgments आणि reclaim, आणि ते Pub/Sub आणि Kafka शी कसे तुलना करतात — विश्वसनीय messaging आणि event-driven features Redis सह बिल्ड करण्यासाठी मूल्यवान, व्यावहारिकदृष्ट्या relevant ज्ञान आहे, delivery guarantees आणि message history ची गरज असल्यावर योग्य निवड जी Pub/Sub प्रदान करू शकत नाही.