---
tags: [Redis, 缓存, Stream, 消息队列]
create time: 2026-05-24 10:00
---

# Redis Stream 消息队列

## 概述

Redis Stream 是 Redis 5.0 引入的日志型数据结构，专门为**可靠消息传递**设计。它弥补了 Pub/Sub 「发完即忘、不持久化」的先天缺陷，同时又比 Kafka/RabbitMQ 这类外部中间件轻量——不需要额外部署组件，复用已有的 Redis 实例即可。

> [!question] Pub/Sub 够用吗？为什么要用 Stream？
> Pub/Sub 的核心问题：消息**不持久化**，订阅者下线就丢失。Stream 将每条消息追加写入内存（可配合 AOF 持久化），并通过 Consumer Group 实现**消费确认**机制——消息只有被 ACK 后才算真正消费完成。这使得 Stream 能胜任任务队列、事件溯源等对可靠性有要求的场景。

## 一、核心概念

### 基本操作命令

```bash
# === 生产者 ===
XADD mystream * field1 value1 field2 value2
# * 表示自动生成 ID（时间戳-序号），如 1685000000000-0

# === 消费者（无消费者组模式）===
XREAD COUNT 10 BLOCK 5000 STREAMS mystream 0
# BLOCK 5000 = 最多等 5 秒；0 = 从头读取
# 返回一批 XEntry，每条包含 ID + fields

# === 消费者组模式（推荐）===
XGROUP CREATE mystream mygroup $    # $ = 只消费创建后的新消息
XREADGROUP GROUP mygroup consumer1 COUNT 1 BLOCK 5000 STREAMS mystream >
# > 表示「只取未分配的新消息」
# 返回后消息进入该消费者的 pending 列表

XACK mystream mygroup <entry-id>    # 确认消费完成
```

> [!tip] `>` vs `$` vs `0` —— 三个特殊 ID
> | ID | 含义 | 典型场景 |
> |---|------|---------|
> | `0` | Stream 的第一条消息 | 数据重放、全量回溯 |
> | `$` | 当前最新消息的 ID | `XGROUP CREATE` 时指定起始点 |
> | `>` | 只返回组内**尚未投递给任何消费者**的消息 | `XREADGROUP` 正常消费循环 |
>
> 注意：`>` 只在 `XREADGROUP` 中有意义。如果传 `0` 读取消费者组，则返回该消费者的 **pending 消息**而非新消息——这在"重启后恢复未完成任务"场景中非常有用。

### Stream ID 自动生成机制

ID 格式为 `<毫秒时间戳>-<序号>`，由 Redis 服务器生成（用 `*` 时）。规则如下：

1. **时间戳部分**：取当前毫秒级 Unix 时间戳
2. **序号部分**：同一毫秒内递增（从 0 开始）；如果时间戳前进到下一毫秒，序号重置为 0

```bash
XADD mystream * k v    # 返回 1685000000000-0
XADD mystream * k v    # 同一毫秒内 → 1685000000000-1
XADD mystream * k v    # 跨毫秒后 → 1685000000001-0
```

> [!question] 能手动指定 ID 吗？
> 可以，但必须**严格递增**。新 ID 必须大于 Stream 中已有最大 ID，否则报错 `(ERR) The ID specified in XADD is equal or smaller than the target stream top item`。手动指定 ID 的典型场景：数据迁移、事件溯源回放。

### 底层存储结构

每条消息以 Radix Tree + Listpack 存储，追加写入时间复杂度 O(1)。同一时间戳内的多条消息会紧凑打包在 Listpack 节点中，极大节省内存。

> [!question] Stream 会像 List 一样消费后删除吗？
> 不会。Stream 是**只追加日志**，消息消费后仍在。需要显式 `XDEL` 或通过 `MAXLEN`/`MINID` 策略裁剪。这带来了「可回溯」的优势，但也意味着必须主动管理容量。

### 历史消息读取

消费者组模式适用于"实时消费"，但有时你需要**按范围回溯历史消息**——比如排障、数据对账、事件溯源。这时用 `XRANGE`/`XREVRANGE`：

```bash
# 按 ID 范围读取：从最小 ID 到最大 ID，最多 10 条
XRANGE mystream - + COUNT 10
# - = 最小 ID，+ = 最大 ID

# 按时间范围读取（ID 只需写时间戳部分，序号默认为 0）
XRANGE mystream 1685000000000 1685000060000 COUNT 10

# 反向读取（从新到旧）
XREVRANGE mystream + - COUNT 5

# 获取 stream 长度
XLEN mystream
```

