如何在 Spring Cloud 中配置 Redis Stream 实现可靠消息投递？

在 Spring Cloud 中使用 Redis Stream 实现可靠消息投递，推荐启用消费者组（Consumer Group）并配置手动 ACK 确认机制。适用场景为中低吞吐量业务，风险边界在于 Redis 持久化配置不当可能导致消息丢失，且需防止 Pending 列表无限增长。

先说结论：Spring Cloud Stream 结合 Redis Stream 可实现可靠投递，但必须配置消费者组和手动确认，否则消息可能丢失或重复。

适合：中小规模异步任务、日志收集、事件驱动架构，不依赖重度事务场景。
先准备：确认 Redis 版本支持 Stream 结构（5.0+），开启 AOF 或 RDB 持久化。
验收：验证消费者宕机重启后能否从 Pending 状态恢复消息，确认无消息积压。

命令速用版

以下是 Maven 依赖和核心配置片段，直接用于项目构建和 application.yml 设置。

<!-- Maven 依赖 -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-stream-binder-redis</artifactId>
</dependency>

# application.yml 配置
spring:
  cloud:
    stream:
      bindings:
        input:
          destination: my-stream
          group: consumer-group-1
          consumer:
            max-attempts: 3
      redis:
        stream:
          bindings:
            input:
              consumer:
                ack-mode: manual
                pending-queries-per-poll: 10

为什么会这样

可靠投递的核心在于 Redis Stream 的消费者组机制和 PEL（Pending Entries List）列表。

Redis Stream 默认模式下，消息被读取即视为消费，若消费者宕机则消息丢失。启用消费者组后，消息进入 PEL 列表，只有客户端发送 ACK 命令后才会移除。Spring Cloud Stream 通过 binder 封装了这一过程，若配置为手动 ACK，业务逻辑执行成功后才提交确认，确保至少投递一次。若未配置持久化，Redis 重启会导致内存中的 Stream 数据丢失，因此持久化是可靠性的物理基础。

分步处理

按以下步骤配置 Spring Cloud 与 Redis Stream，确保每一步都有检查点。

步骤 1：引入依赖

在 pom.xml 或 build.gradle 中加入 spring-cloud-stream-binder-redis 依赖。检查点：确认版本与 Spring Cloud 版本兼容，避免缺少传递依赖。

步骤 2：配置消费者组

在 application.yml 中设置 spring.cloud.stream.bindings.input.group。检查点：group 名称必须固定，若变更会导致消息被重新消费。

步骤 3：开启手动 ACK

如何在 Spring Cloud 中配置 Redis Stream 实现可靠消息投递？

设置 ack-mode 为 manual。在代码中使用 Acknowledgment 对象手动确认。检查点：确保 catch 块中不提交 ACK，触发重试或进入死信队列。

步骤 4：配置重试与死信

设置 max-attempts 大于 1，配置 dead-letter-queue destination。检查点：验证失败消息是否路由到 DLQ 主题，避免阻塞主队列。

步骤 5：Redis 持久化

在 redis.conf 中开启 appendonly yes。检查点：重启 Redis 服务后，使用 XLEN 命令确认 Stream 长度未清零。

怎么验证是否生效

通过 Redis 命令行和日志观察消息状态，确认可靠性机制 working。

检查 pending 消息：使用命令 XPEING my-stream consumer-group-1 查看未确认消息列表。若有消息停留，说明 ACK 未提交。

检查消费进度：使用命令 XINFO GROUPS my-stream 查看 consumers 和 pending 数量。正常状态下 pending 应随消费完成归零。

模拟故障测试：停止消费者服务，发送新消息，重启服务。观察日志是否重新打印旧消息，确认 PEL 恢复机制生效。

检查持久化：执行 BGSAVE 后重启 Redis，验证 Stream 数据是否存在。

常见坑

配置 Redis Stream 可靠投递时，以下场景容易导致生产事故，需谨慎处理。

ACK 提交时机错误：在业务逻辑开始前就提交 ACK，若后续处理失败，消息永久丢失。必须在业务成功完成后提交。

消费者组名称动态变化：若 group 名称包含随机 UUID，每次重启都会创建新组，导致消息重复消费。必须使用固定字符串。

PEL 列表无限增长：若消费者长期宕机且未配置死信或最大重试，PEL 列表占用内存。需配置 max-attempts 和 DLQ。

Redis 内存淘汰策略：若配置 volatile-lru 且未设置过期时间，Stream 数据可能被意外淘汰。建议专用 Redis 实例或配置 noeviction。

常见问题

Spring Cloud Stream Redis Binder 支持自动创建消费者组吗？

支持，但需配置 spring.cloud.stream.redis.stream.bindings.input.consumer.consumer-group 属性。若未指定，部分版本可能默认不创建组，导致退化为普通消费模式。

消息重复消费如何处理？

可靠投递保证至少一次，无法避免重复。业务代码必须实现幂等性，例如通过数据库唯一键或 Redis 分布式锁防止重复处理。

Redis Stream 和 Kafka 在可靠性上有什么区别？

Redis Stream 依赖单节点或哨兵/集群持久化，数据安全性弱于 Kafka 的多副本机制。高可靠场景优先选 Kafka，Redis Stream 适合轻量级异步。

手动 ACK 失败后消息去哪了？

若配置了死信队列（DLQ），超过 max-attempts 后消息转发到 DLQ 主题。若未配置，消息保留在 PEL 列表中，直到被手动清理或消费者组删除。