Redis XPENDING 怎么查看消费组中最老的未确认消息
Redis Stream 使用消费组读取消息时,消息被某个消费者读到但还没有执行 XACK,就会进入 Pending Entries List。要查看消费组中按消息 ID 最早的未确认消息,最直接的命令是:
XPENDING orders-stream order-workers - + 1
# orders-stream 是 Stream key,order-workers 是消费组
# - 和 + 表示从最小 ID 到最大 ID,1 表示只取一条
返回结果的第一项是消息 ID,第二项是当前消费者,第三项是距离上次投递经过的毫秒数,第四项是投递次数。这里的“最老”指 Pending 列表中消息 ID 最小,不等于空闲时间最长。后者要用 IDLE 条件单独查询。
XPENDING stream group先看 pending 总数、最小 ID、最大 ID和消费者分布。XPENDING stream group - + 1可取按 ID 最早的一条明细。- 真正排查卡住消息时,还要看 idle 毫秒数和 deliveries 次数,必要时再考虑恢复。
Redis XPENDING 先看消费组的 Pending Entries List
XPENDING 只检查消费组的待确认记录,不读取 Stream 的字段内容,也不会自动确认或转移消息。先执行摘要形式,适合判断问题规模:
XPENDING orders-stream order-workers
# 这个形式不带范围参数,只返回消费组摘要
摘要通常包含四部分:pending 总数、最小消息 ID、最大消息 ID,以及每个拥有 pending 消息的消费者和对应数量。例如返回的结构可以理解为:
| 位置 | 含义 | 排障用途 |
|---|---|---|
| 1 | pending 总数 | 判断消费组是否存在未确认积压 |
| 2 | 最小 pending ID | 定位按消息 ID 最早的未确认消息 |
| 3 | 最大 pending ID | 了解未确认范围的大致上界 |
| 4 | 消费者计数 | 判断积压集中在哪个消费者 |
如果第一项为 0,后面的最小和最大 ID通常为空,此时没有可供 XPENDING ... - + 1 查询的 pending 消息。不要用 Stream 中最早的消息 ID代替 pending 最小 ID,两者属于不同集合。
用扩展查询确认按 ID 最早的未确认消息
要拿到摘要中的最小 ID对应的完整 pending 元数据,可以把范围设为整个 ID空间、数量设为 1:
XPENDING orders-stream order-workers - + 1
# 结果按 Pending Entries List 的 ID 顺序返回,数量限制为 1
扩展形式每条记录有四个字段:消息 ID、当前 owner、idle 毫秒数、投递次数。假设结果类似 1728000000000-0 worker-a 42000 2,可读成“消息 ID 为 1728000000000-0,由 worker-a 持有,距上次投递约 42 秒,累计投递 2 次”。这一步已经能回答“最老的是谁、当前被谁拿着、多久没动过”。
如果需要查看这条消息的业务字段,再用同一个 ID查询 Stream:
XRANGE orders-stream 1728000000000-0 1728000000000-0
# 只回查这个 ID,避免把整条 Stream 扫出来

用 consumer 和 IDLE 条件缩小排查范围
当摘要显示多个消费者都有 pending 消息时,可以追加消费者名称,只查看该 owner 的记录:
XPENDING orders-stream order-workers - + 20 worker-a
# 只查询 worker-a 持有的 pending 消息,最多返回 20 条
Redis 6.2及以上还支持 IDLE,单位是毫秒。下面的命令只找空闲至少 60 秒的 pending 消息:
XPENDING orders-stream order-workers IDLE 60000 - + 20
# IDLE 过滤的是距上次投递的空闲时长,不是消息 ID年龄
因此可以这样区分两个目标:
| 想找什么 | 命令重点 | 结论 |
|---|---|---|
| 按消息顺序最早 | - + 1 | 第一条返回记录就是最小 pending ID |
| 长时间无人处理 | IDLE 60000 - + 20 | 返回空闲至少 60秒的记录 |
| 某个消费者的积压 | 末尾追加 consumer | 只看该消费者的 owner 记录 |
查询结果中的 idle 较大、deliveries 不断增加,通常说明消费者重复读取或处理失败;idle 较小但 pending 数量持续上升,则更像消费速度跟不上生产速度。这里是排查线索,不应只凭一条命令直接判定业务故障。