> [!tip] `XRANGE` vs `XREAD`
> `XREAD` 适合**持续阻塞消费**（配合 `BLOCK`），是生产者的标准读法。`XRANGE` 适合**一次性按范围查询**，不阻塞，常用于排障和数据审计。两者互补，不要混淆。

## 二、Consumer Group 机制详解

Consumer Group 是 Stream 的核心抽象，它让多个消费者**协作消费同一条 Stream**，每条消息只会被组内的一个消费者处理。

### 消息生命周期

```mermaid
flowchart TD
    P["Producer"] -->|"XADD"| S["Stream"]
    S -->|"XREADGROUP"| C1["Consumer A"]
    S -->|"XREADGROUP"| C2["Consumer B"]
    C1 -->|"XACK"| S
    C2 -->|"XACK"| S
    C1 -.->|"crashed"| PDL["Pending List"]
    PDL -->|"XCLAIM"| C2
    C2 -->|"XACK"| S

    style S fill:#dfd,stroke:#090
    style C1 fill:#ddf,stroke:#669
    style C2 fill:#ddf,stroke:#669
    style PDL fill:#fdd,stroke:#f00
```

### Pending List（待确认列表）

当消费者通过 `XREADGROUP GROUP ... >` 读取消息后，消息进入该消费者的 **PEL（Pending Entry List）**。只有显式调用 `XACK` 后才会移除。

```bash
# 查看组内 pending 状态
XPENDING mystream mygroup

# 更详细的 pending 信息（包含消费者、空闲时间）
XPENDING mystream mygroup - + 10   # 返回最多 10 条 pending 条目
```

XPENDING 返回字段：

| 字段 | 含义 |
|------|------|
| `message-id` | 消息 ID |
| `consumer` | 被分配的消费者 |
| `idle-ms` | 自读取以来的空闲时间（毫秒） |
| `delivery-count` | 被投递的次数（重试计数器） |

> [!tip] Pending 是 Stream 的「可靠性根基」
> Pub/Sub 没有 pending 概念，消息发出去就消失了。Stream 的 PEL 记录了「谁领了哪条消息、领了多久、重试了几次」，这就是「至少一次投递」语义的实现基础。

### 消费者组内部机制

```mermaid
sequenceDiagram
    participant P as Producer
    participant S as Stream
    participant G as Consumer Group
    participant C1 as Consumer A
    participant C2 as Consumer B

    P->>S: XADD msg-1
    P->>S: XADD msg-2
    P->>S: XADD msg-3
    C1->>G: XREADGROUP COUNT 2
    G->>S: 分配 msg-1, msg-2
    S-->>C1: msg-1, msg-2 (pending)
    C2->>G: XREADGROUP COUNT 2
    G->>S: 分配 msg-3
    S-->>C2: msg-3 (pending)
    C1->>S: XACK msg-1
    C1->>S: XACK msg-2
    C2->>S: XACK msg-3
```

> [!question] 消息是如何分配给消费者的？
> Redis 采用**轮询分配**（round-robin）：新消息到达时，依次分配给组内活跃的消费者。注意不是负载均衡——如果某个消费者处理慢，它积压的 pending 消息不会自动转移给其他消费者，需要通过 XCLAIM 手动认领。

> [!tip] NOACK 模式——高吞吐场景的取舍
> `XREADGROUP` 支持 `NOACK` 选项，消息读取后**跳过 PEL，直接视为已消费**。适用于对可靠性要求不高但吞吐要求极高的场景（如实时指标采样）。代价是消费者崩溃时消息会永久丢失。
> ```bash
> XREADGROUP GROUP mygroup consumer1 NOACK COUNT 10 BLOCK 5000 STREAMS mystream >
> ```

### XINFO —— 运维监控利器

排查 Stream 问题时，`XINFO` 是你的第一选择：

```bash
# 查看 stream 元信息（长度、首尾 ID、消费者组数量）
XINFO STREAM mystream

# 查看消费者组列表
XINFO GROUPS mystream

# 查看组内各消费者状态（pending 数、空闲时间）
XINFO CONSUMERS mystream mygroup
```

> [!tip] 运维小贴士
> 监控脚本可以定期执行 `XINFO CONSUMERS`，如果某个消费者的 `idle` 值远超阈值且 pending 不为 0，说明该消费者可能已宕机，需要触发 XCLAIM 或告警。

## 三、Go 实战

### 生产者

