Redis Streams అంటే ఏమిటి?

Question

Accepted Answer

**Redis Streams** అనేది append-only log డేటా స్ట్రక్చర్ — টిఫెరుడైన మెసేజ్ క్యూ లేదా ఈవెంట్ లాగ్ లాంటిది — **consumer groups**, మెసేజ్ persistence, acknowledgments, మరియు replay కు సపోర్టు ఇస్తుంది. అవి reliable 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 — reliable, scalable processing

```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 (scaling processing) అంతటా పంపిణీ చేస్తాయి, ప్రతి మెసేజ్ ఒక consumer కు వెళ్లి, **acknowledgments** (`XACK`) processing ని నిర్ధారిస్తాయి, మరియు **pending/reclaim** (`XPENDING`/`XCLAIM`) consumer క్రాష్ కూడా మెసేజ్‌లు కోల్పోనట్లు సంధర్భం చేస్తాయి — reliable, 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 ను అర్థం చేసుకోవడం **reliable messaging మరియు event processing** కోసం Redis లో విలువైనది, కనుక ఇది ఉపయోగకరమైన జ్ఞానం — ప్రత్యేకించి Streams Pub/Sub యొక్క కీలక పరిమితులను పరిష్కరించుకుంటుంది కాబట్టి.

Pub/Sub సాధారణ కానీ fire-and-forget (offline subscribers శాశ్వతంగా మెసేజ్‌లను కోల్పోతారు, persistence లేదు), **Streams reliable messaging ఇస్తాయి**: **append-only persistent log** ఇక్కడ మెసేజ్‌లు నిల్వ చేయబడతాయి (కోల్పోవు కాదు) మరియు విరుద్ధ-చదవబడతాయి/replay చేయబడతాయి, ప్లస్ **consumer groups** బహుళ consumers అంతటా మెసేజ్‌లను పంపిణీ చేసి processing సరిగా చేస్తాయి, **acknowledgments** (`XACK`) processing నిర్ధారించటానికి, మరియు **pending-message reclaim** (`XPENDING`/`XCLAIM`) consumer crash అయినప్పుడు మెసేజ్‌లు కోల్పోనట్లు — at-least-once, reliable, scalable message processing ఇస్తుంది.

**Streams vs Pub/Sub** అర్థం చేసుకోవడం (Streams reliable delivery, history, మరియు scalable consumers కోసం; Pub/Sub simple real-time broadcast కోసం ఇక్కడ loss అంగీకారమైనది) సరైన Redis messaging primitive ఎంచుకోవటానికి ముఖ్యమైనది.

Streams **lightweight Kafka లాంటివి** అని గుర్తించడం (log-based consumer groups తో) వాటి పాత్రను ఫ్రేమ్ చేయటానికి సహాయపడుతుంది — moderate చাహిదల కోసం separate broker లేకుండా Redis లోపల event-streaming/message-queue సామర్థ్యాలను ఇస్తుంది, అయితే dedicated brokers (Kafka, RabbitMQ) పెద్దపై-scale లేదా అధికమైన messaging కోసం సరిపోతాయి.

Reliable messaging మరియు event processing సాధారణ చాహిదలు, మరియు Redis Streams robust, persistent, consumer-group-based సమాధానం (Pub/Sub యొక్క fire-and-forget పరిమితిని అధిగమించటం) Redis లోపల ఇవ్వుతుంది కాబట్టి, Redis Streams అర్థం చేసుకోవడం — append-only log, consumer groups acknowledgments మరియు reclaim తో, మరియు Pub/Sub మరియు Kafka కు ఎలా సరిపోతాయో — valuable, practically-relevant జ్ఞానం Redis తో reliable messaging మరియు event-driven features నిర్మించటానికి, delivery guarantees మరియు message history అవసరమైన సందర్భంలో Pub/Sub ఇవ్వలేని సరైన ఎంపిక.