爬一手好线杆消息队列这个东西，只要业务量一上来，你迟早绕不开。我曾经在好几个项目里被“系统间调用超时”“数据库扛不住峰值压力”“凌晨三点被告警电话叫醒”这些问题按在地上摩擦，后来把消息队列真正用明白了，很多毛病都是治本而不是治标。如果你正在为接口响应变慢、模块之间耦合太深、或者一到大促就担心服务被打挂而发愁，这篇内容会很对胃口。这篇文章从为什么需要消息队列讲起，结合目前业务系统里非常主流的 Redis Stream 方案，把高性能消息队列的选型思路、Spring Boot 实操细节、重复消费与延迟消息这些容易踩坑的点，以及面试里常见的高频问题都串一遍。不管你是刚接触 MQ 的初级开发，还是想优化现有系统的老手，按这篇文章的思路走一遍，能少走很多弯路。
1. 先想清楚：你的系统为什么需要消息队列
很多人一上来就谈 Kafka、RocketMQ 怎么选，我认为这是本末倒置。先搞清楚“为什么需要”比“用什么实现”重要得多。消息队列本质上解决的是一个非常朴素的问题：当生产者和消费者的速度不一致时，中间需要一层缓冲。
拿电商下单来举例。用户点击“提交订单”之后，后端要做的事情很多：扣减库存、生成订单、修优惠券、发短信、推送物流信息。如果你把这些操作全部串在用户的请求线程里同步执行，每多一个环节，接口响应时间就多几百毫秒。更麻烦的是，如果某个下游服务恰好宕机或者网络抖动，你用户的请求会直接超时失败。这种体验，用户只会给你一次机会。
引入消息队列后，主流程可以做减法：订单状态落库之后立刻把“下单成功”事件丢进队列，然后直接返回。短信通知、积分变动、物流信息这些非核心动作全交给异步消费者慢慢处理。核心接口的 RT 从 1500ms 降到 300ms 以内，消费者那一侧哪怕偶发故障，也不会直接影响下单主链路。
再讲一个更隐蔽的场景：峰值流量削峰。比如秒杀活动，瞬时 QPS 可能冲到一万，但你的数据库能承受的稳定 QPS 就只有两千。这时候如果让所有流量直接穿透到数据库，数据库连接池瞬间被打满，大量线程阻塞等待，最后整个服务雪崩。消息队列就是那道泄洪闸：一万个请求进来，先在后端验签、限流，真正有效流量塞进队列，然后消费者侧按数据库能承受的速率慢慢处理。这保证了系统在大流量冲击下不会瞬间瘫掉。
另外还有系统解耦。你想想看，一个订单服务下游挂了五个业务方：库存、积分、推荐、搜索、风控。如果订单服务直接用 HTTP 接口去调它们，你每新增一个下游业务方，都要改订单服务的代码再重新发布。改用消息队列之后，订单服务只负责产出“订单创建完成”这个事实，下游谁关心这个事件，谁自己去订阅。后面的业务方接不接入、什么时候接入，订单服务完全不用关心。这也是 DDD 里“领域事件”思想的落地基础。
所以你在动手写代码之前，先梳理三个问题：我的链路里有没有哪些环节是不需要用户立刻等到结果的？我有没有削峰需求？我的服务之间是不是存在很强的偶合？如果三个问题有两个回答“是”，那你的系统确实需要认真引入消息队列了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 为什么我没选 Kafka，而是基于 Redis Stream 自己搭高性能 MQ
有些场景确实非 Kafka 不可，但现实业务里大量团队的流量规模根本连 Kafka 的零头都用不满。我之前对比过几套主流方案，最终在一款高并发中台项目里选择了基于 Redis Stream 搭建消息队列。理由在于它对部署成本和运维复杂度都要友好得多，而且用好了性能完全不差。
先看看几个候选方案的问题。Kafka 很强大，但它是个相对重量级的分布式系统，需要独立集群。如果你所在团队没有专人维护消息中间件，光 ZooKeeper、broker、partition 副本这些概念就够你折腾一阵子，更不用说 broker 宕机之后 rebalance 引发的消费停顿。RabbitMQ 的 AMQP 协议成熟，但谈到高吞吐，相比之下数据持久化与追尾读性能不如 Kafka 风格的分区日志模型。RocketMQ 功能丰富，但在中小团队里它和 Kafka 面临类似的部署门槛。
Redis Stream 是 Redis 5.0 引入的数据类型，它本质上是一个支持消费者组（Consumer Group）的持久化日志结构。我用一段大白话总结它的核心设计：生产者往 Stream 里追加消息，每条消息都对应一个全局唯一的 ID。消费者组内部维护一个游标，组里的成员协同消费这些消息，每条消息只被一个成员处理。它还有消息确认机制（ACK），消费完成后需要显式确认，否则这条消息会滞留在未确认列表中，等待后续处理。
相比 Kafka，Redis Stream 的部署成本几乎等于零——你的业务系统大概率已经用了 Redis，Redis 主从架构本身就在那里，Stream 只是新增的一种数据结构，不需要额外引入一大堆组件。它天然适配了“事件总线+轻量级消息中心”的定位。我至今记得第一次在测试环境把单消费者跑到了接近两万 QPS 时的惊讶。当然这个数字受机器配置、消息体大小、是否开启持久化影响，但对绝大多数中小团队的业务场景来说，这个量级完全够用了。
选择 Redis Stream 还有一个非常实际的考量：排查问题链路极短。用 Kafka 的时候，消息丢没丢你得去看 broker 日志，消费落后了你得去看 consumer group 的 lag，一条消息从生产到消费的完整轨迹要跨多个系统追踪。用 Redis Stream 就简单多了，直接进 Redis 里用一条命令就能查到 Stream 的长度、pending 消息数、每个消费者的处理情况，整个消息链路尽收眼底。这是在真实项目中非常有价值的一点，毕竟出问题时，谁能最快定位问题，谁就赢了。
3. Redis Stream 核心机制拆解：从 XADD 到消费者组的完整链路
Redis Stream 的核心命令并不复杂，但它背后的机制和参数细节却决定了你在实际业务中能不能用好它。我建议不要跳过这一段直接看 Spring Boot 集成，因为后续遇到的很多问题，根子都出在对底层机制理解不够透。
先看消息生产。向 Stream 追加消息用的是 XADD 命令，它的作用像往一个日志文件尾部追加记录。每条消息都有唯一的消息 ID，默认是“毫秒时间戳-序号”的组合。这个 ID 结构可以保证消息在同一个 Stream 里严格按时间排序，也方便按时间范围查询。实际项目中，我通常会让 Redis 自动生成消息 ID，而不是自己指定，因为自动生成能保证全局递增，同时避免分布式环境下的并发冲突。
消费者组是 Stream 的重点。创建消费者组需要使用 XGROUP CREATE 命令，这里必须要重点理解一个参数：从什么位置开始消费。XGROUP CREATE mystream mygroup 0 表示从 Stream 里的第一条消息开始消费；如果填的是 $ 符号，表示只消费该组创建之后新到达的消息。这两者的差别在真实场景里非常关键。如果你的消费者组是在消息已经堆积后才创建的，你想要补偿处理历史消息，就得用 0；如果你只关注新消息，用 $ 就够了。我曾经在这个参数上吃过亏：创建组时用了 0，结果消费者一经启动就把积压了半天的测试数据全部重新处理了一遍，下游系统被重复写入了一堆数据。排查了很久才找到根因，就只是因为一个符号的差异。
消费者读取消息有两种方式。第一种是 XREAD，属于独立消费，组里面的每个消费者各自读各自的消息，互不干扰。第二种是 XREADGROUP，属于组内协作消费，同一条消息只会被组内其中一个消费者处理。组内协作模式才是我们业务系统里真正需要的模式，它天然支持消息的并行消费和负载均衡。
我可以给你展示这一个完整的最小可运行流程，你用命令行就能复现：
bash复制# 1. 创建一个 Stream，名字叫 order_events
XADD order_events * event_type "order_created" order_id "10086"
# 2. 创建消费者组，从新的消息开始消费
XGROUP CREATE order_events order_group $
# 3. 消费者A从组里读取消息，每次最多读2条，阻塞等待5秒
XREADGROUP GROUP order_group consumer_A COUNT 2 BLOCK 5000 STREAMS order_events >
# 4. 处理完成后，用 XPENDING 查看待确认消息，然后用 XACK 确认消息
XPENDING order_events order_group
XACK order_events order_group 1699999999999-0
这里需要特别向你强调一下 XREADGROUP 命令末尾那个特殊符号 >。> 表示只返回从未投递给其他消费者的新消息。如果这里换成具体的消息 ID，返回的则是历史消息——通常是消费者崩溃后用来恢复现场的场景。理解这个符号的差异，对你后面排查重复消费问题有直接帮助。
消息确认机制更是 Stream 的灵魂。当消费者通过 XREADGROUP 读到消息后，这条消息会同时进入该消费者的 PEL（Pending Entries List，待确认列表）。如果消费者处理成功，需要调用 XACK 将消息从 PEL 中移除。如果消费者处理完没来得及确认就宕机了，这条消息会一直放在 PEL 里。主流的 Stream 客户端库（比如 Spring Data Redis）默认都是自动确认模式，处理完成立刻 ACK。但如果你用的是手动 ACK 模式，必须保证消费逻辑完全成功后再确认，否则就会出现“消息处理成功但服务重启又重新处理一遍”的重复消费问题。
下面这个状态流转过程是我自己画过很多遍的，你把它理解透，Redis Stream 的消费端就算掌握了大半：
- 生产者 XADD 追加消息，消息进入 Stream 头部尾部。
- 消费者通过 XREADGROUP 读取未投递消息，Redis 为消息分配归属消费者并放入其 PEL。
- 消费者处理消息，调用 XACK 确认，消息从 PEL 移除。
- 如果消费者超时未 ACK，该消息停留在 PEL；可通过 XPENDING 查询，由其他消费者用 XCLAIM 认领该消息并继续处理。
- 如果 Stream 设置了 MAXLEN 上限，旧消息会被自动淘汰。
我建议你动手实践的时候，特意用 XPENDING 观察一下消费前后 PEL 的变化。看到 PEL 里的条目从有到无的过程，你就真正理解了 Redis Stream 可靠投递机制的内核。
4. Spring Boot 实战：用 Redis Stream 拉取和处理队列消息的标准姿势
理论讲完，我们直接进代码。在 Spring Boot 项目中集成 Redis Stream 并不复杂，但有个地方需要特别注意：很多人分不清 Spring Data Redis 里的 StreamListener 和 StreamMessageListenerContainer 之间的关系，实际写出来容易乱。我给你梳理一个最顺手、也经过线上验证的标准落地方式。
首先引入依赖。如果你用的是 Spring Boot 2.7 以上版本，直接在 pom.xml 里加上：
xml复制<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
Spring Data Redis 会自动把 RedisTemplate、StringRedisTemplate 等注入容器。接下去的核心是定义一个监听容器。我用一个在实际项目中稳定运行的简化代码给你看：
java复制@Configuration
public class RedisStreamConfig {
@Bean
public StreamMessageListenerContainer<String, MapRecord<String, String, String>> streamMessageListenerContainer(
RedisConnectionFactory connectionFactory) {
// 设置轮询超时、批量拉取大小等参数
StreamMessageListenerContainer.StreamMessageListenerContainerOptions<String, MapRecord<String, String, String>> options =
StreamMessageListenerContainerOptions
.builder()
.pollTimeout(Duration.ofSeconds(3))
.batchSize(10)
.executor(Executors.newFixedThreadPool(8))
.build();
return StreamMessageListenerContainer.create(connectionFactory, options);
}
}
这段代码看着简单，但里面隐藏着性能调优的学问。pollTimeout 是指没有消息时，消费者线程阻塞等待的最长时间。如果设置太短，会导致 Redis 连接被频繁的轮询请求浪费掉；设置太长，消息到达后消费者的感知延迟会变高。我通常设置 3 秒左右，两者权衡最合适。batchSize 是每次批量拉取的消息条数，适当提高批量大小可以显著降低网络 RTT 对吞吐量的影响。executor 是处理消息的线程池大小，这里需要结合你的业务耗时来定。如果是纯内存计算，8 个线程已经可以跑出不错的吞吐量；如果消费者内部还要查数据库或者调远程接口，这个线程数要根据下游能承受的并发度来调整，不是越大越好。
然后定义消费者处理器。Spring 提供了 StreamListener 接口，我们实现它的 onMessage 方法即可：
java复制@Component
public class OrderEventHandler implements StreamListener<String, MapRecord<String, String, String>> {
private static final Logger log = LoggerFactory.getLogger(OrderEventHandler.class);
@Override
public void onMessage(MapRecord<String, String, String> message) {
Map<String, String> body = message.getValue();
String orderId = body.get("orderId");
String eventType = body.get("eventType");
log.info("收到订单事件, orderId={}, eventType={}, streamId={}", orderId, eventType, message.getId());
// 这里写实际的业务逻辑，比如更新积分、发短信等
handleBusiness(orderId);
// 注意：在 Spring Data Redis 默认配置下，消费成功后容器会自动 ACK
// 如果你改成了手动 ACK 模式，需要在这里调用 ack
}
private void handleBusiness(String orderId) {
// 模拟业务处理耗时
try {
Thread.sleep(50);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
}
}
这里我特意写了“默认配置下自动 ACK”的注释。很多人踩过这个坑：Spring Data Redis 的 StreamMessageListenerContainer 在默认情况下是消费成功后立即向 Redis 发送 XACK，所以消息不会留在待确认列表里。看起来这很智能，但它也带来一个问题——如果 onMessage 方法内部抛出了异常，而你没有覆盖 errorHandler，异常会导致消息被 ACK，业务其实没有处理成功，消息却丢了。这个在面试里也经常被问到，正确做法有两种。
一种是在 onMessage 内部做 try-catch，捕获所有异常并补偿处理（比如写入死信队列）。另一种是设置容器的 errorHandler，并对异常情况不进行 ACK，让消息留在 PEL 中等待后续处理。我个人的经验是：线上环境强烈建议不要完全依赖默认的自动 ACK，因为网络抖动、下游临时不可用导致的业务异常，并不代表这条消息本身有问题，消息应该被保留、重试或者进入死信队列，而不是被静默确认丢弃。
最后把容器和监听器组装起来，注册到指定 Stream 和消费组上：
java复制@Component
public class OrderEventRegistrar implements ApplicationRunner {
@Resource
private StreamMessageListenerContainer<String, MapRecord<String, String, String>> container;
@Resource
private OrderEventHandler orderEventHandler;
@Resource
private StringRedisTemplate stringRedisTemplate;
@Override
public void run(ApplicationArguments args) {
String streamKey = "order_events";
String groupName = "order_group";
// 如果 Stream 或消费组还不存在，先创建（生产级代码需要注意判断异常）
try {
stringRedisTemplate.opsForStream().createGroup(streamKey, groupName);
} catch (Exception e) {
log.warn("消费组可能已存在, 忽略创建: {}", e.getMessage());
}
container.receive(
Consumer.from(groupName, "consumer-" + UUID.randomUUID()),
StreamOffset.create(streamKey, ReadOffset.lastConsumed()),
orderEventHandler);
container.start();
}
}
这里有三个设计细节向你说明。
第一个细节，容器启动时创建消费组。这段代码用 try-catch 把 createGroup 包起来，是因为 Stream 在首次 XADD 之前其实并不存在，如果你直接对不存在的 key 创建消费组，Redis 会返回错误。用 try-catch 的方式即使组已存在也能安全幂等地启动。
第二个细节，ReadOffset.lastConsumed() 代表从组内最后消费的位置继续。这个语义和命令行里的 > 一致，保证只读取新消息。如果你要用历史消息补偿处理，可以换成 ReadOffset.from("0")。业务系统大多数场景下用 lastConsumed 就够了。
第三个细节是 consumer 名称。我每次启动时生成一个 UUID，是为了让这个消费者实例在消费者组里是唯一标识。如果你在集群部署了多个服务实例，每个实例的 consumer 名称必须不同，否则 Redis 会认为它们是同一个消费者，消息分配就可能倾斜到同一个实际实例上。
我还用一个真实的压测场景告诉你这种架构能跑到什么量级。在一台 4 核 8G 的机器上，同时部署 Redis 和 Spring Boot 应用，消费者线程池 16 个线程，消息体大约 500 字节，不开 AOF，纯内存模式压测，稳定吞吐量在 1.8 万条/秒左右，P99 延迟在 30ms 以内。如果分开部署 Redis 到单独的物理机，吞吐量还能再翻一倍。这个数据足以覆盖绝大多数中小互联网业务的实时事件处理场景。
5. 绕不开的两个工程痛点：重复消费与消息堆积的排查实录
消息队列的三大经典问题是：重复消费、消息丢失、消息堆积。这一节我对着 Redis Stream 的特点，逐一讲清楚它们的成因和我在项目里摸索出来的对策。
5.1 重复消费的来源与幂等设计
重复消费问题在这类场景太常见了。我复盘过反复踩的坑，根本原因就两条：一是客户端网络超时重试，二是消费者处理成功但 ACK 丢失。你想想看，消费者从 Redis 里 XREADGROUP 读到消息，正在处理的过程中，客户端和 Redis 之间的 TCP 连接断了。Redis 没有收到 XACK，这条消息一直留在 PEL 里。消费者重连之后，如果用 XAUTOCLAIM 或者其他机制重新拉取，很可能把这同一个消息再读出来，业务逻辑就又执行了一遍。
以 Redis Stream 的场景来说，还有一个背景因素：Redis 的 Stream 本身不提供事务保证，它只保证至少一次投递。至少一次，意味着同一条消息在特殊情况下可能被投递多次。所以如果你做的是转账、扣库存这类对金额敏感的操作，重复消费是绝对不能接受的。
解决重复消费的唯一道路是幂等。换句话说，你的消费者在遇到同一事件第二次处理时，它能识别出来并直接跳过，或者覆盖写入。实现幂等的常用方案有三种。
第一种是基于唯一业务键做去重。在订单场景中，订单 ID 天然是唯一键。在业务表里加一个消息消费记录表，记录 messageId 和业务唯一键，消费前先查询是否已经处理过，处理成功后写入去重表。如果同一消息再次到达，查出记录直接返回成功。这是一张“慢速去重表”的思路，适合低频高价值业务。
第二种是在数据库层做幂等控制，也叫乐观锁或条件更新。比如更新库存时用 SQL 条件 update stock set count = count - ? where product_id = ? and count >= ?，通过受影响行数判断是否已经扣过。如果重复扣减，第二次执行会因为库存不足而失败。这种方式性能好，但业务逻辑往往需要调整。
第三种是把消息的消费结果设计成可重入的。举个例子，你更新用户积分时不是做“加 100 分”这种增量操作，而是做“把用户积分设为某个值”这种全量覆盖。这样即使同一事件重复执行两次，最终结果还是相同的。Redis 里经典的 SETNX、INCR 等命令也经常被用来做短时间内的防重。
我给你的中肯建议是：不要试图从消息队列层面彻底消灭重复，那是不可靠的；你要假设重复一定会发生，然后在消费者层面做幂等。 我见过太多团队花大力气想保证队列“恰好一次”，最后耗时耗力不说，往往还是留下边角漏洞，不如把精力花在设计好幂等方案上。
5.2 消息积压与消费者的扩容之道
消息积压不像重复消费那样让人头皮发麻，但它对业务影响其实更大。用户下单之后，如果积分通知消息堆积了几十万条，商品发出去很久了，用户的会员积分还没有到账，客服那边就会收到大量咨询。
消息积压出现时，我建议按照下面的顺序排查。第一步确认 Redis 里 Stream 的长度是否在持续增长。如果持续增长，说明消费速度小于生产速度。第二步检查消费者的日志耗时。最简单有效的方式是临时增加消费者的并行度。Redis Stream 的消费者组模型非常支持水平扩容，你只需要在服务里加大线程池的线程数，或者多部署几个应用实例，组内的消息消费就会自动负载均衡。这里有个微妙点：Redis 消费者组内部的分发粒度是消息级别，不是分区级别，所以扩容的实时性比 Kafka 好很多，新实例起来后立刻就能参与消费。
如果下游数据库写性能成了瓶颈，加消费者线程数反而会让下游更慢。消费端的扩容一定要观察下游数据库连接池、慢查询、CPU 等指标，找到真正的瓶颈所在。这里的扩展方式是在消费者里引入一个本地队列或者二级缓冲，先把消息快速读出来攒在内存里，再用一个可控速率的下沉线程批量写入数据库。批量写的好处是单位时间内的数据库请求数大幅下降，吞吐量却可以提升好几倍。
还有一个思路常被忽略：对优先级不同的消息，应该把它们放到不同的 Stream 中，而不是混在一个 Stream 里。比如普通业务消息和秒杀活动消息混在一起时，秒杀消息的量突然暴增，普通业务消息会被挤到后面，消费者需要处理完前面的消息才轮到它们。拆分为不同的 Stream，各组消费者独立消费互不影响，能有效避免消息之间的互相干扰。
5.3 消息丢失的三个环节
消息丢失问题分散在生产、存储和消费三个环节中，需要逐个检查。生产端最容易丢消息的场景是：你用 Redis 的 XADD 发消息时，如果 Redis 刚好发生主从切换，还没有同步到从节点的数据就丢了。要降低这个风险，可以开启 Redis 的 AOF 持久化，并将 appendfsync 配置成 everysec。记住，它很安全但并同时会略微降低性能，视数据可靠性要求而定。
消费端丢消息的可能我之前说过：Spring Data Redis 使用默认的自动 ACK 很顺手，但如果业务逻辑失败时异常没被正确处理，就相当于消息成功消费了。这里我建议至少把消费者逻辑包在 try-catch 里，捕获到异常后记录日志。至于是否要给异常场景做重试，取决于你的业务是否允许丢弃——大部分业务不应该允许。
存储端其实还有一个隐藏很深的问题：Redis Stream 默认是无上限的。如果消费者长时间故障，Stream 里的消息会无限增长，最终把 Redis 内存打爆。Redis 虽然提供了 XTRIM 和 MAXLEN 修剪，但对业务关键消息来说，绝对不能依赖这个机制来兜底。我在线上一般会为 Stream 配置 MAXLEN 和一个监控报警，当 Stream 长度超过某个阈值时，立刻告警。因为 Stream 积压到 MAXLEN 的记录会开始丢弃最早未消费的消息，那样的丢数据往往是非常危险的。
5.4 延迟消息的几种实现
延迟消息虽然不在 Stream 的官方功能里，但在实际业务里极其常用，比如：外卖订单超时未支付自动关闭、直播预约开始前提醒、工单 24 小时未处理自动升级等。面试里提到“MQ 延迟消息队列”，本质上是想问你怎么在消息中间件之上实现定时调度的能力。
我在项目里验证过三种可行的延迟方案。第一种是基于 Redis Key 过期事件的方案。把延迟消息的 value 写到 Redis 中，设置一个合适的 TTL 到期时间，同时开启 Keyspace Notifications 监听过期事件。到时间后 Redis 会推送一个过期通知，消费者收到事件后再把业务消息重新投递到真正的消息队列里。这个方案最大的问题是 Redis 过期事件的投递是不可靠的，如果开启过期监听时有大量 key 同时过期，通知事件可能会被削峰甚至丢失，而且订阅者只能收到 key 名称，收不到值，所以还得二次查库。我自己的实践结论是：它对可靠性要求不高的场景可用，但真正生产环境我不推荐。
第二种是 RabbitMQ 死信队列 + TTL。这是 RabbitMQ 生态非常经典的延迟方案。消息发送到交换器时指定 TTL，超时的消息自动转入死信交换器，再由消费者订阅死信队列完成延迟处理。
第三种更适合自己控制底层的场景——基于 Redis ZSet 实现延迟队列。把消息体序列化成 JSON 存入 ZSet，score 设为期望延迟执行的时间戳。消费者侧启动一个定时任务，周期性用 ZRANGEBYSCORE 拉取 score 小于等于当前时间的消息，然后投递到真实的 Stream 队列中去。这样做的优势是你可以自己控制时间精度和拉取频率，完全不依赖 Redis 的过期通知和额外的中间件，实现起来非常可控。下面这一段就是我在项目中实际用过的核心代码骨架：
java复制@Component
public class DelayMessagePoller {
private static final String DELAY_QUEUE_KEY = "delay:order_close";
private static final String READY_STREAM_KEY = "order_events";
@Resource
private StringRedisTemplate stringRedisTemplate;
@Scheduled(fixedDelay = 1000)
public void pollExpiredMessages() {
long now = System.currentTimeMillis();
// 每次取100条到期的延迟消息
Set<String> messages = stringRedisTemplate.opsForZSet()
.rangeByScore(DELAY_QUEUE_KEY, 0, now, 0, 100);
if (messages == null || messages.isEmpty()) {
return;
}
for (String messageJson : messages) {
try {
// 转投到真正的业务流
stringRedisTemplate.opsForStream()
.add(READY_STREAM_KEY, Collections.singletonMap("payload", messageJson));
// 成功后从延迟集合移除
stringRedisTemplate.opsForZSet().remove(DELAY_QUEUE_KEY, messageJson);
} catch (Exception e) {
log.error("延迟消息投递失败: {}", messageJson, e);
}
}
}
}
这里有个很容易忽略的细节：转投和删除这两个动作不是原子的。如果转投成功但删除失败，下一轮你可能会重复投递同一条消息。所以消费端依然需要幂等。另一个细节是 rangeByScore 的 count 参数，建议设置一个合理的拉取上限，避免一次性处理上百万条积压的延迟消息导致 Redis 阻塞。用 1000 或者根据你业务的消息大小动态调整就可以。
你如果想让这个延迟队列更健壮，还可以加一个独立的 Process 线程定期执行 XCLAIM 对超时未 ACK 的消息进行补偿，确保极端情况下消息不会永久停留在延迟集合的某个角落。说到底，延迟队列是工程问题而不是单纯的数据结构问题，必须把这些边界情况想清楚。
6. 消息队列面试高频问题，顺便教你两句“答到点子上”的口径
每次面试我都会问候选人消息队列相关的问题，因为这个问题最容易分辨一个人是真做过还是只背过八股文。下面我把面试中出现频率最高的几个问题和你捋一遍，顺便帮你整理回答口径。
6.1 消息队列如何保证消息不丢失？
这个问题看着很简单，但其实涵盖了生产端、Broker 存储端、消费端三个环节，每一段都要有对应的机制。如果你是面试官，你希望听到的是候选人能分环节说清楚，而不是笼统一句“开启持久化”。
我给你的回答思路是这样：生产端要确认消息已成功写入 Broker，如果写入失败或超时，需要重试；Redis Stream 场景下，生产端调用 XADD 后要判断返回值拿到消息 ID，拿不到就重试。Broker 存储端要开启持久化，Redis 要配置 AOF 且 appendfsync 至少是 everysec，同时生产环境要部署主从模式并设置合理的复制因子，确保主节点宕机后从节点能立刻顶上。消费端需要注意手动 ACK 的语义，处理成功再 ACK，如果在 Spring Boot 默认自动 ACK 的模式下，业务代码里要有异常兜底，保证消息不会因为逻辑异常被误确认。
6.2 如何保证消息只被消费一次？
这个问题的标准回答是：消息队列本身大多只能保证至少一次（at least once）投递，要保证最终的效果恰好一次（exactly once），必须在消费端做幂等控制。具体手段有三种我刚才讲过，关键是要让面试官看到你理解“至少一次投递”与“幂等消费”之间的配合关系，而不是期望队列层面帮你解决所有问题。
6.3 如何实现延迟消息？
如果你是面试官，候选人如果只知道 RabbitMQ 的死信队列，说明接触面有点窄。如果能顺着 Redis ZSet 延迟队列、RocketMQ 定时消息、Kafka 的层级时间轮等思路展开，并且能说出各自的可靠性差别，那我会比较认可。回答时最好能接一个业务例子，比如订单超时关闭，从下单时生成延迟消息，到消息到期投递到业务队列，再到消费者处理时校验订单状态，这样会显得很踏实。
6.4 消息积压了怎么处理？
这是运维类问题中最高频的。我的回答思路是：先看是下游处理慢还是上游生产快。如果是消费者问题，优先扩容消费者实例或增加线程池；如果是下游数据库写不过来了，要考虑批量写、异步刷盘、或者对下游做分库分表。如果消息已经积压得很厉害，Redis 里的 Stream 长度非常大，可以考虑临时把消息导出到另一个更大的消息集群处理，等积压消除后再回切。这个回答能体现你在真实系统里处理过的“危机感”。
6.5 Kafka 和 Redis Stream 怎么选？
这个问题的本质是考察候选人能不能根据业务场景选技术方案。Kafka 适合海量日志、极高的吞吐、需要消息回溯的场景，因为它的顺序读写磁盘模型决定了它的吞吐上限高于内存型方案。Redis Stream 适合中小规模业务系统，它部署简单、生态与 Redis 高度绑定、消息排查方便，性能和可靠性虽然不如 Kafka 那么极致，但绝大多数业务够用。
我用一句话总结选型标准：如果你的日消息量超过千万级、或者你需要做长时间的数据回放，优先上 Kafka；如果你的主要目标只是实现服务间异步解耦、削峰填谷，而你们团队又已经有 Redis 的运维经验和基础设施，用 Redis Stream 完全没问题。很多技术上看起来“不够高级”的方案，在实际业务里恰恰是性价比最高的方案。
7. 给实际项目的一些建议与细节避坑
最后再给你几个我这些年踩过坑之后沉淀下来的实操心得。这里面每一条都是真金白银换来的，不写进官方文档，但线上系统出问题时它们往往就是你救命的钥匙。
第一，Redis Stream 的消息 ID 和业务 ID 一定要分开。不要在业务字段里直接依赖 Redis 生成的消息 ID，那个 ID 只属于 Redis 内部，它不携带任何业务语义。你的业务表里如果要存消息关联 ID，建议自己生成一个业务唯一键（比如 UUID），并在消息正文里带上。这样才能在消费端做幂等、做追踪。
第二，消费者线程池的参数不要拍脑袋定。线程数不是越大越好，我见过有人把线程池设成 200，结果下游数据库连接池先被干穿，整个服务响应瞬间变慢。线程数应该结合下游系统的健康水位来压测确定，先从一个小的值比如 8 开始，用压测工具和监控工具逐步增加，观察延迟和吞吐的变化。如果你们对业务 RT 有硬性指标，还要考虑线程满时新进来消息的处理策略，设置合理的拒绝策略。
第三，消息体设计要短小精悍。不要把整个大对象塞进消息里，最好只放关键 ID 和必备字段，消费者真正需要详情时再通过服务调用获取。曾有一次我在压测中把整个商品对象 JSON 塞进消息体，单条消息撑到了几 KB，吞吐量直接降了一半。把消息体从几 KB 缩减到几百字节后，同样的配置吞吐量翻了将近一倍。
第四，做好 Stream 的监控与报警。Redis Stream 用起来很简单，但正因为简单，很多团队没有建设它的可观测性。强烈建议你把 Stream 长度、消费组 pending 数、消费者 lag 这几个指标接入现有监控体系。通过 Prometheus 的 Redis Exporter 就能很方便地拿到这些指标。设置了可靠告警，你才不会在消息堆积几个小时之后才被动发现。
第五，消费端一定要记录消息的“消费轨迹日制”。每处理完一条消息打一条日志，内容包括 stream ID、消息唯一键、处理结果、耗时，用结构化日志方式输出。这在你排查重复消费和故障恢复时价值巨大。我之前接手过一个项目，消息队列不丢消息，但每次系统重启就有人投诉说收到重复短信，就是因为消费端没有日志，排查时只能靠猜。后来加上日志发现是重启前一批消息已处理完但还没来得及 ACK，重启后重新消费触发了短信重复发送。
这套基于 Redis Stream 的高性能队列方案，给我的团队省下了大量中间件运维时间，也让我们把精力花在了真正的业务代码上。我看好这样的思路：能用现有基础设施解决的事情，就不要轻易引入一个新组件。这是我在很多项目里体会到的一个原则，也希望对你有参考价值。