当前位置：首页 >专题 >Redis Streams 消费组与可靠任务恢复工程实践专题
Redis Streams 消费组与可靠任务恢复工程实践专题
官方入口与权威资料
先厘清 Streams、消费组、确认与失败恢复的底层语义
Redis Streams 官方文档
Redis Streams 数据类型、消费组、Pending Entries List 与消息确认的官方总览。
Redis Streaming 官方用例
Redis 官方用事件流、回放、消费组和可靠处理构建 streaming 应用的实践入口。
XREADGROUP 官方命令文档
XREADGROUP 的消费组读取、BLOCK、COUNT、NOACK 和 Pending 行为说明。
XACK 官方命令文档
XACK 的确认语义、返回值和 Pending 移除行为。
XPENDING 官方命令文档
XPENDING 查询 Pending Entries List、消费者分布和空闲时间。
XAUTOCLAIM 官方命令文档
XAUTOCLAIM 自动接管超过最小空闲时间的 Pending 消息。
go-redis 官方仓库
Redis 官方 Go 客户端仓库，提供 Streams、消费组和命令 API 的实现入口。
站内实战文章
从 Go 队列模型到 Pending 恢复、积压监控与运维边界
Redis 8.8 Stream 怎么扛住 AI Agent 多步任务：重复消费、积压与恢复边界
Docker Compose 本地多服务环境实战：MySQL、Redis、Nginx 一键启动
常见问题
可靠消费最容易误判的四个边界
Redis Streams 能保证消息只处理一次吗？
不能把 Redis 的消费确认理解为业务层 exactly-once。消费者在外部副作用完成后、XACK 之前崩溃，消息可能被重新接管；必须用 task_id、业务唯一键或幂等表保护重复执行。
什么时候应该用 XAUTOCLAIM 接管 Pending 消息？
只有在消息空闲时间明显超过该步骤的正常处理租约、并确认原消费者已失联或不可恢复时才接管。空闲阈值过短会误抢仍在处理的长任务，过长会让积压静默扩大。
XACK 应该在调用外部 API 前还是之后执行？
通常应在业务处理和必要的副作用落库完成后确认；提前 XACK 会造成消息丢失，永不 XACK 又会让 Pending 无限增长。跨 Redis、数据库和外部 API 没有天然事务，需配合幂等、状态机和补偿。
如何判断是消费者慢还是 Redis Stream 真正积压？
同时观察待投递数量、Pending 数量、最老 Pending 的空闲时间、消费者在线数、处理耗时、重试次数和死信数量；只看 Stream 长度无法区分生产过快、消费者掉线和业务处理卡住。
相关专题
继续查看相近方向内容