```go
// StreamProducer 封装了 Stream 的写入逻辑
type StreamProducer struct {
    rdb      *redis.Client
    stream   string
    maxSize  int64 // MAXLEN 裁剪阈值
}

func NewStreamProducer(rdb *redis.Client, stream string) *StreamProducer {
    return &StreamProducer{rdb: rdb, stream: stream, maxSize: 100000}
}

func (p *StreamProducer) Publish(ctx context.Context, fields map[string]interface{}) (string, error) {
    // XADD 的 ApproximateMaxLen 约等于 MAXLEN ~，性能更好
    id, err := p.rdb.XAdd(ctx, &redis.XAddArgs{
        Stream: p.stream,
        ApproximateMaxLen: true, // ~ 模式，不精确计数但更快
        MaxLen: p.maxSize,
        Values: fields,
    }).Result()
    if err != nil {
        return "", fmt.Errorf("XADD failed: %w", err)
    }
    return id, nil
}
```

### 消费者（含重连与重试）

```go
type StreamConsumer struct {
    rdb        *redis.Client
    stream     string
    group      string
    consumer   string
    handler    func(ctx context.Context, msg redis.XMessage) error
    batchSize  int64
    blockTime  time.Duration
}

func (c *StreamConsumer) Start(ctx context.Context) {
    for {
        select {
        case <-ctx.Done():
            return
        default:
            // XREADGROUP 阻塞读取
            streams, err := c.rdb.XReadGroup(ctx, &redis.XReadGroupArgs{
                Group:    c.group,
                Consumer: c.consumer,
                Streams:  []string{c.stream, ">"}, // > = 只取新消息
                Count:    c.batchSize,
                Block:    c.blockTime,
            }).Result()

            if err != nil {
                if errors.Is(err, redis.Nil) {
                    continue // 超时无消息，正常
                }
                log.Printf("XReadGroup error: %v, retrying...", err)
                time.Sleep(time.Second) // 退避重试
                continue
            }

            for _, stream := range streams {
                for _, msg := range stream.Messages {
                    if err := c.handler(ctx, msg); err != nil {
                        log.Printf("handler error for %s: %v", msg.ID, err)
                        continue // 不 ACK，消息留在 pending 列表
                    }
                    // 处理成功，确认消费
                    if err := c.rdb.XAck(ctx, c.stream, c.group, msg.ID).Err(); err != nil {
                        log.Printf("XAck error for %s: %v", msg.ID, err)
                    }
                }
            }
        }
    }
}
```

> [!tip] 不 ACK = 进入 pending
> `handler` 返回 error 时跳过 `XACK`，这条消息会留在消费者的 PEL 中。后续通过 XPENDING + XCLAIM 捞回重试——这就是 Stream 实现「至少一次投递」的关键。

### 初始化消费者组

```go
func EnsureGroup(ctx context.Context, rdb *redis.Client, stream, group string) error {
    // MKSTREAM: 如果 stream 不存在则自动创建
    err := rdb.XGroupCreateMkStream(ctx, stream, group, "$").Err()
    if err != nil && !strings.Contains(err.Error(), "BUSYGROUP") {
        return err
    }
    // BUSYGROUP = 组已存在，忽略即可
    return nil
}
```

## 四、消息确认与重试

### XPENDING —— 检查未确认消息

```bash
# 概览：返回 [最小ID, 最大ID, 总条数, 各消费者pending数]
XPENDING mystream mygroup

# 详细列表：按 ID 范围查询
XPENDING mystream mygroup - + 10
# - = 最小ID，+ = 最大ID，10 = 最多返回10条
```

### XCLAIM —— 转移消息所有权

当消费者宕机后，需要把它 pending 的消息转给存活的消费者处理：

```bash
# 将空闲超过 30000ms 的消息转给 consumer-b
XCLAIM mystream mygroup consumer-b 30000 <msg-id-1> <msg-id-2>
```

```go
// Go 实现：定期扫描超时 pending，认领到自己
func (c *StreamConsumer) ClaimAbandoned(ctx context.Context, minIdle time.Duration) {
    pendings, err := c.rdb.XPendingExt(ctx, &redis.XPendingExtArgs{
        Stream:   c.stream,
        Group:    c.group,
        MinIdle:  minIdle,
        Start:    "-",
        End:      "+",
        Count:    100,
        Consumer: "", // 不限定消费者，扫描所有
    }).Result()
    if err != nil || len(pendings) == 0 {
        return
    }

    ids := make([]string, len(pendings))
    for i, p := range pendings {
        ids[i] = p.ID
    }

    // XCLAIM 认领
    claimed, err := c.rdb.XClaim(ctx, &redis.XClaimArgs{
        Stream:   c.stream,
        Group:    c.group,
        Consumer: c.consumer,
        MinIdle:  minIdle,
        Messages: ids,
    }).Result()
    if err != nil {
        return
    }

    // 对认领到的消息重新执行 handler
    for _, msg := range claimed {
        if err := c.handler(ctx, msg); err == nil {
            c.rdb.XAck(ctx, c.stream, c.group, msg.ID)
        }
    }
}
```

