晚上十点，运维群里又炸了：订单支付成功，积分没加上，库存也没扣，客户投诉电话打到爆。我是老李，在电商后端摸爬滚打多年，这种“消息丢了”的锅背过不少。以前我们总用 Redis 的发布订阅做广播，可它像大喇叭，喊完就没了，听没听到全凭运气。现在订单量上来，需要一套轻量又可靠的事件流，Redis Streams 刚好补上这个缺口。刚好 Redis 8.10 给 XREAD、XREADGROUP 增加了 MAXCOUNT、MAXSIZE 限制，趁热打铁写一篇实战复盘。

## 01、痛点

电商系统的订单链路里，下单成功后通常要触发一串副作用：给用户加积分、扣减库存、发送通知。这些操作往往由不同服务负责，需要一个广播机制把“订单已创建”这个事件散出去。早期大家图省事，直接上 Redis 的 Pub/Sub：订单服务发布一条消息，积分、库存、通知三个订阅者各自处理。听着挺顺，实际跑起来全是坑。

第一个坑：消息不持久。Pub/Sub 就像街头大喇叭，喊的时候没人听，那就彻底错过。如果消费者服务刚好重启、发布瞬间网络抖动，消息直接蒸发，积分漏加、库存没扣，用户投诉接踵而至。第二个坑：没有 ACK 和重新投递。消费者处理到一半崩溃，消息已经发出去了，根本没法知道哪些没处理完，更别说重来一次。第三个坑：无法回溯历史。想查“昨天那条订单到底通知没通知”，Pub/Sub 连个日志都没有，查无实据。

订单量小的时候还能靠补数据兜底，量一上来，这些坑就是生产事故。有没有一个东西，既保留 Redis 的轻量和低延迟，又能提供类似消息队列的持久化、消费者组、确认和重新消费能力？有，这就是 Redis Streams。

## 02、是什么

Redis Streams 是 Redis 5.0 引入的一种数据结构，本质是一个只追加的日志文件。它和 Pub/Sub 最大的区别在于：消息会持久化保存在 Stream 里，不会因为消费者掉线而丢失。每条消息有一个全局递增的 ID，通常由 Redis 自动生成（形如 1699999999999-0）。你可以把 Stream 想象成一本流水账，每一笔记录都有编号，想查哪笔就翻哪页。

它最重要的特性是 Consumer Group（消费者组）。一个 Stream 可以被多个消费者组独立消费，互不影响。同一个组内，一条消息只会被组里的一个消费者处理，这是典型的竞争消费模型，适合横向扩展。每个组维护自己的消费进度，记录哪些消息已经确认（ACK）、哪些还处于 Pending（未确认）状态。如果某个消费者崩溃，它负责但未确认的消息会一直留在 Pending 列表里，其他消费者或者它自己重启后，可以根据 Pending 条目重新消费，实现故障恢复。

除了消费者组，Stream 还支持 XADD 写入、XREAD 非组读取、XREADGROUP 组读取、XACK 确认、XAUTOCLAIM 自动认领等命令。XREAD 和 XREADGROUP 既可以阻塞等待新消息，也可以指定起始 ID 回放历史。轻量、内嵌在 Redis 里，不需要额外部署组件，这是它相比独立消息中间件的最大优势。

到了 Redis 8.10，XREAD 和 XREADGROUP 新增加了 MAXCOUNT、MAXSIZE 两个参数。MAXCOUNT 限制单次响应中最多返回多少条消息，MAXSIZE 限制单次响应中消息体累计占用的字节数。这两个参数能有效防止某个消费者在追历史数据时被超大响应打爆内存或网络。以前只能靠 COUNT 限制条数，现在多了字节维度，对大消息场景更友好。

## 03、为什么

为什么现在要讲这个？因为很多团队把 Redis 当缓存用得很溜，但一提到消息队列就条件反射地引入 Kafka、RocketMQ。引入重量级组件意味着额外的部署、运维、监控成本，还得让团队从头学习。其实有一类需求，用 Redis Streams 就够：事件量中等、可以接受 Redis 自身持久化策略、希望低延迟、并且已经在用 Redis。比如订单事件、用户行为流、轻量任务队列。

Redis Streams 不是要取代 Kafka/RocketMQ，而是填补一块空白：轻量可靠的事件日志。如果业务没有海量吞吐、不需要跨机房容灾、不想为了一个简单的事件广播再维护一套集群，那么 Streams 是性价比很高的选择。反之，如果消息量巨大、需要严格顺序保证、要保留数年之久、或者需要复杂的路由和重试策略，那还是得上 Kafka 或 RocketMQ。这个取舍后面细说。

