Redis Streams एक append-only log data structure हैं — एक durable message queue या event log की तरह — जो consumer groups, message persistence, acknowledgments, और replay को support करते हैं। ये reliable messaging के लिए Redis का उत्तर हैं, Pub/Sub (जो fire-and-forget है) से अधिक robust।
XADD events * user
XADD events * user
XLEN events
XRANGE events - +
XREAD COUNT 10 STREAMS events 0
Streams एक append-only log हैं: entries XADD के साथ जोड़ी जाती हैं (प्रत्येक का एक unique, time-ordered ID होता है) और stream में persist होती हैं — Pub/Sub के विपरीत, messages खोते नहीं हैं; वे संग्रहीत होते हैं और फिर से पढ़े जा सकते हैं।
# 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 messages को कई consumers में distribute करते हैं (processing को scale करते हुए), प्रत्येक message एक consumer के पास जाता है, acknowledgments (XACK) processing की पुष्टि करते हैं, और pending/reclaim (XPENDING/XCLAIM) यह सुनिश्चित करते हैं कि consumer के crash होने पर messages खोएँ नहीं — reliable, at-least-once delivery।
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 के भीतर reliable messaging और event processing के लिए मूल्यवान है, इसलिए यह उपयोगी ज्ञान है — विशेष रूप से क्योंकि Streams Pub/Sub की प्रमुख limitations को संबोधित करते हैं।
हालाँकि Pub/Sub सरल है लेकिन fire-and-forget है (offline subscribers स्थायी रूप से messages चूक जाते हैं, कोई persistence नहीं), Streams reliable messaging प्रदान करते हैं: एक append-only persistent log जहाँ messages संग्रहीत होते हैं (खोते नहीं) और फिर से पढ़े/replay किए जा सकते हैं, साथ ही consumer groups जो scalable processing के लिए messages को कई consumers में distribute करते हैं, acknowledgments (XACK) processing की पुष्टि के लिए, और pending-message reclaim (XPENDING/XCLAIM) ताकि consumer के crash होने पर messages खोएँ नहीं — at-least-once, reliable, scalable message processing प्रदान करते हुए।
Streams बनाम Pub/Sub को समझना (reliable delivery, history, और scalable consumers के लिए Streams; simple real-time broadcast जहाँ loss स्वीकार्य हो उसके लिए Pub/Sub) सही Redis messaging primitive चुनने के लिए महत्वपूर्ण है।
यह पहचानना कि Streams एक lightweight Kafka के समान हैं (consumer groups के साथ log-based) उनकी भूमिका को परिभाषित करने में मदद करता है — एक separate broker के बिना Redis के भीतर event-streaming/message-queue क्षमताएँ प्रदान करना मध्यम आवश्यकताओं के लिए, जबकि dedicated brokers (Kafka, RabbitMQ) बड़े पैमाने या अधिक मांग वाली messaging के लिए उपयुक्त रहते हैं।
चूँकि reliable messaging और event processing आम आवश्यकताएँ हैं, और चूँकि Redis Streams Redis के भीतर एक robust, persistent, consumer-group-based समाधान प्रदान करते हैं (Pub/Sub की fire-and-forget limitation को पार करते हुए), Redis Streams को समझना — append-only log, acknowledgments और reclaim के साथ consumer groups, और वे Pub/Sub और Kafka से कैसे तुलना करते हैं — Redis के साथ reliable messaging और event-driven features बनाने के लिए मूल्यवान, व्यावहारिक रूप से प्रासंगिक ज्ञान है, सही विकल्प जब आपको delivery guarantees और message history चाहिए जो Pub/Sub प्रदान नहीं कर सकता।