Redis Streams ਕੀ ਹਨ?

Question

Accepted Answer

**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 ਹੈ)।

## ਸੁਨੇਹਿਆਂ ਦਾ 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 ਵਿੱਚ distribute ਕਰਦੇ ਹਨ (processing ਨੂੰ scale ਕਰਦੇ ਹੋਏ), ਹਰੇਕ ਸੁਨੇਹਾ ਇੱਕ consumer ਕੋਲ ਜਾਂਦਾ ਹੈ, **acknowledgments** (`XACK`) processing ਦੀ confirm ਕਰਦੇ ਹਨ, ਅਤੇ **pending/reclaim** (`XPENDING`/`XCLAIM`) ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਜੇ ਇੱਕ consumer crash ਹੋ ਜਾਵੇ ਤਾਂ ਸੁਨੇਹੇ ਗੁੰਮ ਨਹੀਂ ਹੁੰਦੇ — 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 ਦੀਆਂ ਮੁੱਖ ਸੀਮਾਵਾਂ ਨੂੰ address ਕਰਦੇ ਹਨ।

جہاں Pub/Sub ਸਧਾਰਨ ਪਰ fire-and-forget ਹੈ (offline subscribers ਸਥਾਈ ਤੌਰ ਤੇ ਸੁਨੇਹੇ ਮਿਸ ਕਰਦੇ ਹਨ, کوئی persistence ਨਹੀਂ), **Streams reliable messaging ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ**: ਇੱਕ **append-only persistent log** ਜਿੱਥੇ ਸੁਨੇਹੇ ਸਟੋਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ (ਗੁੰਮ ਨਹੀਂ ਹੁੰਦੇ) ਅਤੇ ਦੁਬਾਰਾ ਪੜ੍ਹੇ/replayed ਜਾ ਸਕਦੇ ਹਨ, ਅਲਾਵਾ **consumer groups** ਜੋ ਸਕੇਲੇਬਲ processing ਲਈ ਬਹੁਤ ਸਾਰੇ consumers ਵਿੱਚ ਸੁਨੇਹੇ distribute ਕਰਦੇ ਹਨ, **acknowledgments** (`XACK`) processing ਦੀ confirm ਕਰਨ ਲਈ, ਅਤੇ **pending-message reclaim** (`XPENDING`/`XCLAIM`) ਪਿੱਛੇ ਆਇਆ ਜਾਂ ਕਰੈਸ਼ ਹੋ ਗਿਆ consumer — at-least-once, reliable, scalable message processing ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

**Streams vs Pub/Sub** ਨੂੰ ਸਮਝਣਾ (Streams reliable delivery, history, ਅਤੇ scalable consumers ਲਈ; Pub/Sub ਸਧਾਰਨ real-time broadcast ਲਈ ਜਿੱਥੇ loss ਸਵੀਕਾਰ ਹੋ) ਸਹੀ Redis messaging primitive ਚੁਣਨ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ।

ਇਹ ਪਛਾਣਨਾ ਕਿ Streams **lightweight Kafka ਦੇ ਸਮਾਨ** ਹਨ (log-based with consumer groups) ਉਹਨਾਂ ਦੀ ਭੂਮਿਕਾ ਨੂੰ frame ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ — event-streaming/message-queue capabilities ਨੂੰ Redis ਦੇ ਅੰਦਰ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ moderate needs ਲਈ ਵੱਖ broker ਦੀ ਲੋੜ ਤੋਂ ਬਿਨਾਂ, جبکہ dedicated brokers (Kafka, RabbitMQ) ਵੱਡੇ ਪੱਮਾਣ ਜਾਂ ਵਧੇਰੇ demanding messaging ਲਈ مناسب ਰਹਿਦੇ ਹਨ।

چونکہ reliable messaging ਅਤੇ event processing عام ضروريات ਹਨ, ਅਤੇ چونکہ Redis Streams ਇੱਕ مضبوط, persistent, consumer-group-based ਹੱਲ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ (Pub/Sub ਦੀ fire-and-forget ਸੀਮਾ ਨੂੰ overcome ਕਰਦੇ ਹੋਏ) Redis ਦੇ ਅੰਦਰ, Redis Streams ਨੂੰ ਸਮਝਣਾ — append-only log, consumer groups with acknowledgments ਅਤੇ reclaim, ਅਤੇ Pub/Sub ਅਤੇ Kafka ਨਾਲ ਸਮਾਨ ਤਾ — ਮੁਲਸ ਹੈ, practically-relevant ਜਾਣਕਾਰੀ Redis ਦੇ ਨਾਲ reliable messaging ਅਤੇ event-driven features ਬਣਾਉਣ ਲਈ, ਸਹੀ ਚੋਣ ਜਦ ਤੁਹਾਨੂੰ delivery guarantees ਅਤੇ message history ਦੀ ਲੋੜ ਹੈ ਜੋ Pub/Sub ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰ ਸਕਦਾ।