## 04、架构

回到订单场景。我们的目标是：商品下单后写入 order-stream，三个消费者组分别处理积分、库存和通知。架构不复杂：

- 订单服务：负责创建订单，并 XADD 一条订单消息到 order-stream。消息体包含 orderId、userId、amount、skuId 等字段。
- 积分服务：作为消费者组 points-group 的消费者，读取订单消息，给用户加积分。
- 库存服务：作为消费者组 stock-group 的消费者，读取订单消息，扣减库存。
- 通知服务：作为消费者组 notify-group 的消费者，读取订单消息，发送短信或推送。

由于是三个不同的消费者组，同一条订单消息会被三组各自独立消费，互不干扰。每个组内部可以起多个消费者实例，通过竞争消费提升处理能力。这正是我们需要的广播语义：一条消息广播给多个业务域，同时每个业务域内部可以水平扩展。

Spring Data Redis 对这套模型提供了原生的监听支持。你可以用 RedisStreamListener 或者注解驱动的方式绑定消费者组，容器会帮你管理阻塞读取、消息分发、ACK 提交等细节。同时它也保留了 Pub/Sub 的监听接口，如果你的场景真的只需要瞬时广播，仍然可以用老办法。

## 05、实战

下面用命令和代码把整个流程串一遍。假设我们已经在 Redis 里准备好了 Stream。

第一步，创建 Stream 和消费者组。通常首次使用前需要初始化，用 MKSTREAM 可以在 XGROUP CREATE 时自动创建空 Stream：

```
XGROUP CREATE order-stream points-group $ MKSTREAM
XGROUP CREATE order-stream stock-group $ MKSTREAM
XGROUP CREATE order-stream notify-group $ MKSTREAM
```

$ 表示从当前最新的消息之后开始消费，忽略历史消息。如果你想从最早的消息开始补数据，可以改成 0。

第二步，订单服务写入消息。假设下单后产生一条订单：

```
XADD order-stream * orderId 1001 userId 2001 amount 29900 skuId 3001
```

Redis 返回一个 ID，如 1700000000123-0。星号表示由 Redis 自动生成时间戳和序号。

第三步，三个消费者组分别读取消息。积分服务可以通过以下命令读取：

```
XREADGROUP GROUP points-group consumer-a COUNT 1 STREAMS order-stream >
```

大于号 > 表示只读取新分配给该组的消息，即没有被其他消费者认领过的。读取后积分服务处理业务，成功后执行 ACK：

```
XACK order-stream points-group 1700000000123-0
```

库存和通知服务类似，只是组名和业务逻辑不同。

现在加入 Redis 8.10 的 MAXCOUNT 和 MAXSIZE。假设订单消息体可能很大（比如包含商品详情快照），我们可以限制一次读取的数据量：

```
XREADGROUP GROUP points-group consumer-a COUNT 10 MAXCOUNT 10 MAXSIZE 102400 STREAMS order-stream >
```

COUNT 10 表示最多 10 条，MAXCOUNT 10 也是最多 10 条（两者语义有重叠但 MAXCOUNT 是硬上限），MAXSIZE 102400 表示消息体总字节不超过 100KB。如果历史消息特别多，这条命令会分页拉取，不会一次性把所有数据塞给消费者。对于 XREAD 也一样：

```
XREAD COUNT 100 MAXCOUNT 100 MAXSIZE 512000 STREAMS order-stream 0
```

这样可以安全地回放历史数据。

Spring Data Redis 里的代码大致如下（伪代码，省略部分细节）：

```
@Configuration
public class StreamConfig {
    @Bean
    public RedisStreamListener pointsListener() {
        return new PointsStreamListener();
    }
}

public class PointsStreamListener implements StreamListener<String, ObjectRecord<String, Order>> {
    @Override
    public void onMessage(ObjectRecord<String, Order> record) {
        Order order = record.getValue();
        // 处理积分
    }
}
```

然后使用 StreamMessageListenerContainer 或者 ReactiveStreamReceiver 绑定组名、消费者名和读取选项。关键是每个组要指定自己的 group-name 和 consumer-name。

第四步，模拟消费者崩溃和 Pending 恢复。假设积分服务的消费者 consumer-a 在读取消息后处理到一半进程崩溃，没有执行 ACK。这时候消息会留在该组的 Pending 列表中。我们可以用 XPENDING 查看未确认消息：

```
XPENDING order-stream points-group
```

会返回未确认消息总数、起始 ID、结束 ID，以及每个消费者的未确认数量。比如 consumer-a 下面有 1 条未确认。