### XAUTOCLAIM —— Redis 6.2+ 自动认领

`XAUTOCLAIM` 把 XPENDING + XCLAIM 合并为一条原子命令：

```bash
XAUTOCLAIM mystream mygroup consumer-b 30000 0-0 COUNT 10
# 30000 = 最小空闲时间（ms）
# 0-0   = 起始游标（首次从头开始）
# COUNT = 每次最多返回 10 条

# 返回：next-start-id（下次传入作为游标）+ 消息列表 + 已删除的 ID
```

> [!question] XCLAIM 会不会被两个消费者同时认领同一条消息？
> 不会。XCLAIM 是单线程原子操作，Redis 保证同一消息在任意时刻只属于一个消费者。如果 consumer-A 已经 ACK 了某条消息，后续 XCLAIM 不会再返回它。

## 五、容量管理

Stream 是只追加的，消息不会自动删除。生产环境必须配置裁剪策略。

### MAXLEN —— 按数量裁剪

```bash
# 写入时裁剪（推荐，边写边裁）
XADD mystream MAXLEN 10000 * field value

# 精确裁剪 vs 近似裁剪
XADD mystream MAXLEN 10000 * field value      # 精确，O(N) 开销
XADD mystream MAXLEN ~ 10000 * field value    # 近似，~ 模式，O(1) 开销
```

### MINID —— 按 ID 裁剪（Redis 6.2+）

```bash
# 删除 ID 小于指定值的消息
XADD mystream MINID 1685000000000-0 * field value
XADD mystream MINID ~ 1685000000000-0 * field value  # 近似模式
```

### XDEL —— 删除单条消息

```bash
# 删除指定 ID 的消息
XDEL mystream 1685000000000-0

# 批量删除
XDEL mystream 1685000000000-0 1685000000000-1
```

> [!warning] XDEL 不会清除 PEL 引用
> 与 `MAXLEN`/`MINID` 一样，`XDEL` 删除的是 Stream 中的原始消息，但 Pending Entry List 中的引用仍然存在。被删除的消息 ID 在 `XPENDING` 中仍可见，`XCLAIM` 尝试读取时会返回 nil。

### XTRIM —— 手动裁剪

```bash
XTRIM mystream MAXLEN ~ 5000
XTRIM mystream MINID 1685000000000-0
```

> [!warning] 近似裁剪（`~`）的取舍
> `~` 模式不会精确保留 N 条，实际保留数量可能略多（因为底层按 Radix Tree 节点边界裁剪）。对于绝大多数场景，近似裁剪足够，而且**性能显著优于精确裁剪**。建议生产环境一律使用 `~`。

> [!question] 裁剪会影响 pending 中的消息吗？
> 会。`MAXLEN`/`MINID` 会删除 stream 中的原始消息，但 **pending 列表中的引用不会被清除**。这意味着 `XPENDING` 仍会显示这些 ID，但 `XCLAIM` 尝试读取时会返回 nil。设计裁剪策略时需确保消费者的处理速度跟得上写入速度。

## 六、Stream vs Pub/Sub vs Kafka 对比

| 维度 | Stream | Pub/Sub | Kafka |
|------|--------|---------|-------|
| **持久化** | 内存 + AOF | 不持久化 | 磁盘日志 |
| **消费者组** | 原生支持 | 不支持 | 原生支持 |
| **投递语义** | 至少一次（配合 ACK） | 最多一次（fire-and-forget） | 至少一次 / 精确一次 |
| **消息回溯** | 支持（按 ID 范围） | 不支持 | 支持（按 offset） |
| **吞吐量** | 中等（10w+ QPS） | 高（无持久化开销） | 极高（百万级 QPS） |
| **运维复杂度** | 低（复用 Redis） | 低 | 高（独立集群） |
| **适用规模** | 中小规模 | 实时通知 | 大规模事件流 |

> [!tip] 如何选型？
> - **已有 Redis、消息量不大**（< 10w/s）：Stream 是最佳选择，零额外运维成本
> - **实时推送、允许丢消息**：Pub/Sub 更简单直接
> - **海量事件流、需要精确一次语义**：Kafka 不可替代

