什么是 Redis Streams？

Question

什么是 Redis Streams？

Accepted Answer

**Redis Streams** 是一个 append-only log 数据结构 — 就像一个持久化的消息队列或事件日志 — 支持 **consumer groups**、消息持久化、确认机制和重放。这是 Redis 对可靠消息传递的解决方案，比 Pub/Sub（火即忘方式）更加强大。

## 消息的 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**：条目通过 `XADD` 添加（每个条目都有唯一的、时间有序的 ID），并持久化在 stream 中 — 不同于 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** 将消息分配给多个消费者（扩展处理能力），每条消息只发送给一个消费者，**确认机制**（`XACK`）确认处理完成，**待处理/回收**（`XPENDING`/`XCLAIM`）确保消费者崩溃时消息不会丢失 — 提供可靠的、至少一次交付。

## Streams 与 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 对于 Redis 中的 **可靠消息传递和事件处理** 很有价值，因此这是实用知识 — 特别是因为 Streams 解决了 Pub/Sub 的关键局限性。

Pub/Sub 很简单但是火即忘方式（离线订阅者永久丢失消息，无持久化），而 **Streams 提供可靠消息传递**：一个 **append-only 持久化日志**，其中消息被存储（不会丢失）并可以被重新读取/重放，加上 **consumer groups** 将消息分配给多个消费者以实现可扩展处理，**确认机制**（`XACK`）确认处理，以及 **待处理消息回收**（`XPENDING`/`XCLAIM`）以便消费者崩溃时消息不会丢失 — 提供至少一次、可靠、可扩展的消息处理。

理解 **Streams 与 Pub/Sub 的比较**（Streams 用于可靠交付、历史和可扩展消费者；Pub/Sub 用于简单的实时广播，其中丢失是可以接受的）对于选择正确的 Redis 消息原语很重要。

认识到 Streams **类似于轻量级 Kafka**（基于日志的 consumer groups）有助于理解它们的角色 — 在 Redis 中提供事件流/消息队列功能，无需为中等规模的需求配置单独的 broker，而专用 broker（Kafka、RabbitMQ）仍然适合更大规模或更复杂的消息传递。

由于可靠消息传递和事件处理是常见需求，而且 Redis Streams 提供了一个强大的、持久化的、基于 consumer group 的解决方案（克服了 Pub/Sub 的火即忘局限）在 Redis 中，理解 Redis Streams — append-only log、带有确认和回收的 consumer groups、以及它们与 Pub/Sub 和 Kafka 的比较 — 是有价值的、具有实际意义的知识，用于使用 Redis 构建可靠的消息传递和事件驱动功能，当你需要 Pub/Sub 无法提供的交付保证和消息历史时这是正确的选择。