接下来消费组内其他消费者或者重启后的 consumer-a 可以认领这些 Pending 消息。最简单的方式是用 XREADGROUP 指定起始 ID 为 0，并读取 Pending 列表：

```
XREADGROUP GROUP points-group consumer-b COUNT 1 STREAMS order-stream 0
```

0 表示从 Pending 消息的最早一条开始读取，而不是读新消息。这样 consumer-b 就能拿到那条未确认消息，重新处理。处理成功后执行 XACK。更自动化的做法是使用 XAUTOCLAIM，它可以把长时间未确认的消息自动转移给其他消费者：

```
XAUTOCLAIM order-stream points-group consumer-b 60000 0-0
```

这条命令会扫描所有超过 60 秒未确认的消息，并把它们分配给 consumer-b，返回转移的消息列表。然后 consumer-b 逐一处理并 ACK。这样就完成了 Pending Message Recovery。这套机制比 Pub/Sub 可靠太多，因为消息不会丢，处理进度可追踪。

## 06、洞见

说了这么多，回到最初的问题：什么场景可以用 Redis Streams，什么时候应该直接使用 Kafka/RocketMQ？

我的判断标准是“三个够不够”：数据量够不够大、可靠性要求够不够高、团队运维能力够不够强。如果数据量在每天几百万到几千万条、消息体不大、可以接受 Redis 持久化策略（如 RDB + AOF 混合）、并且团队已经熟悉 Redis，那么 Redis Streams 非常合适。它部署简单、延迟低、命令直观，和 Spring Data Redis 集成顺畅。

反之，如果消息量达到每天数十亿条、需要严格的分区顺序保证、需要跨机房复制和长期存储（以年计）、或者需要复杂的重试和死信策略，那就不要硬撑，直接上 Kafka 或 RocketMQ。Kafka 的分区模型可以做到单分区有序，多分区并行，吞吐量巨大；RocketMQ 对事务消息和延迟消息支持更友好，国内生态完善。这些能力 Redis Streams 不是没有，但要么性能有差距，要么实现起来复杂。

另一个容易忽略的点：Redis Streams 的消费者组模型虽然类似 Kafka 的消费组，但它没有 Kafka 那种基于 offset 的分区概念，其 ID 是全局的，同一个组内消息分配是基于“消息条目”而非分区。所以如果需要根据某个 key（如 orderId）做分区有序，Streams 做不到，得自己模拟或换方案。大多数订单事件不需要严格有序，但支付流水可能就需要。

Redis 8.10 新加的 MAXCOUNT、MAXSIZE 让 Streams 的读取控制更精细，尤其适合处理消息体偏大或历史消息积压的场景。用这些参数可以避免消费者在追数据时因一次性拉取过多而超时或内存压力过大。

## 07、行动

如果你想在自己的项目里试试 Redis Streams，我建议按以下步骤走：

1. 升级到 Redis 8.10 或至少 5.0，确认 XREAD、XREADGROUP 支持 MAXCOUNT、MAXSIZE（老版本不支持这两个参数，需自行用 COUNT 加代码判断）。
2. 梳理业务事件，比如订单创建、支付成功、退款申请等，定义事件结构和字段。
3. 用 XGROUP CREATE 创建消费者组，采取 $ 从最新开始，避免一开始就大量处理历史。
4. 在 Spring Data Redis 中配置 StreamListener 容器，为每个业务域设置独立的 group-name，消费者名可以按实例随机生成。
5. 处理消息时务必在 finally 中执行 ACK，或者使用容器自动 ACK 模式。但如果自动 ACK，一旦处理失败就丢了，要根据业务选择。
6. 监控 Pending 数量，设置告警。可以定时运行 XPENDING 检查，如果某个组 Pending 积压超过阈值，说明有消费者故障或处理能力不足。
7. 对于历史消息回放或故障恢复，使用 XAUTOCLAIM 或 XREADGROUP 指定起始 ID 0，配合 MAXCOUNT/MAXSIZE 分批读取。
8. 压力测试，对比 Kafka/RocketMQ 的吞吐和延迟，决定是否满足你的业务指标。

不要一上来就重构所有消息链路，可以先挑一个非核心但能体现价值的场景试水，比如操作日志、通知消息，跑稳定后再扩大范围。

## 08、小结

