Redis Streams શું છે?

Question

Accepted Answer

**Redis Streams** એ append-only log ડેટા સ્ટ્રક્ચર છે — જેવું કે durable message queue અથવા event log — જે **consumer groups**, message persistence, acknowledgments, અને replay સપોર્ટ કરે છે. તે reliable messaging માટે Redis નો જવાબ છે, જે Pub/Sub કરતાં વધુ મજબૂત છે (જે fire-and-forget છે).

## Messages નો 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 ની જેમ નહીં, messages lost નથી થતા; તેઓ store થાય છે અને ફરીથી વાંચી શકાય છે.

## 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** messages ને multiple consumers માં વહેંચે છે (processing ને scale કરતાં), દરેક message એક consumer ને જાય છે, **acknowledgments** (`XACK`) processing ને confirm કરે છે, અને **pending/reclaim** (`XPENDING`/`XCLAIM`) নিશ્ચિત કરે છે કે જો consumer crash થાય તો messages lost ન થાય — 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 સ્થાયી રીતે messages ચૂકી જાય છે, કોઈ persistence નથી), જ્યારે **Streams reliable messaging પ્રદાન કરે છે**: એક **append-only persistent log** જ્યાં messages store થાય છે (lost નથી થતા) અને ફરીથી વાંચી/replay કરી શકાય છે, અલાવા **consumer groups** જે messages ને multiple consumers માં વહેંચે છે scalable processing માટે, **acknowledgments** (`XACK`) processing ને confirm કરે છે, અને **pending-message reclaim** (`XPENDING`/`XCLAIM`) તેથી messages lost ન થાય જ્યારે 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 સાથે) તેમની ભૂમિકા frame કરવામાં મદદ કરે છે — event-streaming/message-queue capabilities Redis માં પ્રદાન કરતાં separate broker વગર moderate needs માટે, જ્યારે dedicated brokers (Kafka, RabbitMQ) મોટા-પાયે અથવા વધુ demanding messaging માટે યોગ્ય રહે છે.

Jrelิable 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 સાથે સરખાય છે — મૂલ્યવાન, વ્યવહારિક રીતે સંબંધિત જ્ઞાન છે Redis સાથે reliable messaging અને event-driven features બાંધવા માટે, યોગ્ય પસંદ જ્યારે તમને delivery guarantees અને message history જોઈએ છે જે Pub/Sub આપી શકે નથી.