查到最老消息后不要误用 XACK 或转移命令
XPENDING 是只读观察命令。确认业务已经成功处理后,才对明确的消息 ID执行 XACK;如果原消费者失效且消息已超过恢复阈值,再根据幂等策略评估 XAUTOCLAIM 或 XCLAIM。直接对“最小 ID”执行确认,可能把尚未处理的订单、支付或库存事件从待确认列表移除。
生产排查可以按这份清单走:先记下 pending 总数和最小 ID,再取一条扩展明细;随后用 XRANGE 核对业务字段,查看 owner、idle 和 deliveries;最后结合消费者日志决定修复、确认或恢复。命令本身耗时与返回条数有关,日常观察应使用较小的 count,不要无条件拉取整个 Pending 列表。
常见问题
XPENDING 返回空结果怎么办?
先确认 Stream key和消费组名称没有写错,再执行摘要形式。如果 pending 总数为 0,说明当前没有未确认记录;如果命令报错,则检查消费组是否已经创建。
最小 pending ID能直接拿到消息内容吗?
不能。XPENDING 返回的是 Pending Entries List 元数据,要用 XRANGE stream id id按这个 ID回查 Stream 字段。
怎么找空闲最久的消息?
XPENDING 的扩展结果包含 idle 毫秒数,可使用 IDLE筛出超过阈值的记录,再结合返回的 idle 值和消费者状态判断。按 ID最小并不代表空闲最久。
Redis 官方命令说明可参考 XPENDING 文档,其中还列出了范围、消费者过滤和 IDLE参数的完整语法。
Go errors.Join 返回的错误怎么逐个用 errors.Is 判断
- 上一篇
- Go errors.Join 返回的错误怎么逐个用 errors.Is 判断
- 下一篇
- Go bufio.Reader 读取一行时怎么保留行尾换行符
-
- 数据库 · Redis | 3小时前 |
- Redis Lua 脚本返回数组时客户端为什么出现 nil
- 448浏览 收藏
-
- 数据库 · Redis | 5小时前 | Redis · 事务 · Redis Cluster · redis Redis Cluster 哈希标签 MULTI hash slot
- Redis Cluster 跨槽位事务为什么不能直接使用 MULTI
- 300浏览 收藏
-
- 数据库 · Redis | 7小时前 |
- Redis AOF 重写期间磁盘空间为什么会突然变大
- 191浏览 收藏
-
- 数据库 · Redis | 9小时前 | Redis · Streams · Pub/Sub · Redis Streams Redis Pub/Sub 消息补收
- Redis Pub/Sub 断线后消息为什么不能补收
- 363浏览 收藏
-
- 数据库 · Redis | 14小时前 |
- Redis Hash 里的大字段怎么只更新一个子键
- 414浏览 收藏
-
- 数据库 · Redis | 16小时前 |
- Redis Stream 消费组如何处理 Pending 列表里的超时消息
- 494浏览 收藏
-
- 前端进阶之JavaScript设计模式
- 设计模式是开发人员在软件开发过程中面临一般问题时的解决方案,代表了最佳的实践。本课程的主打内容包括JS常见设计模式以及具体应用场景,打造一站式知识长龙服务,适合有JS基础的同学学习。
- 543次学习
-
- GO语言核心编程课程
- 本课程采用真实案例,全面具体可落地,从理论到实践,一步一步将GO核心编程技术、编程思想、底层实现融会贯通,使学习者贴近时代脉搏,做IT互联网时代的弄潮儿。
- 516次学习
-
- 简单聊聊mysql8与网络通信
- 如有问题加微信:Le-studyg;在课程中,我们将首先介绍MySQL8的新特性,包括性能优化、安全增强、新数据类型等,帮助学生快速熟悉MySQL8的最新功能。接着,我们将深入解析MySQL的网络通信机制,包括协议、连接管理、数据传输等,让
- 500次学习
-
- JavaScript正则表达式基础与实战
- 在任何一门编程语言中,正则表达式,都是一项重要的知识,它提供了高效的字符串匹配与捕获机制,可以极大的简化程序设计。
- 487次学习
-
- 从零制作响应式网站—Grid布局
- 本系列教程将展示从零制作一个假想的网络科技公司官网,分为导航,轮播,关于我们,成功案例,服务流程,团队介绍,数据部分,公司动态,底部信息等内容区块。网站整体采用CSSGrid布局,支持响应式,有流畅过渡和展现动画。
- 485次学习
-
- H2O EvalGPT
- H2O EvalGPT是H2O.ai推出的开源LLM评估平台,提供详细的大模型性能排行榜、行业特定基准测试及A/B测试功能,助您快速选择最适合项目的高性能大语言模型。
- 37次使用
-
- SuperCLUE
- SuperCLUE是权威的中文大语言模型综合评测基准,涵盖语言理解、知识应用、AI Agent智能体及安全性等12项核心能力。通过多轮对话与客观测试,定期发布榜单与技术报告,为模型研发、优化及行业选型提供科学依据。
- 189次使用
-
- C-Eval
- 深入了解C-Eval中文评估套件,涵盖52个学科与4级难度。本文详解其功能特点、Zero-shot/Few-shot使用方法及代码示例,助您全面评测LLM中文理解与泛化能力。
- 129次使用
-
- AI Prompt Library
- 探索AI Prompt Library免费资源库,涵盖营销、写作及多场景AI提示词。兼容ChatGPT、Claude等工具,一键复制优化输出,提升工作效率。
- 53次使用
-
- Generrated
- Generrated汇集9300+张DALL·E生成图像及对应提示词,支持查看完整图集、对比DALL·E 2与3版本差异,是AI绘图新手学习Prompt设计与获取创作灵感的实用工具。
- 40次使用
-
- Go与Redis实现分布式互斥锁和红锁
- 2022-12-22 117浏览
-
- Go+Redis实现延迟队列实操
- 2023-02-23 426浏览
-
- 一文搞懂Go语言操作Redis的方法
- 2023-01-07 171浏览
-
- Golang分布式应用之Redis示例详解
- 2023-01-07 113浏览
-
- Go Redis客户端使用的两种对比
- 2022-12-30 195浏览