> [!warning] Redis Cluster 模式下的 Stream
> 在 Redis Cluster 中，一个 Stream 被分配到**单个 slot**，所有写入和读取都路由到同一节点，**无法水平分片**。Consumer Group 的所有操作（XREADGROUP、XACK、XPENDING）也必须在同一节点完成。如果单个 Stream 成为热点，考虑将其拆分为多个 Stream（如 `orders:0`、`orders:1`……）并使用客户端负载均衡。

## 七、死信队列（Dead Letter Queue）

当某条消息被重试 N 次仍然失败时，继续重试没有意义。此时应将其移入**死信队列**，等待人工介入或补偿处理。

### 实现思路

Stream 本身没有内置 DLQ，但可以通过 XCLAIM 的 `delivery-count` 自行实现：

```go
const maxRetries = 5

func (c *StreamConsumer) ProcessPendingWithDLQ(ctx context.Context) {
    pendings, _ := c.rdb.XPendingExt(ctx, &redis.XPendingExtArgs{
        Stream:  c.stream,
        Group:   c.group,
        Start:   "-",
        End:     "+",
        Count:   100,
        MinIdle: 30 * time.Second,
    }).Result()

    for _, p := range pendings {
        if p.TimesDelivered >= maxRetries {
            // 超过重试次数 → 写入死信 Stream
            c.moveToDLQ(ctx, p.ID)
            continue
        }
        // 认领并重试
        claimed, _ := c.rdb.XClaim(ctx, &redis.XClaimArgs{
            Stream:   c.stream,
            Group:    c.group,
            Consumer: c.consumer,
            MinIdle:  30 * time.Second,
            Messages: []string{p.ID},
        }).Result()
        for _, msg := range claimed {
            if err := c.handler(ctx, msg); err == nil {
                c.rdb.XAck(ctx, c.stream, c.group, msg.ID)
            }
        }
    }
}

func (c *StreamConsumer) moveToDLQ(ctx context.Context, msgID string) {
    // 读取原始消息内容（XCLAIM 的返回可能为空，用 XRANGE 兜底）
    msgs, _ := c.rdb.XRange(ctx, c.stream, msgID, msgID).Result()
    if len(msgs) == 0 {
        // 消息可能已被裁剪删除，仅 ACK 清理 pending
        c.rdb.XAck(ctx, c.stream, c.group, msgID)
        return
    }
    // 拷贝一份，避免污染原始消息的 Values map
    dlqFields := make(map[string]interface{}, len(msgs[0].Values)+2)
    for k, v := range msgs[0].Values {
        dlqFields[k] = v
    }
    dlqFields["original_id"] = msgID
    dlqFields["original_stream"] = c.stream
    c.rdb.XAdd(ctx, &redis.XAddArgs{
        Stream: c.stream + ":dlq",
        Values: dlqFields,
    })
    // 从原 Stream 确认移除
    c.rdb.XAck(ctx, c.stream, c.group, msgID)
}
```

> [!tip] DLQ 最佳实践
> - 死信 Stream 命名建议 `<stream>:dlq`，保持关联性
> - 在 DLQ 消息中记录 `original_id`、`original_stream`、`error_reason`，方便排查
> - 监控 DLQ 长度，超过阈值立即告警——DLQ 堆积意味着业务逻辑有系统性问题

## 八、消息完整生命周期

```mermaid
flowchart TD
    P["Producer"] -->|"XADD"| S["Stream"]
    S -->|"XREADGROUP"| C1["Consumer A"]
    S -->|"XREADGROUP"| C2["Consumer B"]
    C1 -->|"XACK success"| ACK["Confirmed"]
    C1 -->|"handler fail"| PEL["Pending Entry List"]
    C2 -->|"XACK success"| ACK
    C2 -->|"handler fail"| PEL
    PEL -->|"retry count < max"| C1
    PEL -->|"retry count >= max"| DLQ["Dead Letter Queue"]
    ACK -->|"MAXLEN trim"| TRIM["Trimmed"]
    DLQ -->|"人工处理"| FIX["Fixed"]

    style S fill:#dfd,stroke:#090
    style PEL fill:#fdd,stroke:#f00
    style DLQ fill:#ffd,stroke:#f90
    style ACK fill:#dff,stroke:#099
    style TRIM fill:#eee,stroke:#999
```

## 关联笔记

- [[hhs/Redis/09-高级特性]] — Pub/Sub 基础、Lua 脚本原子操作
- [[hhs/Redis/03-基本命令速查]] — Redis 命令速查手册
- [[hhs/Redis/README]] — 知识索引总览