Redis Streams 是 Redis 生态里一块被低估的宝石。它把消息队列的核心能力塞进了我们已经熟知的 Redis 中，不需要额外部署组件，就能实现持久化、消费者组、ACK 确认、重新消费。Pub/Sub 适合纯粹的实时广播，对可靠性要求不高的场景；Streams 则适合需要事件日志、故障恢复、多组独立消费的场景。Redis 8.10 的 MAXCOUNT、MAXSIZE 进一步提升了读取控制力。

本文通过订单下单后的积分、库存、通知三个消费者组的实战，演示了从建组、写入、读取、ACK 到崩溃恢复的完整链路。最后给出的测验问题：什么场景用 Redis Streams，什么时候直接上 Kafka/RocketMQ，相信你已经有了答案。核心是：轻量、中低吞吐、已有 Redis、想要快速上线，就选 Streams；高吞吐、强一致、长期存储、复杂路由，就选 Kafka/RocketMQ。别拿大炮打蚊子，也别用弹弓打飞机。

## 09、链接与概念说明

为了方便你继续深挖，这里梳理几个核心概念和命令：

- Pub/Sub：Redis 的发布订阅，即时广播，消息不持久，订阅者离线时消息丢失。
- Streams：Redis 5.0+ 的流数据结构，只追加日志，持久化消息，支持消费者组。
- Consumer Group：消费者组，同一个组内竞争消费，不同组独立消费同一条消息。
- Pending：未确认消息列表，用来追踪已读取但未 ACK 的消息，用于故障恢复。
- ACK：确认操作，告诉 Redis 该消息已被成功处理，可以从 Pending 中移除。
- XADD/XREAD/XREADGROUP/XACK/XAUTOCLAIM：核心命令，分别用于写入、读取（组读取）、确认、自动认领。
- MAXCOUNT/MAXSIZE：Redis 8.10 新增参数，限制 XREAD/XREADGROUP 单次响应的消息条数和字节总量。
- Spring Data Redis：提供 StreamListener 容器和 Pub/Sub 监听支持，简化与 Spring 应用集成。
- Kafka/RocketMQ：独立的分布式消息中间件，适合更大规模、更复杂的消息场景。

更详细的命令文档可以查阅 Redis 官方命令参考，Spring Data Redis 的 Stream 支持可以参考对应版本的官方文档。希望这篇文章能帮你少踩几个坑，让订单消息不再丢。

晚上十点，运维群里又炸了：订单支付成功，积分没加上，库存也没扣，客户投诉电话打到爆。我是老李，在电商后端摸爬滚打多年，这种“消息丢了”的锅背过不少。以前我们总用 Redis 的发布订阅做广播，可它像大喇叭，喊完就没了，听没听到全凭运气。现在订单量上来，需要一套轻量又可靠的事件流，Redis Streams 刚好补上这个缺口。刚好 Redis 8.10 给 XREAD、XREADGROUP 增加了 MAXCOUNT、MAXSIZE 限制，趁热打铁写一篇实战复盘。

《Redis 8.10 + Spring Boot 实战》第10招 Pub/Sub 与 Streams——Redis 不只是缓存，也可以传递事件

Redis Streams 实战：从订单广播到崩溃恢复，详解消费者组、Pending 与 Redis 8.10 新参数 MAXCOUNT/MAXSIZE 的取舍

架构师

数据库

后端

开发工具

Redis Streams实战：解决订单消息丢失难题，用轻量持久化流替代Pub/Sub，支持消费者组与故障恢复。Redis 8.10新增MAXCOUNT/MAXSIZE限制读取量，防大消息打爆内存。通过积分、库存、通知三组独立消费演示完整链路，并给出选型建议：中低吞吐选Streams，高吞吐复杂路由用Kafka/RocketMQ。

日志文件

代码解释

压力测试

消息队列

数据结构

中间件

流数据

路由

容器

容灾

短信

Kafka

Redis

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Redis Streams实战：解决订单消息丢失难题，用轻量持久化流替代Pub/Sub，支持消费者组与故障恢复。Redis 8.10新增MAXCOUNT/MAXSIZE限制读取量，防大消息打爆内存。通过积分、库存、通知三组独立消费演示完整链路，并给出选型建议：中低吞吐选Streams，高吞吐复杂路由用Kafka/Roc...

《Redis 8.10 + Spring Boot 实战》第10招 Pub/Sub 与 Streams——Redis 不只是缓存，也可以传递事件-腾讯云开发者社区-腾讯云

《Redis 8.10 + Spring Boot 实战》第10招 Pub/Sub 与 Streams——Redis 不只是缓存，也可以传递事件

《Redis 8.10 + Spring Boot 实战》第10招 Pub/Sub 与 Streams——Redis 不只是缓存，也可以传递事件

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